Subject: Comments on Phone BCP (Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt)

From: [email-masked]
Date: Wed, 25 Oct 2006 21:05:00 -0400

Hi all, 

I've given the new Phone BCP rev a good read, and have a bunch of comments 
/ questions.  None negative, just looking to further improve the spec.  I 
have also collected a pile of editorial type nits that I don't want to 
torture the whole list with, but would be happy to compile and fwd to the 
authors if they like (Brian, James just let me know). 

First though, I'm really glad to see LLDP-MED specifically a MUST location 
method.  I certainly believe this is a very good thing, especially in 
managed enterprise environments.  Also think it has a lot of future 
extension potential. 

Comments: 

o Pg 3, Introduction.  The "Phone BCP" also covers aspects of network 
infrastructure and the overall Emergency Call Service itself, as required 
to support the end device.  I think this needs to be more carefully stated 
in the Intro material, to scope the spec.  If the scope cannot be easily 
limited, then it might be better to either break up into multiple specs 
(one for end device, one for access network, one for proxy ...), or 
intentionally pile in all requirements on all elements in the path. 
Personally, I hope not to need to go to either option; think the content 
is well targeted, however it is real important to get the right 
implementation people to take it seriously.  A specific Scope section 
might help.  I could try some words if you like. 

o Pg 3, under "As a quick overview...", 2nd bullet point, also add 
LLDP-MED.  (DHCP and L7 mentioned only)

o Sec 4 general.  This reads as one big mouthful, and as such makes it 
hard to follow and determine what applies to what.  Suggest some 
subsectioning would be a very helpful (albeit editorial) change. Suggest: 
Location Determination Methods, Location Determination Timeliness, Mapping 
of Location Information. 

o Sec 4, pg 5, 1st paragraph "Such a method MUST be specified, and every 
device MUST support it.", I think it would be good to strengthen this, by 
adding words to the effect of: "It is RECOMMENDED that at least one of the 
location methods specified here be used, in order to promote improved 
interoperability."

o Sec 4, pg 5, 2nd paragraph, I think it would be helpful to tighten 
words: "For all other devices, the device MUST support all of: DHCP [ref], 
L7 [ref], and LLDP-MED [ref]."  Also break off part of this paragraph 
about DHCP to separate paragraph (see next). 

o Sec 4, pg 5, after above, I think all 3 methods should have some 
statement of applicability and their general nature.  Notably, paragraph 
on LLDP-MED should not characterize it as "an alternative to DHCP" --  it 
is not really, though it shares common data format for Civic and Geo LCI. 
I can try some words if others agree that applicability would be a good 
thing. 

o Sec 4, pg 5, 5th paragraph, "For devices that operate in ...".  This one 
is unclear to me.  (Thought I got it on first read ... now not so sure.) I 
*think* it is intended to be about deployments such as ethernet or 
wireless boxes behind (say) cable / DSL modem, for example residential or 
small office / home office.  (?!?!?)  I think this needs to be clarified, 
and state more clearly which end is receiving location from the network 
operator, how, and how it is relayed to the actual endpoint through one of 
the 3 mechanisms. 

o Sec 4, pg 5, 7th paragraph.  Is "Self Reported" meant to mean end-user 
configured, or something else?  It is capitalized as a Formal Term, yet 
not defined.  Needs to be clarified.  (actually, a Definitions section 
might help overall.) 

o Sec 5, pg 7, 8th paragraph, "Systems that support roaming ...".  I think 
it would be helpful to point out "guest use" of the end device as another 
important scenario (eg. Alice, visiting Germany; Dieter has an issue and 
grabs Alice's phone, dials ... what exactly).  This is orthogonal to 
visited network vs home, but  has many of the same requirements in terms 
of knowing the local emergency dial string. 

o Sec 5, pg 8, 2nd paragraph.  This does not mention the proposed DHCP 
method for supplying local dialstring.  I seem to have lost (or is that 
LoST ;-) track of where this went, if anywhere.  What's the state of the 
proposal to supply dialstring by DHCP?  If it is alive, it would be worth 
mention here. 

o Sec 6.2, pg 9, item 13, re compressed codecs.  Also seem to have lost 
track on this one.  Personally, I believe compressed codecs should be in 
the SDP list, but as last choice.  SHOULD NOT seems too strong, would 
personally prefer "MUST be lowest priority".  At any rate, it should say 
non-compressed audio codec MUST be supplied, and should name one (likely 
G.711).  Yeah, this is probably still contentious... 

o Sec 6.2, pg 9, paragraph after item 13, re silence suppression.  I think 
this deserves to be a numbered item, not merely a note.  Silence sup 
non-use is the right thing (ie MUST NOT), normative, so not a side-note. 
o Sec 6.2, pg 10, 1st paragraph, " ... mapping is performed whenever the 
UA acquires new location information that is outside the bounds of the 
current PSAP coverage region ...".  Perhaps I'm missing something obvious 
here, but, HOW can the UA determine this?  I would be VERY resistant to 
burden the end device (which must be simple and very cost-sensitive) with 
complex and possibly open-ended calculations to figure out PSAP bounds.  I 
think the trigger to get new LoST PSAP URI info should be much simpler, 
either time based, or at every time the underlying location data changes. 

o Sec 6.4, pg 11, 4th paragraph, " ... 5 minutes elapses ... call may be 
declared dead ...".   Hmmmm....   Is the 5 minutes an arbitrary SWAG 
(Scientific Wild-Ass Guess)?  Would this requirement potentially differ 
depending on jurisdiction?  Agree there needs to be some time limit, but 
this just seems arbitrary. 

o References, both LLDP and LLDP-MED needs corrections: 
[LLDP] IEEE 802.1AB-2005, Station and Media Access Control Connectivity Discovery 
(aka Link Layer Discovery Protocol - LLDP), May 2005.   <-- Note date, capitalization "AB" and (tm) ... IEEE folks are fussy 
about these things. 
[LLDP-MED] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices 
(aka LLDP-MED), Apr 2006. 

---- 

Hope that helps. 

Peter Blatherwick

. 

[email-masked]
18.10.06 15:50

        To:     [email-masked]
        cc:     [email-masked]
        Subject:        [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Emergency Context Resolution with 
Internet Technologies Working Group of the IETF.

                 Title                           : Best Current Practice 
for Communications Services in support of Emergency Calling
                 Author(s)               : B. Rosen, J. Polk
                 Filename                : 
draft-ietf-ecrit-phonebcp-00.txt
                 Pages                           : 16
                 Date                            : 2006-10-18

   Requesting help in an emergency using a communications device such as
   a telephone or mobile is an accepted practice in most of the world.
   As communications devices increasingly utilize the Internet to
   interconnect and communicate, users will continue to expect to use
   such devices to request help, regardless of whether or not they
   communicate using IP.  The emergency response community will have to
   upgrade their facilities to support the wider range of communications
   services, but cannot be expected to handle wide variation in device
   and service capability.  The IETF has several efforts targeted at
   standardizing various aspects of placing emergency calls.  This memo
   describes best current practice on how devices and services should
   use such standards to reliably make emergency calls

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ecrit-phonebcp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
                 [email-masked].
In the body type:
                 "FILE /internet-drafts/draft-ietf-ecrit-phonebcp-00.txt".
 
NOTE:            The mail server at ietf.org can return the document in
                 MIME-encoded form by using the "mpack" utility.  To use 
this
                 feature, insert the command "ENCODING mime" before the 
"FILE"
                 command.  To decode the response(s), you will need 
"munpack" or
                 a MIME-compliant mail reader.  Different MIME-compliant 
mail readers
                 exhibit different behavior, especially when dealing with
                 "multipart" MIME messages (i.e. documents which have been 
split
                 up into multiple messages), so check your local 
documentation on
                 how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
ftp://[email-masked]/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit