[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 shida at ntt-at.com PHONE: (604) 762-5606 


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