Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 11 Jul 2006 19:43:26 -0500

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.":
 
If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>. 
   and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>. 
 
Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec.
 
Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that:
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).
 
Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]]
Sent: Friday, June 30, 2006 9:44 AM
To: Rohan Mahy
Cc: Rosen, Brian; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:

To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. 

Just throwing in my $0.0199997, I have not formed a strong opinion about this either.  It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses.

Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

-andy

*****

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

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 11 Jul 2006 22:38:51 -0500

I would be very cautious about recommending the use of RFC-3825 encoding
to report emergency locations given the issues raised at IETF-65 in
Dallas that are yet to be adequately resolved. In NENA we put a caveat
around its use to the effect that location provided in this manner must
be regarded as a point only, and that encodings for resolution must be
ignored.

Cheers

James

*****

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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 12 Jul 2006 09:34:00 -0400

As stated in RFC3825, it is applicable to non-mobile environments.
 
-Marc-

  _____  

From: Winterbottom, James [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 11:39 PM
To: Stark, Barbara; Andrew Newton; Rohan Mahy
Cc: Rosen, Brian; [email-masked]
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

I would be very cautious about recommending the use of RFC-3825 encoding to
report emergency locations given the issues raised at IETF-65 in Dallas that
are yet to be adequately resolved. In NENA we put a caveat around its use to
the effect that location provided in this manner must be regarded as a point
only, and that encodings for resolution must be ignored.

Cheers

James

----------------------------------------------------------------------------
--------------------
----------------------------------------------------------------------------
--------------------
[mf2] 

*****

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 12 Jul 2006 16:23:45 -0500

Marc, this has nothing to do with mobile. It is to do with the potential
for massive errors to be introduced by the encoding technique used in
RFC-3825. Please see appendix A of PIDF-LO profile for more details.

________________________________

From: Marc Linsner [mailto:[email-masked]] 
Sent: Wednesday, 12 July 2006 11:34 PM
To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy'
Cc: 'Rosen, Brian'; [email-masked]
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

-Marc-

________________________________

	I would be very cautious about recommending the use of RFC-3825
encoding to report emergency locations given the issues raised at
IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put
a caveat around its use to the effect that location provided in this
manner must be regarded as a point only, and that encodings for
resolution must be ignored.

	Cheers

	James

	
------------------------------------------------------------------------
------------------------
	This message is for the designated recipient only and may
	contain privileged, proprietary, or otherwise private
information. 
	If you have received it in error, please notify the sender
	immediately and delete the original. Any unauthorized use of
	this email is prohibited.
	
------------------------------------------------------------------------
------------------------
	[mf2] 

	*****

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

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 12 Jul 2006 19:21:57 -0400

Please identify the non-mobile application(s) that use geo and are required
to convey uncertainty.
 
-Marc-

Marc, this has nothing to do with mobile. It is to do with the potential for
massive errors to be introduced by the encoding technique used in RFC-3825.
Please see appendix A of PIDF-LO profile for more details. 

  _____  

-Marc-

  _____  

Cheers

James

*****

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 12 Jul 2006 18:35:19 -0500

Marc you are missing the point entirely.

No one is required to convey uncertainty, but RFC-3825 stipulates quite
clearly how the values returned in option 123 are to be interpreted.

The shape described by the encoding in RFC-3825 is either a 4 sided
polygon, or a prism, unless you use the maximum resolution, hence
uncertainty is part of the interpretation and mobility 

has absolutely nothing to do with it.

Are you suggesting that the way to interpret the values in RFC-3825 is
not normative?

From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 13 July 2006 9:22 AM
To: Winterbottom, James
Cc: [email-masked]
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

Please identify the non-mobile application(s) that use geo and are
required to convey uncertainty.

-Marc-

	Marc, this has nothing to do with mobile. It is to do with the
potential for massive errors to be introduced by the encoding technique
used in RFC-3825. Please see appendix A of PIDF-LO profile for more
details. 

	

	To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton';
'Rohan Mahy'

	As stated in RFC3825, it is applicable to non-mobile
environments.

	-Marc-

		From: Winterbottom, James
[mailto:[email-masked]] 
		Sent: Tuesday, July 11, 2006 11:39 PM
		To: Stark, Barbara; Andrew Newton; Rohan Mahy
		Cc: Rosen, Brian; [email-masked]
		Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

		I would be very cautious about recommending the use of
RFC-3825 encoding to report emergency locations given the issues raised
at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we
put a caveat around its use to the effect that location provided in this
manner must be regarded as a point only, and that encodings for
resolution must be ignored.

		Cheers

		James

	
------------------------------------------------------------------------
------------------------
		This message is for the designated recipient only and
may
		contain privileged, proprietary, or otherwise private
information. 
		If you have received it in error, please notify the
sender
		immediately and delete the original. Any unauthorized
use of
		this email is prohibited.

		*****

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