Subject: [Ecrit] Comments on [draft-ietf-ecrit-phonebcp-00.txt]

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 11 Jan 2007 13:36:55 -0500

General Comments
phonebcp has requirements for end devices, proxies, and PSAPs. It would be useful if there were some way to easily distinguish which requirements applied to which elements, such as specific subsections for the different elements, or by numbering the requirements, with a separate numbering scheme for each element. I would like to be able to use this document by telling vendors that they must comply with it. I would want to tell proxy vendors they must comply with the proxy requirements, and SIP endpoint vendors that they must comply with the SIP endpoint requirements. The easier it is for them to locate all the individual requirements that apply, the greater the likelihood that they will successfully comply. I'm happy to help with this, in any way.

I also believe this document needs considerably more detail. Some specifics on this are at the end of this email, along with an offer to help write some of those specifics. In general, I would like to see this document provide specifications at a level so that device behavior is highly consistent and predictable between different vendors.

Specific Comments
Section 2
Numbered list, number 2 
It really doesn't matter whether the user dialed a "visited" or "home" number, so long as the number is recognized by the device as an emergency number. Could this be genericized to say "User dials an emergency number that is known to the device."?

Bullet list, 3rd bullet
When I read "as the uri of an emergency call", this suggested "Request-URI" to me. But Section 6.1 says this would be the uri in "To:". There are just so many URIs in SIP Invite. Could this be made more explicit to say "as the "To:" uri of an emergency call"?
4th bullet
And say that the PSAP's URI is the "Request-URI". I think it's also important to note that the LoST query validated the location.

Section 4
2nd paragraph
[editorial] expand "LCPs" acronym

[editorial] 3rd and 7th paragraphs are redundant; 4th and 8th are also effectively redundant. Recommend deleting 3rd paragraph, and merging the best parts of 4 and 8.

I have grave concerns over the mandating of LLDP in consumer products, and will address this in a separate email. I realize LLDP has been discussed before, but I don't think it was fully resolved.

Section 6.1
Item 1
The initial SHOULD statement is too weak. I would prefer "If the device recognizes the dialstring as an emergency call, and it successfully gets a uri as a response to a LoST query, then it MUST place that uri in the Request-URI. If the device recognizes the call as an emergency call, but does not succeed in getting a uri from a LoST query, then it MUST place an "sos" service URN in the Request-URI. [I assume that the reference to the "To:" field for the "sos" service urn should have been "Request-URI".]
I appreciate the purpose of draft-rosen-iptel-dialstring-04, but I'm not sure it's really appropriate or needed as a requirement in this bcp. That is, devices will continue to format dial strings just as they always have (e.g., sip:[email-masked]), unless VSPs adopt the changes recommended in the referenced draft. And it's not at all clear to me when those changes will happen. I recommend saying that "If the device cannot do local dialstring interpretation, then it is expected that the device will place the dialed digits in the Request-URI, consistent with the expectations of its VSP's proxy."

Item 2
The "SHOULD" statement regarding the service URN is too weak. Stating that "To:" must be present seems unnecessary to me, since RFC 3261 already requires it. I would prefer: 
If the device recognizes the dial string as an emergency number, it MUST place an "sos" service URN in the To: header. sips MUST be specified ... TLS connection. If the device does not recognize the dial string, it is expected that the device will place the dialed digits in the To: header, consistent with the expectations of its VSP's proxy.

Item 3
[editorial] Expand "AoR"

RFC 3261 requires From:. The MUST statement seems redundant.
How is this requirement intended to modify the requirements of RFC 3261, in which AoR in To: is effectively a "MAY" ("possibly" is the exact word used), and where it is explicit that "Anonymous" with a meaningless URI is perfectly ok? 

Item 4
RFC 3261 requires Via:, and it frequently has the local IP address and port of the device. This requirement is suggesting it should be something else? 

Item 5
Need to include reference (draft-rosenberg-sip-ua-loose-route-00) for loose route parameter? I didn't have a clue what a loose route parameter was.

References
[editorial] update dhcp-civil reference to RFC 4676, here and in document text.

-------------------------------------------
What I think is missing
---------------------------------
I'm happy to provide text for any of these items. The way I see it, if it isn't in phonebcp, I'm going to have to write it anyway, either to go into a document at another standards body, or for the company I'm with to be able to provide requirements to its equipment vendors.

Per the framework document, this phonebcp needs to address what happens when it receives multiple locations.

Requirements for multipart (per the discussion on the email reflector)

Expanded requirements on the disabling of features. For example, instead of simply listing "Outbound Call Blocking", it might be better to say "The calling device MUST NOT apply any outbound call blocking rules to dial strings or URIs that are defined in the device as emergency dial strings or URIs." In many cases, these features are frequently provided out of a VSP features server. Therefore, requirements for disabling of features need to be written for VSP features, as well as calling device features.

Requirements for routers that may have VoiP behind them

Considerably more detail on location determination. Here is a slightly updated version of what I sent previously:
Endpoint device
 1. If the device has a DHCP client, the client MUST support RFC 3825 and RFC 4676. [There is an expectation that the responding DHCP server has the intelligence to respond to only one or the other.]
   a. If the device is configured to use DHCP for bootstrapping, it MUST include both options in its DHCP REQUEST.
   b. When this device initiates an emergency call (see section on requirements for recognizing emeregency calls), it MUST send a DHCP INFORM message to refresh the location information. [Should it only use the option that was previously successful?]
 2. If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.
 3. The device MUST support whatever L7 mechanism we come up with.
 4. The device MUST support certain discovery mechanisms for finding that L7 server.
    a. Server discovery MUST be done before any VPNs are initiated.
 5. If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and RFC 4676, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).
   a. If the device is configured to request location through DHCPINFORM, then it MUST include both options in a DHCP INFORM message sent shortly after bootstrap, and before any VPN sessions are initiated.
   b. When this device initiates an emergency call (see section on requirements for recognizing emeregency calls), it MUST send a DHCP INFORM message to refresh the location information. [Should it only use the option that was previously successful?]
 6. Interactions of the various methods
   a. If a device receives location information from both LLDP-MED and DHCP which takes precedence?
   b. If a device successfully receives location information through either DHCP or LLDP-MED, it MUST NOT request a location through the L7 mechanism.
7. Location from embedded GPS?
8. Handling of multiple locations? 
9. The device MUST discover a LoST server. [This needs more detail, as to precisely which steps to take, and how to determone which steps to take.]
10. The device MUST do a LoST query, using its location, for each "sos" URI that is known to it.

Devices with DHCP servers
 1. The DHCP server MUST support RFC 3825 and RFC 4676. The device MUST be configurable to respond to either 0 (zero) or 1 of these options. The device MUST NOT allow both options to be enabled simultaneously.
 2. If the device supports LLDP-MED, it MUST meet the requirements of an LLDP-MED Network Connectivity Device, as defined in <LLDP-MED reference>. This is NOT a requirement for the device to support LLDP-MED -- only a requirement that if LLDP-MED is implemented, it must be done according to the spec.
 3. We might want to require this device to participate in some of the L7 server discovery mechanisms. 
 4. If the device has a WAN interface, it MUST meet requirements 1, 3, 5, 6, and 7 of the Endpoint device, over that WAN interface.
 5. A different set of L7 server discover mechanisms will probably need to be recommended.
 6. Do we want to require the device to be able to translate an L7 response on the WAN side to a DHCP response to LAN devices? Should this occur automatically?
 7. If the device receives location information via DHCP on its WAN interface, it MUST automatically configure itself to pass this information on to LAN-side devices that request it.
8. Does this device have a role in LoST discovery?

Barbara Stark
BellSouth Science & Technology (a recently acquired part of AT&T)

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622

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