[Ecrit] review comments: draft-ietf-ecrit-framework-00

[peter_blatherwick at mitel.com]

Hi, 

OK, I've finally found some time to compile comments on 
draft-ietf-ecrit-framework-00 ... read it through just ages ago now.  I've 
only made it to compiling comments through end of section 4 so far (my 
main area of expertise anyway).  May have more later. 

Overall, I find this doc very useful, in fact required to understand all 
the other bits and pieces.  Glad to see it become an official WG item! 

Cheers, 
Peter Blatherwick

===============================================================

General
-------

o Biggest comment is I think the Overview needs some work, for clarity and 
readability.  Real important to get this very clear, since it sets up all 
the other pieces.  Most of the appropriate material seems to be there, but 
it is confusing in current form.  See some specific suggestions below. 

o Generally, the document seems focused on "public" scenarios (lumping 
residential in here), and does not mention enterprise needs much at all. 
Phrases like "access network" (which shows up very often) tend to 
emphasize this.  Framework should be applicable to both.  It needs to be 
pointed out that enterprise networks also must work into this overall 
framework, and may (or may not) reuse the same mechanisms in exactly the 
same ways, but with some pieces inside the enterprise infrastructure or 
otherwise differently arranged (notably LIS and other location resources, 
IMHO..).  Also, it should be pointed out that many networks perceived by 
the end user as "public" are actually managed enterprise-like networks -- 
notable examples would be airport and municipal run WiFi, university 
campuses, etc.  Not sure how to fix this, or if others also share this 
view for that matter.  Maybe some scoping statements, or just a bit more 
discussion on applicability somewhere up front would clarify?  (I will put 
my thinking cap on for this one.) 

o Sec 5, Location, is primarily an informative discussion, with some pros 
and cons, at present.  Is it intended to add explicit requirements into 
this section as they get settled (MUSTs, SHOULDs ...)?  Would be very 
helpful. 

Specific (issues, comments, etc)
--------------------------------

o sec 1 Terminology, I think it would be very helpful to spell out 
definitions here, even where they come from other docs (notably the Req'ts 
and core SIP).  Yes, i know, creates dependancies.  But it would make this 
doc stand alone, and it will be the first thing on the topic many people 
read. 

o sec 1 Terminology, Location Determination.  Should add more likely 
examples here, including ones not device-driven (GPS is low likelihood, 
other than cellular).  Would add words to effect of " ..., or location may 
be determined by administration using a wiremap database or similar." 

o sec 3 Overview. Needs a brief description of Fig 1, outlining each of 
the main elements. (See more below.) 

o sec 3 Overview, para 2, bullet 2.  Should be stated more clearly that 
other methods are equally applicable (remove bias).  Please add words to 
effect of "... we use DHCP as an example location acquisition protocol 
(LLDP or [L7] methods are equally applicable). 

o sec 3 Overview, description of fig 2.  Here, I start to get confused... 
I find the description pretty hard to follow, kinda crammed and jumbled. 
Also, there are multiple errors in which message is which in the 
description, and Fig 2 and Fig 1 seem to be reversed (eg. UA contacting 
the LoST server is M3 (not M7) in Fig 1, or is it M5-6 in Fig 2 ??)  There 
are others lower down as well. Suggest a re-organization of the material 
would be a big help.  Suggest: 
- adding descr of the functional elements shown in Fig 1, immediately 
below fig 1 (comment above); 
- then Fig 2; 
- then description of Fig 2 main steps, with each step description led 
with the messages it applies to, eg "[M5]-[M6] Alice's UA performs an 
initial Lost query <blah blah blah> ..."
- line up message numbers between Fig 1 and Fig 2, if possible (or maybe 
lose the numbers altogether in Fig 1). 

o sec 3 Overview, description of fig 2.  The roll of the LIS in this is 
quite unclear, making it hard to correlate Fig to Fig 2.  Please describe 
how the LIS fits in. 

o sec 5.2. Add references for DHCP-Civic, DHCP-geo, [L7] (TBD), as well as 
LLDP-MED. 

o sec 5.2, final paragraph.  Protocols developed outside of IETF are also 
used in the ECRIT framework, and also can support all IETF recommended 
formats.  Notably LLDP-MED (now MUST in the Phone BCP) uses exact same 
data formats as the DHCP methods (and more).  Current wording implies that 
only IETF protocols are used.  Suggest this get re-worded to effect of "In 
IETF recommended Location Configuration Protocols [x-ref sec 5.5], both 
civic and geospatial formats are supported. ..." 

o sec 5.5, LLDP.  LLDP-MED is no longer "proposed", was released last 
year.  Also, should point out it carries exact same civic and geo content 
as DHCP methods.  Suggest: "Link Layer Discovery Protocol [LLDP] with 
Media Endpoint Device extensions [LLDP-MED] can be used to deliver 
location information directly from the Layer 2 network infrastructure, and 
also supports both civic and geospatial formats identical in format to 
DHCP methods." 


Nits
----

o sec 2 Intro, 1st paragraph.  Suggest wording fix " ... many of the 
technical [properties] of Internet multimedia require re-thinking..." 
Having to re-think is not an "advantage". 

o sec 2 Intro, 2nd paragraph, bullet 2.  Broken sentence, suggest: " 
interleaving of emergency call traffic along with non-emergency traffic 
(e.g. normal call or other data) over the same infrastructure." 

o sec 2 Intro, 2nd paragraph, bullet 5.  Would lose the second sentence -- 
it is out of place with other bullets.  Or, add some example to the other 
bullets. 

o sec 2 Intro, paragraph 5 & 6. Some boundaries can be nation, 
state/province, county.  Think it would be better to just keep it neutral. 
 Suggest: "... systems are organized [regionally]; ..."   "... Internet 
does not respect [regional] boundaries ..."  "... emergency calls can be 
[in different regions (even continents)], with different [regulatory 
constraints,] conventions and processes ..."  "... refused to create 
[regional] variants ..."

o sec 2 Intro, paragraph 8, last sentence.  It is really the phone BCP 
that mandates common codecs, so sentence is a bit confusing / misleading. 
Suggest something like "... this document describes that certain minimal 
capabilities, that call taker UAs and PSAP operated proxies should 
support, will be required for reliable operation.  [Phone BCP] describes 
these requirements in detail. "

o sec 5.2, Jurisdictional.  Should point out that Civic/Jurisdictional is 
preferred.  (Postal description says that that one is not preferred.) 

o sec 5.3.4. Needs a preamble. 

o sec 5.4, formatting of pros / cons would be easier as a table. 

===============================================================



_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit