Subject: [Ecrit] Who has to support HELD/DHCP?

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Jun 2011 17:54:38 -0400

Pete Resnick has a DISCUSS on -phonebcp on AN-13/INT-14
 ED-21/INT-13 Devices MUST support both the Dynamic Host Configuration
   Protocol (DHCP) location options [RFC4776], [RFC3825] and HTTP
   Enabled Location Delivery (HELD) [RFC5985].  When devices deploy a
   specific access network interface for which location configuration
   mechanisms such as Link Layer Discovery Protocol - Media Endpoint
   Discovery (LLDP-MED) [LLDP-MED] or 802.11v are specified, the device
   SHOULD support the additional respective access network specific
   location configuration mechanism.

   AN-13/INT-14 The access network MUST support either DHCP location 
   options or HELD.   The access network SHOULD support other location 
  configuration technologies that are specific to the type of access network.

There are a couple of issues.  One is when a proxy is providing location.  In that case, it doesn't need HELD or DHCP.  Another is where there is an intermediary device.  The network doesn't have to support SIP/HELD if the intermediary does.  Another is where the network has a network specific LCP and requires all devices to support it; don't need SIP/HELD there either

What to do?

It would be a big rework to try to get all of this in there, but that may be the best thing to do.

I would
a) Change MUST to SHOULD in ED-21/INT-13 and add a sentence that says if the access network requires support of a specific LCP, the endpoint MUST support it.
b) Separate AN-13 from INT-14
c) Change AN-13 to say SHOULD support either, SHOULD support others, and MAY support only other(s) if it requires all devices and intermediary devices connected to the network to support that one.  MAY not provide LCP if all services that could place calls can have a proxy insert location.
d) Change INT-14 to say MUST support at least one of the LCPs the AN supports and must interwork to SIP or HELD.

Probably needs some text in -framework to match

This is a big change.  

The simplest change is to add in AN-13 "Where the AN is certain all services that could place emergency calls have proxys that can insert location of the endpoint, and it has relationships and compatible protocols implemented with all such services to provide location, it MAY rely on such proxies to provide location, rather than supply location to endpoints and intermediate devices".

Other ideas?

Brian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 20 Jun 2011 18:33:50 -0400

<hat type="individual" />

What's common to the three use cases you present is that they all assume some out of band coupling between one or more of the players in the ECRIT system.  In the "proxy adding" case, the proxy is coupled with the location server.  In the "walled garden" case, the endpoint is coupled with the network (at a deeper level than "using for IP access").

While in principle we could address these cases in ECRIT, you quickly run into a combinatorial explosion problem given all the possible agreements that the different actors could make.  So my inclination is to leave the problem alone altogether, or at most to say something general, e.g.:
"
This document assumes the general case where the end device, access network, and VoIP provider have no special association or configuration other than existing basic service relationships, i.e., the end device receiving IP service and VoIP service from the access network and VSP.  In cases where special arrangements exist, some interoperability requirements may not apply.  For example, a proxy that is provisioned with an up-to-date list of mappings between dial strings and PSAP URIs would not need to support LoST (see SP-25).  
"

--Richard

P.S.:

I thought we had this conversation before, and decided not to leave the loophole.  Quoth the minutes from IETF 73:
"
A Hum was taken in the room between a two-optioned approach to changes
in the existing text around which LCPs are “musts”.  The two options
for the Hum, Option 1.) which is to make the wording in phonebcp read,
“end points MUST implement both HELD and DHCP, and if the device is
an 802 wired device, it MUST implement LLDP.  Option 2.) is to change
text to as follows, “MUST implement both of HELD and DHCP, period.”,
(with any other LCPs mentioned, as a MAY.)  The results of the 2 Hums
were inconclusive – so chairs will take it to the list.
"
I haven't been able to track down a conclusive answer to the hums in the mailing list archives, but given that the room was OK with those two choices, it seems like *adding* additional options for LCPs was not really something that was supported.

On Jun 20, 2011, at 5:54 PM, Rosen, Brian wrote:

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

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 21 Jun 2011 11:49:07 +0800

I agree with approach and (most of) the wording.

The example isn't complete; at best the "would not need" is "wouldn't necessarily need". The dial strings may be insufficient and still require a geo-based resolution of the PSAP URI. I'd suggest that an example isn't necessary - example exceptions have a tendency to become a canonical exception.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Tuesday, 21 June 2011 8:34 AM
To: Rosen, Brian
Cc: [email-masked] Org
Subject: Re: [Ecrit] Who has to support HELD/DHCP?

--Richard

P.S.:

I thought we had this conversation before, and decided not to leave the loophole.  Quoth the minutes from IETF 73:
"
A Hum was taken in the room between a two-optioned approach to changes
in the existing text around which LCPs are "musts".  The two options
for the Hum, Option 1.) which is to make the wording in phonebcp read,
"end points MUST implement both HELD and DHCP, and if the device is
an 802 wired device, it MUST implement LLDP.  Option 2.) is to change
text to as follows, "MUST implement both of HELD and DHCP, period.",
(with any other LCPs mentioned, as a MAY.)  The results of the 2 Hums
were inconclusive - so chairs will take it to the list.
"
I haven't been able to track down a conclusive answer to the hums in the mailing list archives, but given that the room was OK with those two choices, it seems like *adding* additional options for LCPs was not really something that was supported.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 21 Jun 2011 10:26:08 -0400

How about:

"This document assumes the general case where the end device, access
network, and VoIP provider have no association or configuration other than
a common customer, i.e., the end device is receiving IP service from the
access provider and VoIP service from the VoIP provider.  In the case
where there is an association between the various service providers, some
interoperability requirements may not apply."

-Marc-

-----Original Message-----
From: "Dawson, Martin" <[email-masked]>
Date: Tue, 21 Jun 2011 11:49:07 +0800
To: "Richard L. Barnes" <[email-masked]>, "[email-masked] Org"
<[email-masked]>

>The example isn't complete; at best the "would not need" is "wouldn't
>necessarily need". The dial strings may be insufficient and still require
>a geo-based resolution of the PSAP URI. I'd suggest that an example isn't
>necessary - example exceptions have a tendency to become a canonical
>exception.
>
>Cheers,
>Martin
>
>What's common to the three use cases you present is that they all assume
>some out of band coupling between one or more of the players in the ECRIT
>system.  In the "proxy adding" case, the proxy is coupled with the
>location server.  In the "walled garden" case, the endpoint is coupled
>with the network (at a deeper level than "using for IP access").
>
>While in principle we could address these cases in ECRIT, you quickly run
>into a combinatorial explosion problem given all the possible agreements
>that the different actors could make.  So my inclination is to leave the
>problem alone altogether, or at most to say something general, e.g.:
>"
>This document assumes the general case where the end device, access
>network, and VoIP provider have no special association or configuration
>other than existing basic service relationships, i.e., the end device
>receiving IP service and VoIP service from the access network and VSP.
>In cases where special arrangements exist, some interoperability
>requirements may not apply.  For example, a proxy that is provisioned
>with an up-to-date list of mappings between dial strings and PSAP URIs
>would not need to support LoST (see SP-25).
>"
>
>--Richard
>
>
>P.S.:
>
>I thought we had this conversation before, and decided not to leave the
>loophole.  Quoth the minutes from IETF 73:
>"
>I haven't been able to track down a conclusive answer to the hums in the
>mailing list archives, but given that the room was OK with those two
>choices, it seems like *adding* additional options for LCPs was not
>really something that was supported.
>
>
>
>
>> There are a couple of issues.  One is when a proxy is providing
>>location.  In that case, it doesn't need HELD or DHCP.  Another is where
>>there is an intermediary device.  The network doesn't have to support
>>SIP/HELD if the intermediary does.  Another is where the network has a
>>network specific LCP and requires all devices to support it; don't need
>>SIP/HELD there either
>> 
>> What to do?
>> 
>> a) Change MUST to SHOULD in ED-21/INT-13 and add a sentence that says
>>if the access network requires support of a specific LCP, the endpoint
>>MUST support it.
>> c) Change AN-13 to say SHOULD support either, SHOULD support others,
>>and MAY support only other(s) if it requires all devices and
>>intermediary devices connected to the network to support that one.  MAY
>>not provide LCP if all services that could place calls can have a proxy
>>insert location.
>> d) Change INT-14 to say MUST support at least one of the LCPs the AN
>>supports and must interwork to SIP or HELD.
>> 
>> The simplest change is to add in AN-13 "Where the AN is certain all
>>services that could place emergency calls have proxys that can insert
>>location of the endpoint, and it has relationships and compatible
>>protocols implemented with all such services to provide location, it MAY
>>rely on such proxies to provide location, rather than supply location to
>>endpoints and intermediate devices".
>> 
>> Other ideas?
>> 
>> Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 22 Jun 2011 10:07:51 +0800

Yes; that's what I was thinking. Succinct.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Wednesday, 22 June 2011 12:26 AM
To: [email-masked]
Subject: Re: [Ecrit] Who has to support HELD/DHCP?

How about:

-Marc-

-----Original Message-----
From: "Dawson, Martin" <[email-masked]>
Date: Tue, 21 Jun 2011 11:49:07 +0800
To: "Richard L. Barnes" <[email-masked]>, "[email-masked] Org"
<[email-masked]>