Subject: [Ecrit] Fwd: Re: WGLC on draft-ietf-ecrit-phonebcp-04

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Mar 2008 14:34:33 -0600

please ignore this message, I replied to this message when I thought 
I was replying to another message.  I don't believe there is any 
secret sauce in this message...

hehe

sorry!

James

>Date: Tue, 04 Mar 2008 14:32:11 -0600
>To: <[email-masked]>, <[email-masked]>, <[email-masked]>
>From: "James M. Polk" <[email-masked]>
>Subject: Re: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04
>
>Subha
>
>Hey - I'm pretty sure this TBD isn't the same element, which means 
>this guy is going ot come after us each time he thinks of a new 
>element.  I agree with your analysis, though I don't want to have to 
>bring several up to speed if they want to join.  I don't know if you 
>can suggest that only a few of us tackle this as the EAB-location 
>group, and let it stand as we work it out along the way.  If so, 
>this would be better coming from both you and Allan than from me 
>(during the call Friday).
>
>James
>
>At 02:21 PM 3/4/2008, James M. Polk wrote:
>>Gabor
>>
>>That this document is from the IETF means it involves IP.
>>
>>more in-line below
>>
>>At 10:37 PM 3/2/2008, [email-masked] wrote:
>> >Few comments below:
>> >
>> >1. The title of the document does not explicitely say that this document
>> >is about "VoIP" emergency calls.
>> >Suggestion: add "VoIP" to the title (... Communications Services in
>> >support of VoIP Emergency Calling)
>>
>>Calls are not limited to "voice", even though each are called "calls".
>>
>>
>> >2. The title of the documents says "Best Current Practice for ...",
>> >while the document is not a collection nor a subset of the currently
>> >used practices for emergency calling. And there is no 'current practice'
>> >for VoIP emergency calling yet, thus a 'best current practice' of yet
>> >nonexisting practices is confusing.
>> >Suggestion: change the title eg to "Requirements for Communication
>> >Services in support of VoIP Emergency Calling"
>> >(and revise the abstract section accordingly)
>>
>>While I agree there are no current practices, this document is an
>>effort with a fair degree of interworking amongst emergency calling
>>consortia - and the goal here is to establish an singular
>>architecture, not one of many choices - therefore stating clearly
>>this is "one" practice to be implemented is best. The title does
>>this.  The document status is to be Proposed Standard, not Best
>>Current Practice.
>>
>>
>> >3. "ED-4/SP-3 Emergency calls MUST be marked with a Service URN in the
>> >    Request-URI of the INVITE."
>> >Marked by whom, the endpoints, the proxies or both? Clarify
>>
>>this is in the document
>>
>>
>> >4. "ED-5/SP-4 Local dial strings MUST be recognized." and "ED-6/SP-5
>> >Home dial strings MAY be recognized."
>> >Recognized by whom? Clarify
>>
>>What is this document about?  (hint: entities supporting this (to be)
>>IETF standard) That's whom.
>>
>>
>> >5. "ED-10 Devices SHOULD NOT have one button emergency calling
>> >    initiation."
>> >While I understand that the intention is to discourage vendors to design
>> >devices with a button dedicated only for emergency calls, current mobile
>> >phones have the possibility of 'speed dial', when a preset dial string
>> >(including 112 or 911) can be assigned to any button. Requirement ED-10
>> >can be also read to ban this feature in the phone. Clarify.
>>
>>Have you not been involved in the emergency calling discussions over
>>the past several years within the IETF or NENA?
>>
>>This "emergency button" was tried and if failed miserably within the
>>US in the late 80s - because of too many false emergency calls
>>because the single button was accidently hit (for example, in a
>>lady's purse).  This wrecked havoc on PSAP call takers and first
>>responders. So while this idea sounds great, it doesn't work in practice.
>>
>>If this still needs to be clarified, this can be with a single sentence.
>>
>> >I do not have a suggestion, but as today's devices do not have such a
>> >dedicated red button any more, I see no value in this requirement, it
>> >just creates confusion.
>>
>>it clarifies that one shouldn't ever be thought of again
>>
>>
>> >6. "ED-11/SP-9 All emergency services specified in
>> >[I-D.ietf-ecrit-service-urn] MUST be recognized."
>> >Recognized by whom? Clarify.
>>
>>(hint: entities supporting this (to be) IETF standard) That's whom.
>>
>>
>> >7. "6.1.  Types of location information
>> >
>> >    There are several forms of location.  In IETF protocols , civic and
>> >geospatial (geo) forms are both supported."
>> >The term "IETF protocols" is too broad. UDP/TCP/DNS/ARP etc. are all
>> >'IETF protocols', but they do not support location. Be more specific.
>>
>>In these are to carry location  - I think they should consider what's
>>said in this document.
>>
>>To be more specific means to list every protocol that cannot support
>>location and every protocol that might be able to support
>>location.  The remainder either is going to or does support location.
>>
>>
>> >8. section 6.1
>> >"Other forms of
>> >    location representation must be mapped into either a geo or civic for
>> >    use in emergency calls."
>> >Currently most mobile network carriers use cell-id for directing the
>> >call to the correct psap.
>>
>>Is cell-id a location?  If true, is an ALI a location. Both are
>>ids... what's the difference?
>>
>> >That technique will not go away for yet a long
>> >time. While cell-id could be mapped into either civic or geo, there is
>> >no added value in doing so, as cell-id based routing serves the purpose
>> >just as well as civic or geo based routing.
>>
>>Cell-id routing... on IP?  I believe you're mixing technologies where
>>mixing shouldn't be done.
>>
>> >I would suggest relaxing the
>> >requirement, otherwise the draft will go against current practices.
>>
>>...of cellular world infrastructures, which aren't IP based, so
>>there's no reason this requirement addresses the legacy
>>infrastructure. BTW -- I believe IMS (which is cellular based
>>systems) is using PIDF-LO and location-URI references, not cell-ids
>>
>>
>> >9. "ED-17/INT-8/AN-7 Devices that support endpoint measuring of location
>> >    MUST have at least a coarse location capability (typically <1km
>> >    accuracy when not location hiding) at all times for routing of
>> >calls."
>> >I do not understand the text in the brackets. What is location hiding
>> >(add reference to it) and what happens when it is applied, will the req
>> >become n/a? clarify.
>>
>>I agree location hiding shouldn't be in this document
>>
>> >Same comment for AN-9
>> >
>> >10. same paragraph as above. "This mechanism MAY be a service provided
>> >by the access network." It is not clear what 'this mechanism' refers to.
>> >
>> >11. "AN-8 Access networks MAY provide network-measured location
>> >    determination.  Wireless access network which do not support network
>> >    measured location MUST require that all devices connected to the
>> >    network have end-system measured location. "
>> >What kind of wireless access networks are we talking about? Commercial,
>> >public, private, academic or all of them? I could hardly believe that a
>> >free public network like the google one in Mountain View (which does not
>> >support network measured location) would have a means to restrict my
>> >laptop's access (which does not have an end-system measured location).
>> >Suggestion: be more specific. Say 'commercial wireless access networks'
>> >or 'subscription based wireless access networks'. It has to be a managed
>> >network, otherwise nothing can be enforced.
>> >
>> >12. "ED-27/INT-20 If the device sends a DHCP INFORM message"
>> >The text should say 'DHCPINFORM' (no space between, rfc2131).
>> >
>> >13. "ED-28/INT-21 To minimize the effects of VPNs that do not allow
>> >split
>> >    tunneling VPNs, location configuration SHOULD be attempted before
>> >    such tunnels are established."
>> >Add reference to 'split tunneling VPNs'(if exists). If there is no
>> >reference, then be more explicit. Say that using an LCP while on a VPN
>> >may result in getting the location of the vpn gateway. Avoid using
>> >non-defined terms.
>>
>>I agree with this
>>
>>
>> >14. "ED-47 Endpoints MUST support one or more mechanisms that allow them
>> >    to determine their public IP address.  Examples include ICE ..."
>> >It should be STUN instead of ICE.
>>
>>I believe this is true too
>>
>>
>> >15. "   ED-68/SP-38 The emergency dialstrings SHOULD NOT be permitted in
>> >Call
>> >    Forward numbers or speed dial lists."
>> >There is no such regulatory requirement in place. Vendors comply with
>> >regulatory requirements when it comes to emergency services. This draft
>> >is not an amendment to any regulatory document, thus this requirement is
>> >inappropriate. Remove it.
>>
>>ah, so here's the issue.  I you dial 911 from a US phone and the call
>>ends too early, and the call-taker chooses to call-back to the phone
>>you called from, and the phone call-forwards all calls to another
>>phone/location -- you're pretty much jacked.
>>
>>Besides, there is text stating that where local regulation/laws
>>overwrite what's written in this doc, local regulation/laws win.
>>
>>
>> >16. general comment: the draft seem to focus on 802.11 access networks.
>> >The term "access point" is used all over. Access networks other than
>> >wi-fi use terms like base station, rnc, node-b, etc. If the draft is
>> >meant to be applicable to access networks other than wi-fi, then a more
>> >generic term should be used instead of 'Access Point'.
>>
>>If this doc doesn't make it clear that
>>
>>          Access Point = AP = wifi = 802.11 base-station
>>
>>then this does need to be clarified. I don't remember if it does at 
>>the moment.
>>
>>
>> >- gabor
>> >
>> >-----Original Message-----
>> >From: [email-masked] [mailto:[email-masked]] On Behalf
>> >Of ext Hannes Tschofenig
>> >Sent: Sunday, March 02, 2008 9:54 AM
>> >To: [email-masked]
>> >Subject: [Ecrit] WGLC on draft-ietf-ecrit-phonebcp-04
>> >
>> >This is a Last Call for comments on
>> >http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-04
>> >
>> >Because of the timing of the impending IETF meeting and the interactions
>> >with other SDOs, we are setting the call for **4 weeks**.
>> >
>> >Please have your comments in no later than March 30.
>> >
>> >Do remember to send a note in if you have read the document and have no
>> >other comments other than "its ready to go" - we need those as much as
>> >we need "I found a problem".
>> >
>> >Thanks!
>> >Hannes & Marc
>> >
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>> >_______________________________________________
>> >Ecrit mailing list
>> >[email-masked]
>> >https://www.ietf.org/mailman/listinfo/ecrit
>>
>>_______________________________________________
>>Ecrit mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/ecrit

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