Subject: [Ecrit] Comments on draft-rosen-sos-phonebcp-01

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 7 Jul 2006 13:25:44 -0500

I've sort of gone through the document and have comments mostly centered around sections 3 and 4 on "Which devices and services should support emergency calls" and "Determining location". Brian, if you want me to try to turn any of these comments into sample text, please let me know.

Section 3 only discusses endpoints that can initiate calls. But the other sections go on to provide requirements for DHCP servers, proxies, and other devices, in addition to just endpoints. If this document is intended to provide recommendations for all these devices, then I'd like to see all of these categories of devices described as having a role.

I think it might be useful to have a section (or subsection) on (1) devices that should be involved in location determination, (2) devices that should be involved in determining an emergency call, and (3) devices that should actively participate in emergency call signaling. This would match the sections 4-6, so that requirements can be called out in each of these sections for the various device types.

In the "Determining Location" section, there seem to be requirements for endpoints, "network attachment" devices, devices with DHCP servers in them, and un-named intermediate devices which need to support some method of providing more accurate location (where DHCP Relay is one such method). 

And then there's a requirement for networks that don't control the specification of endpoint devices. This says that all such networks must support DHCP. I'm not sure what all sorts of networks this is supposed to refer to, but I was wondering if it would be better to describe the devices that would be used in such networks, and put requirements on them, instead of the network as a whole.

So, if I were to translate some of the paragraphs to be listed requirements for devices, I think it might be like:

The following requirements apply to devices that are intended to be operated on a network where the network operator does not control the specification of every device connected to the network.

Endpoint device
 1. If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>. [Are both a must? Is it ok to support one and not the other in certain types of devices? If both are a must, is there 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>. [Note this doesn't require support of LLDP-MED; I believe that if LLDP-MED is going to be put in devices and deployed in networks, it has to be for more reasons that just location determination; therefore, I don't think it's appropriate to require LLDP-MED in this BCP.]
 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 <dhcp-civil>, 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. I'd also like to see recommendations on interactions of the various L7 server discovery mechanisms

Devices with DHCP servers
 1. The DHCP server MUST support RFC 3825 and <dhcp-civil>. 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>. [Again, this does not mean LLDP-MED is required -- only that if it is implemented, it needs to be implemented per 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.

Un-named intermediate devices which need to support some method of providing more accurate location (where DHCP Relay is one such method)
 1. I'm really not sure what these devices are, or what the requirements are.

Barbara

*****

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. 118

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

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 07 Jul 2006 13:41:51 -0500

Barbara

I think most of your comments below are good comments - from a peeling back 
the layers of the onion pov - and should be interleaved into this doc.  As 
this happens, more gaps will be discovered.

Thank you for taking the time to do this analysis.

At 01:25 PM 7/7/2006 -0500, Stark, Barbara wrote:
>Content-Transfer-Encoding: 7bit
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6A1F2.C2D3805A"
>
>I've sort of gone through the document and have comments mostly centered 
>around sections 3 and 4 on "Which devices and services should support 
>emergency calls" and "Determining location". Brian, if you want me to try 
>to turn any of these comments into sample text, please let me know.
>
>Section 3 only discusses endpoints that can initiate calls. But the other 
>sections go on to provide requirements for DHCP servers, proxies, and 
>other devices, in addition to just endpoints. If this document is intended 
>to provide recommendations for all these devices, then I'd like to see all 
>of these categories of devices described as having a role.
>
>I think it might be useful to have a section (or subsection) on (1) 
>devices that should be involved in location determination, (2) devices 
>that should be involved in determining an emergency call, and (3) devices 
>that should actively participate in emergency call signaling. This would 
>match the sections 4-6, so that requirements can be called out in each of 
>these sections for the various device types.
>
>In the "Determining Location" section, there seem to be requirements for 
>endpoints, "network attachment" devices, devices with DHCP servers in 
>them, and un-named intermediate devices which need to support some method 
>of providing more accurate location (where DHCP Relay is one such method).
>
>And then there's a requirement for networks that don't control the 
>specification of endpoint devices. This says that all such networks must 
>support DHCP. I'm not sure what all sorts of networks this is supposed to 
>refer to, but I was wondering if it would be better to describe the 
>devices that would be used in such networks, and put requirements on them, 
>instead of the network as a whole.
>
>So, if I were to translate some of the paragraphs to be listed 
>requirements for devices, I think it might be like:
>
>The following requirements apply to devices that are intended to be 
>operated on a network where the network operator does not control the 
>specification of every device connected to the network.
>
>Endpoint device
>  1. If the device has a DHCP client, the client MUST support RFC 3825 and 
> <dhcp-civil>. [Are both a must? Is it ok to support one and not the other 
> in certain types of devices? If both are a must, is there 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>. [Note this doesn t 
> require support of LLDP-MED; I believe that if LLDP-MED is going to be 
> put in devices and deployed in networks, it has to be for more reasons 
> that just location determination; therefore, I don t think it s 
> appropriate to require LLDP-MED in this BCP.]
>
>  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 <dhcp-civil>, 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?]
>
>    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. I d also like to see recommendations on interactions of the various 
> L7 server discovery mechanisms
>
>  1. The DHCP server MUST support RFC 3825 and <dhcp-civil>. 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>. 
> [Again, this does not mean LLDP-MED is required -- only that if it is 
> implemented, it needs to be implemented per the spec.]
>
>  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.
>
>  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.
>
>Un-named intermediate devices which need to support some method of 
>providing more accurate location (where DHCP Relay is one such method)
>
>  1. I m really not sure what these devices are, or what the requirements 
> are.
>
>Barbara
>
>*****
>
>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. 118