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

From: "Brian Rosen" <[email-masked]>
Date: Sun, 4 Mar 2007 22:52:49 -0500

I did most of these.

Look at the new text and see whether we need more "applicability" stuff in
the LCP section

I took a half hearted attempt to rework the text on relayed location.  Maybe
it's okay, but I'm expecting you still won't like it.

I'm not sure what we have agreed to for learning home dialstring.  It's not
DHCP (that is visited).  It's some form of configuration.

I think we have been moving down the line that if you have a mobile client,
you can do a point in polygon to figure out if you moved beyond the provided
service boundary.  We will offer advise that this boundary should be simple
(by using approximations when not near an edge, and using a small edge
section when near an edge)

I don't want to have another parameter for a declared dead call.  5 min is a
pretty long SWAG.  Got another suggestion?

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, October 25, 2006 9:05 PM
To: ECRIT list
Cc: Brian Rosen; James Polk
Subject: Comments on Phone BCP (Re: [Ecrit] I-D
ACTION:draft-ietf-ecrit-phonebcp-00.txt)

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.tx
t_______________________________________________
Ecrit mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ecrit

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