[Ecrit] Review: draft-ietf-ecrit-phonebcp-01.txt

[Shida Schubert <[e-mail]>]

Draft: draft-ietf-ecrit-phonebcp-01
Reviewer: Shida Schubert
Review Date: 2007.05.10

Summary/General Comments:
----------------------------------------
 - First of all thank you very much for putting this together..
   I don't know why I waited so long to read this draft, it 
   covers a lot of ground and gives you a very good idea 
   on how SIP enabled device would interact with other entity 
   to make emergency call work. I think it's in pretty good 
   shape but needs some more work.

 - Introduction needs some text mentioning how this document 
   provide the minimum primitives and recommended behavior 
   each entity involved in an emergency call needs to support
   or comply. AFAIK, the document will also cover recommended 
   behavior for LoST, Resolver 
   etc. specific to an emergency call(providing default URI in 
   case it can't inquire Forest Guide or other leaf node etc.) 
   and it should be mentioned in an introduction as well.

 - Section 6.1 seems to lack the UA's behavior in case multiple location 
   or multiple means of obtaining location exists(e.g. GPS, DHCP, L7-LCP).


Technical Comments:
----------------------------------------
 T1: Section 2, 4th paragraph.
 - 3rd bullet expects entity to get dialstring without 
   the Service-URN. AFAIK it works the other way around. 
   You provide the Service URN and you get dialstring in return. 

 T2: Section 4.3.
 - I don't really see how location determined by network can 
   be explicitly overridden by the location user enters. Even 
   if device manages to override location information it obtained 
   through DHCP, L7-LCP or LLDP-MED, same provider that provided 
   the location can still insert the location by reference. 

 - Also what do you mean by the last sentence on this section? 
   What method? Account for what condition? 

 T3: Section 4.4, paragraph 1, last sentence.
 - "In other words, the established VPN to Chicago from the 
    device in Dallas MUST NOT overwrite the Dallas location 
    for any reason especially an emergency call."
    > I don't think we have any specs to accomplish this "MUST NOT"?
      I see the value and when we consider VPN, it sure is a  
      sounding requirement but do we have anything that we can provide 
      to satisfy the "MUST NOT"? Problem is not only 
      overwriting but the Dallas location should be used if there 
      are multiple locations(e.g. proxy in Chicago may add by-reference 
      location.)
    > I guess if UA is aware of the fact that it's connected to Dallas 
      via VPN, and it could distinguish the location information it 
      obtain from Dallas ISP/AP it could in fact flag the location it 
      obtained with the "message-routed-on-this-uri" whether it be 
      by-reference or by-value. 

 T4: Section 4.4, paragraph 3.
 - I always thought that the location request is expected to take place 
   if only when the device has no way to measure its location. If that's 
   the case text should consider the fact that device may not be dependent 
   on the Network for location configuration.

 T5: Section 4.5
 - Emergency specific behavior and expectations surrounding location, I guess
   needs to be added to this section. 
    e.g) 
     by-value MUST NOT be encrypted using S/MIME etc.

 T6: Section 6.1, 1st bullet, last sentence.
 - sips URI being a MUST seems a bit too restrictive. RFC3261 compliant 
   proxy is supposed to implement sips, but that's not how it is for UA. 
   "SHOULD" here seems more reasonable. 

 T7: Section 6.1, 3rd bullet.
 - You are mandating an AoR to be present when it may be possible that 
   device can't set AoR. Where there is a chance that AoR may not be set 
   and that's foreseen, shouldn't the strength be SHOULD not MUST or 
   say something like "unless AoR can't be provided due to brabrabra.."

 T8: Section 6.1, 6th bullet
 - Neither P-A-ID or SIP IDentity are added at discretion of the UA, so 
   this is a requirement for the administrative domain not that of a UA.. 
   This bullet should be moved elsewhere. 

 T9: Section 6.2, last bullet
 - I don't think we really want to change the location used for location 
   based routing in midst of the routing. Also semantically would simple
   location based routing(local database using location to determine 
   which next hop proxy it should route the call to) and location used 
   for LoST resolution be the same thing? 
 - Anyhow, if we want to allow mid-routing change of location used for 
   location routing, I think you should add a text describing the implication.

 T10: Section 6.3, 1st sentence
 - AFAIK, LoST doesn't take location expressed by PIDF-LO does it? I thought 
   it takes the location potion of the PIDF-LO but not the whole PIDF-LO. 

 T11: Section 6.3, 2nd paragraph.
 - The mandate for LoST usage is "location support and LoST support" so 
   the following text should say 

   OLD: "User agents that can obtain location information MUST perform the
        mapping from location information to PSAP URI using
        [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>]. "

   NEW: "User agents that can obtain location information which support 
        [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>]MUST perform the mapping from location 
        information to PSAP URI using.

   > Question is what if UA doesn't support LoST? I guess it can't really 
     forward the call to proxy to simply obtain PSAP URI could it? As it 
     would probably end up making the actual emergency call...
 
 
Clarifications Desirable:
----------------------------------------
 C1: Section3 
 - In Introduction, it seems to focus on SIP devices though 
   in section 3, the scope and expectation of devices supporting 
   emergency call seems to not be limited to SIP devices. 
   Is this document a BCP for SIP enabled phones and servers? 
   If so I don't know if there is any value to leave it too 
   flexible. 

 C2: Section 4, 1st paragraph, last sentence.
 - Where is it a norm? IP? Current infrastructure?

 C3: Section 5, 4th paragraph, 2nd sentence.
 - What do yo mean? "The scheme includes a single
   emergency URN (urn:service:sos) and responder specific ones
   (urn:service:sos.police)".. Could you paraphrase this so 
   I can understand what you are trying to state with this 
   statement? Thank you..

Editorial Comments:
----------------------------------------	
 E1: Section 2, 4th paragraph, 5th bullet.  
  OLD: It would determine the PSAP's URI by using the
      [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>] mapping server from the location provided

  NEW: It would determine the PSAP's URI with the location it obtained 
      using the [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>] mapping server.

 E2: Section 2, 4th paragraph, last bullet.
  OLD: The call is established and common media streams opened.
 
  NEW: The call is established and common media streams open.

 E3: Section 2, last paragraph, 1st sentence. 
  - "video" is missing. 

  OLD: Best Current Practice for SIP user agents including handling of audio
       and real-time text [RFC4103 <http://tools.ietf.org/html/rfc4103>]media detailed in [RFC4504 <http://tools.ietf.org/html/rfc4504>] SHOULD be
       applied.
 
  NEW: Best Current Practice for SIP user agents including handling of audio,
       video and real-time text [RFC4103 <http://tools.ietf.org/html/rfc4103>]media detailed in [RFC4504 <http://tools.ietf.org/html/rfc4504>] SHOULD be
       applied. 


 E4: Section 2, last paragraph, last sentence. 
  - "as" is missing. 

  OLD: This memo can be considered an addition to it for
       endpoints.
 
  NEW: This memo can be considered as an addition to it for
       endpoints. 

 E5: Section 3, 1st paragraph, 2nd sentence. 
  - There are 2 periods at the end of this sentence.

 E6: Section 3, 1st paragraph, 3rd sentence.
  OLD: In general, if a user could reasonably expect to be able to call for
    help with the device, 

  NEW: In general, if a user could reasonably expect to make a call for 
    help with the device, 

 E7: Section 4, 2nd paragraph.
  - Use of "we" seems a bit odd. Who is WE?

  OLD: In Internet emergency calling, we "Determine" where the endpoint is
   located using a variety of measurement or wiretracing methods.  We
   "Configure" endpoints with their own location.  We "Map" the location
   to the URI to send the call to, and we "Convey" the location to the
   PSAP (and other elements) in the signaling.  These topics are
   detailed in [I-D.ietf-ecrit-framework <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-framework>].

  NEW: In Internet emergency calling, we "Determine" where the endpoint is
   located using a variety of measurement or wiretracing methods. The 
   endpoints are "Configured" with the measured or the obtained location . 
   Location is "Mapped" to the URI where call is to be sent to, and "Conveyed"
   to the PSAP (and other elements) in the signaling. These topics are
   detailed in [I-D.ietf-ecrit-framework <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-framework>].

 E8: Section 4.1, 2nd paragraph, 2nd sentence.
  - Introduce the acronym LCP.
   
  OLD: To obtain location information, the endpoint can use a Location 
    Configuration Protocol.

  NEW: To obtain location information, the endpoint can use a Location 
    Configuration Protocol (LCP).

 E9: Section 4.3, 2nd last sentence.
  - demarc is an acronym so wouldn't it be DEMARC?

 E10: Section 5, 6th paragraph, 
 
  OLD: This mapping is SHOULD performed at the endpoint device, but MAY be
   performed at an intermediate entity (such as a SIP proxy server)

  NEW: This mapping SHOULD be performed at the endpoint device, but MAY be
   performed at an intermediate entity (such as a SIP proxy server)

 E11: Section 5, 2nd last paragraph, last sentence.
  - Better keep the number format consistent.
 
  OLD: If the device roams to Paris, the home
   dialstring remains the same, "9-1-1", but the visited dialstring
   changes from 999 to "1-1-2".

  NEW: If the device roams to Paris, the home
   dialstring remains the same, "9-1-1", but the visited dialstring
   changes from "9-9-9" to "1-1-2". 

 E12: Section 5, last paragraph, 2nd sentence. 
  - No ")"
 
  OLD: [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>]) provides dialstrings for a given
   location and SHOULD be used by devices to learn the local (i.e.
   "visited" dialstrings.

  NEW: [I-D.ietf-ecrit-lost <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-ecrit-lost>]) provides dialstrings for a given
   location and SHOULD be used by devices to learn the local (i.e.
   "visited" dialstrings).

 E13: Section 6, 1st sentence.
 
  OLD: SIP signaling [RFC3261 <http://tools.ietf.org/html/rfc3261>] is expected be supported by upgraded PSAPs.

  NEW: SIP signaling [RFC3261 <http://tools.ietf.org/html/rfc3261>] is expected to be supported by upgraded PSAPs.




 E14: Section 6.1, 2nd bullet, 2nd sentence 
  - "To" should be R-URI

 OLD: If the device cannot access a LoST server, the
      To: SHOULD be a service URN in the "sos" tree.  If the device
      cannot do local dialstring interpretation, the Request-URI
      SHOULD be a dialstring URI 

 NEW: If the device cannot access a LoST server, the
      Request-URI: SHOULD be a service URN in the "sos" tree.  If the device
      cannot do local dialstring interpretation, the Request-URI
      SHOULD be a dialstring URI 


 E15: Section 6.1, 7th bullet
  - How about something like this?
  
 OLD: A Contact header MUST be present (which might contain a GRUU
      [I-D.ietf-sip-gruu <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-sip-gruu>]) to permit an immediate call-back to the
      specific device which placed the emergency call.

 NEW: A Contact header MUST be present with URI that's hopefully 
      globally routable such as GRUU [I-D.ietf-sip-gruu <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-sip-gruu>] to permit 
      an immediate call-back to the specific device which placed 
      the emergency call.

 E16: Sectino 6.1, 11th bullet
  - 11th bullet starts of with "if the device support loc-conv". 
    Therefore it should come before bullet 10 > Change bullet 10 and 11. 

 E17: Section 6.1, 10th bullet
  
  OLD: If the device's location is by-reference, a Geolocation: header
       [I-D.ietf-sip-location-conveyance <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-sip-location-conveyance>] MUST be present containing
       the URI of the PIDF-LO reference for that device.  Whichever
       location is used for routing the message towards the PSAP or
       ESRP, even if there is only one, the Geolocation "message-
       routed-on-this-uri" header parameter SHOULD be added to the
       corresponding URI in the Geolocation header.
  
  NEW: If the device's location is by-reference, a Geolocation: header
       [I-D.ietf-sip-location-conveyance <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-sip-location-conveyance>] MUST be present containing
       the URI referencing the PIDF-LO for that device.  



 E18: Section 6.1, 11th bullet
	

 OLD: 	if a device understands the SIP Location Conveyance
        [I-D.ietf-sip-location-conveyance <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-sip-location-conveyance>] extension and has its
        location available by value, it MUST include location either by-value or
        by-reference.  If including by-value, the INVITE contains a
        Supported header with a "geolocation" option tag, and a "cid-
        URL" [RFC2396 <http://tools.ietf.org/html/rfc2396>] as the value in the Geolocation header,
        indicating which message body part contains the PIDF-LO.  If including the
        location by-reference, it includes the same Supported header with the 
        "geolocation" option tag, and includes the URI to the PIDF-LO 
	in a Geolocation header.[I-D.ietf-geopriv-pdif-lo-profile <http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-01#ref-I-D.ietf-geopriv-pdif-lo-profile>] MUST be used. 


 E19: Section 6.1
  - Add a bullet for when UA does the LoST resolution and needs to 
    mark the location it used for LoST. Following text is a suggestion.

    If the LoST resolution was done on UA, whichever
    location used for resolving PSAP or ESRP URI 
    SHOULD have "message-routed-on-this-uri" header parameter 
    appended to the corresponding URI in the Geolocation header.

 E20: Section 6.1, 15th bullet
  OLD: A UAC SHOULD include the Geolocation "inserted-by=endpoint"
       header parameter.  

  NEW: A UAC SHOULD append the Geolocation "inserted-by=endpoint" 
       header parameter to all the location UAC inserted.

 E21: Section 6.2, 1st bullet, 2nd point
  - "Insert a Geolocation header as per 10-12 above" would imply
    that proxy can add PIDF-LO into the message which violates RFC3261.

    Of course if it's B2BUA it's possible but I think you should focus 
    on proxy here, so only reference 10 which talks about by-reference
    should be noted.
 


I hope it helps. 
 Thanks & Regards

--
Shida Sven Schubert           
[e-mail]	PHONE: [phone] 


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