Subject: [Geopriv] I-D ACTION:draft-ietf-geopriv-http-location-delivery-00.txt

From: [email-masked]
Date: Fri, 08 Jun 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title		: HTTP Enabled Location Delivery (HELD)
	Author(s)	: M. Barnes
	Filename	: draft-ietf-geopriv-http-location-delivery-00.txt
	Pages		: 40
	Date		: 2007-6-8
	
   A Layer 7 Location Configuration Protocol (L7 LCP) is described that
   is used for retrieving location information from a server within an
   access network.  The protocol includes options for retrieving
   location information either by-value or by-reference.  The protocol
   supports mobile and nomadic devices through Location URIs.  The
   protocol is an application-layer protocol that is independent of
   session-layer; an HTTP, web services binding is specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-geopriv-http-location-delivery-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 8 Jun 2007 16:26:15 -0400

We should probably revisit some of the discussions we've had for  
LoST, which have led us to abandon the concept of status codes in  
favor of "real" XML. I won't repeat the arguments (Andy can chime  
in...), but the basic idea was that this makes debugging and  
validation easier and seems much more in the spirit of XML. Using  
codes that are almost, but not quite, the same as HTTP (or SIP) seems  
to be an invitation for confusion or creative extensions where HTTP  
codes are "borrowed".

I'm also unconvinced that creating a non-namespace extensions  
mechanism (options) is a good idea. Either we use XML and its tools  
or we make up our own protocol, but a hybrid seems dubious  
architecturally. IANA can register namespaces, too.

The editor may want to take a look at the identity mechanisms in  
RELO. It is currently not clear how entities are identified and how  
this is extensible.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 08 Jun 2007 15:53:45 -0500

>         Filename        : draft-ietf-geopriv-http-location-delivery-00.txt

I think it best to rename this to something other than "HELD".  I'm 
sure to get flamed from some for this suggestion. However, there are 
many that know the old HELD - and want to hang on to those 
capabilities (some of which are not in this document).  It seems less 
confusing to me to get every up on a new name (therefore a mental 
reset of what *this* is) vs. having the (probable) endless 
discussions about assumptions that what previous IDs called HELD is 
not in the current version of HELD, the latter of which is the one 
moving forward.

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 8 Jun 2007 18:39:58 -0500

Hi Henning,

I have no concerns about changing the message codes.
I am not sure that I see too many issues with the options extension,
though as you point out, adding attributes and using their namespace for
qualifying them is the norm within XML.

I find it hard to believe that you can't see how the identity extensions
aren't provided. Please look at
http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-exte
nsions-01 It has after all only be presented a couple of time now.

This is as opposed to something proprietary like Cisco Discovery
Protocolas RELO suggests.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, 9 June 2007 6:26 AM
> To: GEOPRIV
> Subject: Re: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-
> delivery-00.txt
> 

------------------------------------------------------------------------------------------------
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: [email-masked]
Date: Mon, 11 Jun 2007 12:40:39 -0400

[removing internet-drafts and i-d-announce from the list ...]

I tend to agree with James.  If there's a mental reset required, then the 
naming should reflect it.  It would help to keep us from getting mired. 

-- Peter

"James M. Polk" <[email-masked]>
08.06.07 16:53
 
        To:     [email-masked], [email-masked]
        cc:     [email-masked]
        Subject:        Re: [Geopriv] I-D 
ACTION:draft-ietf-geopriv-http-location-delivery-00.txt

At 02:50 PM 6/8/2007, [email-masked] wrote:
>         Filename        : 
draft-ietf-geopriv-http-location-delivery-00.txt

---

From: [email-masked]
Date: Mon, 11 Jun 2007 13:03:13 -0400

Hi, 

Hoping I'm not about to step on a land mine ...

>  .. as opposed to something proprietary like Cisco Discovery
> Protocolas RELO suggests

While I don't think specifying something proprietary would be a good thing 
(bad actually -- I would oppose CDP), I just wanted to point out the RELO 
actually talks about several possible ids, not just CDP.  RELO also 
mentions MAC address, LLDP (by extension LLDP-MED would be there also), 
and mentions all in the context of "such as" which I read to mean "for 
example".  So, I do not surmise that the intent was to propose 
"proprietary" solution, as alluded below. 

The held-identity-extensions draft also talks about LLDP.  In both RELO 
and held-identity-extensions, in presence of LLDP, I fail to see why the 
L7 protocol would be used at all in general practice.  If the switching 
environment supports LLDP / LLDP-MED, then why not use it to directly 
supply the location objects.  Adding the L7 moving parts would make things 
less reliable in those cases.  (I can see how there might be cases where 
L7 is needed, however do not see it for the general rule.  In those cases, 
supplying these ids may add value.) 

-- Peter

"Winterbottom, James" <[email-masked]>
08.06.07 19:39
 
        To:     "Henning Schulzrinne" <[email-masked]>, "GEOPRIV" 
<[email-masked]>
        cc: 
        Subject:        RE: [Geopriv] 
I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Henning,

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 11 Jun 2007 17:35:03 -0500

Hi Peter,

What would you do in network configurations that support LLDP but not
LLDP-MED, of which I suspect there are many?

Cheers

James

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 12 June 2007 3:03 AM
To: Winterbottom, James
Cc: GEOPRIV; Henning Schulzrinne
Subject: RE: [Geopriv]
I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi, 

>  .. as opposed to something proprietary like Cisco Discovery

While I don't think specifying something proprietary would be a good
thing (bad actually -- I would oppose CDP), I just wanted to point out
the RELO actually talks about several possible ids, not just CDP.  RELO
also mentions MAC address, LLDP (by extension LLDP-MED would be there
also), and mentions all in the context of "such as" which I read to mean
"for example".  So, I do not surmise that the intent was to propose
"proprietary" solution, as alluded below.   

The held-identity-extensions draft also talks about LLDP.  In both RELO
and held-identity-extensions, in presence of LLDP, I fail to see why the
L7 protocol would be used at all in general practice.  If the switching
environment supports LLDP / LLDP-MED, then why not use it to directly
supply the location objects.  Adding the L7 moving parts would make
things less reliable in those cases.  (I can see how there might be
cases where L7 is needed, however do not see it for the general rule.
In those cases, supplying these ids may add value.)   

-- Peter 

08.06.07 19:39 

        To:        "Henning Schulzrinne" <[email-masked]>,
"GEOPRIV" <[email-masked]> 
        cc:         
        Subject:        RE: [Geopriv]
I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Henning,

Cheers
James

> RELO. It is currently not clear how entities are identified and how

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

---

From: [email-masked]
Date: Thu, 14 Jun 2007 13:27:39 -0400

(oops, seem to have missed this one going by...)

Upgrade.  Seriously, any of the location proposals will require upgrades, 
so it is really a matter of where, not if.  (Note I do not work for a 
networking vendor, so have no direct interest in network upgrades other 
than to make the deployment job easier, ongoing admin and TCO lower, and 
ECS more reliable.) 

A corresponding questions to either L7 or DHCP methods is how would you 
get the wiremap data (ultimately L2 chassis/port ids and corresponding 
physical locations) into the server?  How to maintain it when things 
change at L2?  What's the standard interface for doing those important 
steps? 

>> Hoping I'm not about to step on a land mine ... 
Please Note: I'm trying not to ignite a battle of methods here!  Though 
quite aware it could happen.  Original intent was to just point out that 
RELO did not really appear to be pointing to anything proprietary.  But 
thinking about it led me to wondering: in the presence of LLDP/LLDP-MED 
why it would not just be used directly, instead of indirectly through more 
moving parts.  Each of the methods has its place. 

-- Peter

11.06.07 18:35
 
        To:     <[email-masked]>
        cc:     "GEOPRIV" <[email-masked]>, "Henning Schulzrinne" 
<[email-masked]>
        Subject:        RE: [Geopriv] 
I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Peter,

Cheers
James

Hi, 

-- Peter 

        

Hi Henning,

Cheers
James

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 14 Jun 2007 13:00:48 -0500

Henning,

Sorry for the delay in replying -  my email server has not been
cooperative this week.

Thanks for the feedback. I've got some brief comments below [MB] and one
question on your last point.  

Mary

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 3:26 PM
To: GEOPRIV
Subject: Re: [Geopriv] I-D

We should probably revisit some of the discussions we've had for  
LoST, which have led us to abandon the concept of status codes in  
favor of "real" XML. I won't repeat the arguments (Andy can chime  
in...), but the basic idea was that this makes debugging and  
validation easier and seems much more in the spirit of XML. Using  
codes that are almost, but not quite, the same as HTTP (or SIP) seems  
to be an invitation for confusion or creative extensions where HTTP  
codes are "borrowed".
[MB] It does seem reasonable to consider the approach you suggest. But,
unless someone
strongly disagrees, we can make that change. [/MB]

[MB] Also a valid point and something we can consider for the next
version. [/MB]

The editor may want to take a look at the identity mechanisms in  
RELO. It is currently not clear how entities are identified and how  
this is extensible.
[MB] Per James W.'s response, I will clarify this.  There had previously
been a reference to the 
document that James W highlighted, so I think the problem is that I
removed that reference and likely should add some more explanatory text.
Or, are you suggesting that we need more normative text in the body of
the document somewhere (since that discussion is in the appendix that
summarizes how this doc meets the requiremetns)?  [/MB]

Henning

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 14 Jun 2007 13:01:39 -0500

I've changed the title so that we can better track any additional
feedback on this topic. 

I've seen Peter's response, as well, agreeing with this idea and I don't
see a problem with  changing the name to something that might be deemed
more neutral, yet still descriptive.  

Putting creativity aside (i.e., my initial suggestions don't have a cute
acronym), I'd suggest the new title as "Layer 7 Location Retrieval
Protocol (L7LRP)" or "HTTP Enabled Location Retrieval (HELR)".  

Any other suggestions? 

Mary

---

From: <[email-masked]>
Date: Thu, 14 Jun 2007 14:13:55 -0400

Hi Mary,

I personally don't see what good changing the name will do actually. HELD is perfectly fine as far as I'm concern.

And since it may have been referenced in other venues, it may be preferable to stick with HELD.

Thanks,

Guy Caron
-----Message d'origine-----
De : Mary Barnes [mailto:[email-masked]] 
Envoyé : 14 juin 2007 14:02
À : James M. Polk
Cc : [email-masked]
Objet : [Geopriv] draft-ietf-geopriv-http-location-delivery-00.txt -Title/Name of Protocol

Any other suggestions? 

Mary

---

From: [email-masked]
Date: Thu, 14 Jun 2007 14:24:43 -0400

Thanks,
HTTP Emergency Location Protocol (HELP) ?  ;-)     It too bad LoST is 
taken ...
-- Peter

"Mary Barnes" <[email-masked]>
14.06.07 14:01
 
        To:     "James M. Polk" <[email-masked]>
        cc:     [email-masked]
        Subject:        [Geopriv] 
draft-ietf-geopriv-http-location-delivery-00.txt -      Title/Name of 
Protocol

Any other suggestions? 

Mary

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 14 Jun 2007 14:57:17 -0400

Oddly, I'm in favor of keeping the name.  We selected this protocol from the
candidates.  It may get modified in the normal course of the IETF process,
but it was supposed to be what we wanted.  The consensus was for HELD, and
HELD is what it should be.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 14, 2007 2:14 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] draft-ietf-geopriv-http-location-delivery-00.txt-
> Title/Name of Protocol
> 
> Hi Mary,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Jun 2007 16:02:22 -0400

> summarizes how this doc meets the requiremetns)?  [/MB]

The document needs to be able to stand alone, thus, it needs some  
indicator of how other namespaces can be accommodated, whether this  
indication is by reference or by value. I think this need to describe  
both the namespaces of interest and how to define new ones (e.g., is  
that an IANA consideration?)

Also, the current document doesn't seem to actually state explicitly  
that the lookup is supposed to be based on the IP address of the  
client. That general logic needs to be explained, so that the  
extensions to other explicit identifiers make sense.

At this point, we may not have enough consensus or experience to  
define other identifiers, so it might be best to avoid referencing an  
external document, as this would be a normative, and thus delaying,  
reference.

Henning

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Jun 2007 21:07:31 -0500

Hi Peter,

In LLDP-MED, the device are going to learn this stuff from SNMP, or at
least that is what the documents I have read in the past suggested, so
isn't this simply a wiremap database that needs to be kept in synch with
what changes at L2 as well?

Cheers

James

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 15 June 2007 3:28 AM
To: Winterbottom, James
Cc: GEOPRIV; Henning Schulzrinne
Subject: RE: [Geopriv]
I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Upgrade.  Seriously, any of the location proposals will require
upgrades, so it is really a matter of where, not if.  (Note I do not
work for a networking vendor, so have no direct interest in network
upgrades other than to make the deployment job easier, ongoing admin and
TCO lower, and ECS more reliable.)   

Please Note: I'm trying not to ignite a battle of methods here!  Though
quite aware it could happen.  Original intent was to just point out that
RELO did not really appear to be pointing to anything proprietary.  But
thinking about it led me to wondering: in the presence of LLDP/LLDP-MED
why it would not just be used directly, instead of indirectly through
more moving parts.  Each of the methods has its place.   

-- Peter 

11.06.07 18:35 

Hi Peter, 

Cheers 
James 

Hi, 

-- Peter 

08.06.07 19:39 

Hi Henning,

Cheers
James

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 14 Jun 2007 21:09:28 -0500

Strangely I agree with Brian.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Friday, 15 June 2007 4:57 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv]draft-ietf-geopriv-http-location-delivery-00.txt-
> Title/Name ofProtocol
> 
> > I personally don't see what good changing the name will do actually.
> HELD
> > is perfectly fine as far as I'm concern.
> >

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 15 Jun 2007 07:12:04 -0500

HELD is already gaining widespread use in the terminology, so why change something that some folks are just not getting their arms around? HELD should not be changed.

Marc Berryman, ENP
Geographic Information Systems
Greater Harris County 9-1-1 Emergency Network
Houston, Texas      (713) 407-2254
[email-masked]

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, June 14, 2007 1:57 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv]draft-ietf-geopriv-http-location-delivery-00.txt-Title/Name ofProtocol

Brian

---

From: [email-masked]
Date: Fri, 15 Jun 2007 14:11:02 -0400

Hi again,

> In LLDP-MED, the device are going to learn this stuff from SNMP ...

Correct, where "device" here is the Network Connectivity Device (ie L2 
switch), not the endpoint.  Endpoint does not need to support SNMP (can if 
it wants).  The switching infrastructure *can*, usually would, use SNMP in 
the process, but does not absolutely need to (read on). 

> ... so isn’t this simply a wiremap database that needs to be kept in 
synch with what changes at L2 as well? 

Yes, the wiremap dB does need to be kept in synch with L2 changes in *any* 
of the methods. 

In the LLDP / LLDP-MED based case, the interface to do this is well 
defined today (SNMP MIBs). 

In a pretty real sense, the switching infrastructure itself can be 
considered as the "database" since all the information is actually held in 
the edge switches -- and where the least moving parts aspect comes in is 
that's the box on the other end of the physical wire from the phone. 
Changes can be made directly at the switch side, and re-synched with a 
master dB in the higher level management system by SNMP polling, or 
changes can be made in the management system side and pushed to the 
switching infrastructure using SNMP.  Mismatches can also be detected by 
noticing that info read from the switch side does not match the management 
system side.  Either works, or mixture of both, and which is used I would 
expect to be a matter of system scale and operational preference.  Small 
systems (a few L2 switches) need no master dB or higher order management 
system at all -- it can readily all be done directly on the L2 boxes. 

-- Peter

14.06.07 22:07

Hi Peter,
 
In LLDP-MED, the device are going to learn this stuff from SNMP, or at 
least that is what the documents I have read in the past suggested, so 
isn’t this simply a wiremap database that needs to be kept in synch with 
what changes at L2 as well?

Cheers
James

-- Peter 

        

Hi Peter, 

Cheers 
James 

Hi, 

-- Peter 

        

Hi Henning,

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 16 Jun 2007 10:34:07 -0500

Ah... I haven't met a network admin yet who would prefer to manage their network data in each individual end-point versus having a common management database. That's even where there's only a couple of switches.

When it comes to location, managing a database with a consistent (Switch-ID + Switch-port -> Location) schema is much simpler then dealing with the vendor specific mechanisms for managing the switch. That's why SNMP is popular after all.

In terms of device capability, a network based location protocol like HELD can take advantage of a vanilla LLDP device because the switch port information can be sent to the LIS which has the location data to reference against. You don't need LLDP-MED to do that. You also don't really need LLDP to be used by the device because the LIS can learn the device to switch port association using many mechanisms including SNMP bridge MIB polling, DHCP-relay, DHCP lease query. That's before we get to the point where there's a generic framework for network devices to report location-related network parameters to the LIS. The NGES working group in ESIF are currently looking at formalising this using the LIS-ALE (FLAP) definition as a starting point. However, LLDP is nevertheless also a valid option.

Yes, all these things work to provide at least basic location information and any given implementer has the option of using the approach that works best for them. However, it is better if devices can interact with access networks in the same way regardless of access technology - and not have to "know" it should be using LLDP-MED at this particular moment. When more sophisticated functionality (such as location signing, assertion, and location-by-reference) are required the L2 mechanisms also break down.

Which brings me to a point I probably should have made at the beginning; the current topic on the thread started with the suggestion that while the identity extension draft mentioned LLDP, should it not also include LLDP-MED? The sense in which LLDP is pertinent is that it can be used to get a "transient identity component"; a switch/switchPort value for example. This information can be used to determine location. I assume LLDP-MED is raised because it provides a means to obtain location directly. However, "location as an identity component from which location can be determined" doesn't really fit with the identity-extensions. It more fits with the legion of alternative ways to get location in the first place.

Cheers,
Martin

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, 16 June 2007 4:11 AM
To: Winterbottom, James
Cc: GEOPRIV; Henning Schulzrinne
Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi again, 

> In LLDP-MED, the device are going to learn this stuff from SNMP ... 

Correct, where "device" here is the Network Connectivity Device (ie L2 switch), not the endpoint.  Endpoint does not need to support SNMP (can if it wants).  The switching infrastructure *can*, usually would, use SNMP in the process, but does not absolutely need to (read on).   

> ... so isn't this simply a wiremap database that needs to be kept in synch with what changes at L2 as well? 

Yes, the wiremap dB does need to be kept in synch with L2 changes in *any* of the methods. 

In the LLDP / LLDP-MED based case, the interface to do this is well defined today (SNMP MIBs).   

In a pretty real sense, the switching infrastructure itself can be considered as the "database" since all the information is actually held in the edge switches -- and where the least moving parts aspect comes in is that's the box on the other end of the physical wire from the phone.  Changes can be made directly at the switch side, and re-synched with a master dB in the higher level management system by SNMP polling, or changes can be made in the management system side and pushed to the switching infrastructure using SNMP.  Mismatches can also be detected by noticing that info read from the switch side does not match the management system side.  Either works, or mixture of both, and which is used I would expect to be a matter of system scale and operational preference.  Small systems (a few L2 switches) need no master dB or higher order management system at all -- it can readily all be done directly on the L2 boxes.   

-- Peter 

        To:        <[email-masked]> 
        cc:        "GEOPRIV" <[email-masked]>, "Henning Schulzrinne" <[email-masked]> 
        Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Peter, 
  
In LLDP-MED, the device are going to learn this stuff from SNMP, or at least that is what the documents I have read in the past suggested, so isn't this simply a wiremap database that needs to be kept in synch with what changes at L2 as well? 

Cheers 
James 

________________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, 15 June 2007 3:28 AM
To: Winterbottom, James
Cc: GEOPRIV; Henning Schulzrinne
Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt 

> What would you do in network configurations that support LLDP but not LLDP-MED, of which I suspect there are many? 

Upgrade.  Seriously, any of the location proposals will require upgrades, so it is really a matter of where, not if.  (Note I do not work for a networking vendor, so have no direct interest in network upgrades other than to make the deployment job easier, ongoing admin and TCO lower, and ECS more reliable.)   

A corresponding questions to either L7 or DHCP methods is how would you get the wiremap data (ultimately L2 chassis/port ids and corresponding physical locations) into the server?  How to maintain it when things change at L2?  What's the standard interface for doing those important steps?   

>> Hoping I'm not about to step on a land mine ... 
Please Note: I'm trying not to ignite a battle of methods here!  Though quite aware it could happen.  Original intent was to just point out that RELO did not really appear to be pointing to anything proprietary.  But thinking about it led me to wondering: in the presence of LLDP/LLDP-MED why it would not just be used directly, instead of indirectly through more moving parts.  Each of the methods has its place.   

-- Peter 

       To:        <[email-masked]> 
       cc:        "GEOPRIV" <[email-masked]>, "Henning Schulzrinne" <[email-masked]> 
       Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Peter, 
 
What would you do in network configurations that support LLDP but not LLDP-MED, of which I suspect there are many? 
 
Cheers 
James 

________________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 12 June 2007 3:03 AM
To: Winterbottom, James
Cc: GEOPRIV; Henning Schulzrinne
Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt 

Hi, 

>  .. as opposed to something proprietary like Cisco Discovery

While I don't think specifying something proprietary would be a good thing (bad actually -- I would oppose CDP), I just wanted to point out the RELO actually talks about several possible ids, not just CDP.  RELO also mentions MAC address, LLDP (by extension LLDP-MED would be there also), and mentions all in the context of "such as" which I read to mean "for example".  So, I do not surmise that the intent was to propose "proprietary" solution, as alluded below.   

The held-identity-extensions draft also talks about LLDP.  In both RELO and held-identity-extensions, in presence of LLDP, I fail to see why the L7 protocol would be used at all in general practice.  If the switching environment supports LLDP / LLDP-MED, then why not use it to directly supply the location objects.  Adding the L7 moving parts would make things less reliable in those cases.  (I can see how there might be cases where L7 is needed, however do not see it for the general rule.  In those cases, supplying these ids may add value.)   

-- Peter 

      To:        "Henning Schulzrinne" <[email-masked]>, "GEOPRIV" <[email-masked]> 
      cc:         
      Subject:        RE: [Geopriv]        I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Hi Henning,

Cheers
James

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jun 2007 19:23:46 -0700

(splitting thread)

> strongly disagrees, we can make that change. [/MB]

Webdav has a model where some of the error codes end up in the HTTP  
response and some in an XML body. As an ex-chair of that wg, I can  
say that this was hard to get right. I'm not sure what advice to give  
but I think it is well worth careful attention to figuring out the  
semantics of if you need two places for errors, how to keep them from  
contradicting, and the semantics of what type of error gets reported  
where.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jun 2007 19:23:48 -0700

(splitting thread)

> [MB] Also a valid point and something we can consider for the next

How we go about extending XML always seems a little tricky but it  
seems like we should have this figured out by now. Thoughts on what  
the possibilities are, and any special requirements that might drive  
us one way or the the other here?

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jun 2007 19:26:21 -0700

With my individual hat on - I agree with James and Brian. The name  
correctly attributes it's heritage, it's a fine name, let's get on  
with the bigger fish we have to fry.

On Jun 14, 2007, at 7:09 PM, Winterbottom, James wrote:

>> Oddly, I'm in favor of keeping the name.  We selected this  
>> protocol from
>> the
>>>> This draft is a work item of the Geographic Location/Privacy  
>>>> Working
>>>> Group of the IETF.
>>>>

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Jun 2007 22:04:55 -0500

When we talked about doing this on our call, we specifically talked
about conditions where we wanted to introduce a new attribute that
changed functionality in HELD without having to declare a whole new
namespace.

The example we used was suppose that we decided that we want to
introduce a new signed=true option. If this is the only change, then do
this with XML we would have to define a new namespace just for the
signed attribute. 

I am not wedded to keeping this notation, but I really don't see the
problem of keeping it either. This email is designed to provide the
rationale as to why it is currently defined as it is.

Cheers
James

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Tuesday, 19 June 2007 12:24 PM
> To: GEOPRIV
> Subject: [Geopriv] draft-ietf-geopriv-http-location-delivery-00
> XMLExtentions
> 
> (splitting thread)
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 Jun 2007 02:46:25 -0400

I'm not sure I understand your comment. As written, HELD uses 3-digit  
numeric status codes that look like HTTP codes and have some  
resemblance in the first digit, but otherwise have nothing to do with  
the HTTP number space. I consider that another reason not to do that.  
(RELO was able to avoid this by relying only on HTTP status codes,  
but I digress.)

A separate issue, left unaddressed currently, is which HTTP status  
codes go along with which HELD error messages, however coded.

On Jun 18, 2007, at 10:23 PM, Cullen Jennings wrote:

> say that this was hard to get right. I'm not sure what advice to  
> give but I think it is well worth careful attention to figuring out  
> the semantics of if you need two places for errors, how to keep  
> them from contradicting, and the semantics of what type of error  
> gets reported where.
>
>
>
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 19 Jun 2007 02:14:30 -0500

In so far as it makes sense to do this mapping I don't see a problem.
I notice for example that in the current LoST specification only one
HTTP error code is mapped, and this is for the Forbidden case. Is there
a plan to add other mapping, say for the timeout case, to LoST also?

Cheers
James 

> Sent: Tuesday, 19 June 2007 4:46 PM
> To: Cullen Jennings
> Cc: GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-http-location-delivery-00 -
> ErrorReporting
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Jun 2007 19:37:30 -0500

HI Peter,

Yup, all of that gels okay.

I was only trying to point out that if I have a central repository for
the data that is the master then pushing that data to an intermediary
and then to the end-point may actually be less efficient, in some cases,
than having the data pulled by the end-point from the master DB
directly. This latter functionality is one capability that HELD
provides.

Cheers

James

Hi again, 

Correct, where "device" here is the Network Connectivity Device (ie L2
switch), not the endpoint.  Endpoint does not need to support SNMP (can
if it wants).  The switching infrastructure *can*, usually would, use
SNMP in the process, but does not absolutely need to (read on).   

> ... so isn't this simply a wiremap database that needs to be kept in
synch with what changes at L2 as well? 

Yes, the wiremap dB does need to be kept in synch with L2 changes in
*any* of the methods. 

In a pretty real sense, the switching infrastructure itself can be
considered as the "database" since all the information is actually held
in the edge switches -- and where the least moving parts aspect comes in
is that's the box on the other end of the physical wire from the phone.
Changes can be made directly at the switch side, and re-synched with a
master dB in the higher level management system by SNMP polling, or
changes can be made in the management system side and pushed to the
switching infrastructure using SNMP.  Mismatches can also be detected by
noticing that info read from the switch side does not match the
management system side.  Either works, or mixture of both, and which is
used I would expect to be a matter of system scale and operational
preference.  Small systems (a few L2 switches) need no master dB or
higher order management system at all -- it can readily all be done
directly on the L2 boxes.   

-- Peter 

14.06.07 22:07 

Hi Peter, 

Cheers 
James 

-- Peter 

11.06.07 18:35 

Hi Peter, 

Cheers 
James 

Hi, 

-- Peter 

08.06.07 19:39 

Hi Henning,

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Jun 2007 21:54:19 -0500

Ah... I haven't met a network admin yet who would prefer to manage their
network data in each individual end-point versus having a common
management database. That's even where there's only a couple of
switches.

When it comes to location, managing a database with a consistent
(Switch-ID + Switch-port -> Location) schema is much simpler then
dealing with the vendor specific mechanisms for managing the switch.
That's why SNMP is popular after all.

In terms of device capabiltity, a network based location protocol like
HELD can take advantage of a vanilla LLDP device because the switch port
information can be sent to the LIS which has the location data to
reference against. You don't need LLDP-MED to do that. You also don't
really need LLDP to be used by the device because the LIS can learn the
device to switch port association using many mechanisms including SNMP
bridge MIB polling, DHCP-relay, DHCP lease query. That's before we get
to the point where there's a generic framework for network devices to
report location-related network parameters to the LIS. The NGES working
group in ESIF are currently looking at formalising this using the
LIS-ALE (FLAP) definition as a starting point. However, LLDP is
nevertheless also a valid option.

Yes, all these things work to provide at least basic location
information and any given implementer has the option of using the
approach that works best for them. However, it is better if devices can
interact with access networks in the same way regardless of access
technology - and not have to "know" it should be using LLDP-MED at this
particular moment. When more sophisticated functionality (such as
location signing, assertion, and location-by-reference) are required the
L2 mechanisms also break down.

Which brings me to a point I probably should have made at the beginning;
the current topic on the thread started with the suggestion that while
the identity extension draft mentioned LLDP, should it not also include
LLDP-MED? The sense in which LLDP is pertinent is that it can be used to
get a "transient identity component"; a switch/switchPort value for
example. This information can be used to determine location. I assume
LLDP-MED is raised because it provides a means to obtain location
directly. However, "location as an identity component from which
location can be determined" doesn't really fit with the
identity-extensions. It more fits with the legion of alternative ways to
get location in the first place.

Cheers,

Martin

Hi again, 

-- Peter 

14.06.07 22:07 

Hi Peter, 

Cheers 
James 

-- Peter 

11.06.07 18:35 

Hi Peter, 

Cheers 
James 

Hi, 

-- Peter 

08.06.07 19:39 

Hi Henning,

Cheers
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 16 Jun 2007 10:29:58 -0500

Cheers,

Martin

Hi again, 

-- Peter 

14.06.07 22:07 

Hi Peter, 

Cheers 
James 

-- Peter 

11.06.07 18:35 

Hi Peter, 

Cheers 
James 

Hi, 

-- Peter 

08.06.07 19:39 

Hi Henning,

Cheers
James

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 27 Jun 2007 12:46:44 -0700

The non-namespaced extension functionality is completely unnecessary  
in the context of XML and it's unclear what it would mean to support  
it -- or to fail to support it.  It also introduces a new registry  
and registries are becoming more work to administer and oversee  
(we've spent many hours each in the past couple months discussing  
expert reviewers and backup processes for IANA registries).   
Namespaces are precisely there to avoid the choice between registries  
and name collisions, and they've been made extremely easy to define.

There's no need to define a new namespace for a new standard option  
such as  "signed=true".  A new RFC could define that attribute to be  
in the existing "urn:ietf:params:xml:ns:geopriv:held" namespace.  The  
RFC review process is needed already to make a new option a standard,  
and the review process is sufficient to determine if the new option  
is appropriate in the existing namespace.

In contrast, companies that want to add their own proprietary or  
simply limited-use extensions can define namespaces like "http:// 
mycompany.example.com/ns/held-extension" trivially for their non- 
standard extensions.

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 27 Jun 2007 13:18:50 -0700

> On Jun 19, 2007, at 12:14 AM, Winterbottom, James wrote:
>

I don't know about LoST but I'd probably make the same recommendation  
in either case: be clear about what HTTP error codes mean in the  
context of an application extending HTTP.

Since I have reviewed HELD, my specific recommendations for HELD  
status codes are:

1. For each internal status code, specify what HTTP response status  
code goes with it.  Otherwise you'll end up seeing 200 OK  
encapsulating HELD errors, or PIDF-LO objects inside 403 Forbidden  
codes, and not know whether this is intended or a bug or what the  
interpretation ought to be.

A more cleanly layered model is that any status code other than 200  
indicates a response generated at the HTTP layer rather than by the  
LCS.  A 500 response code would indicate that the HTTP server was  
having problems and the LCS didn't even see the request.  Any answer  
generated by the LCS implementation could arrive inside a 200 OK  
response body -- the outer status message meaning "The request was  
successfully delivered to the layered application and the response is  
from the layered application".    That means that a non-compliant  
"application/held+xml" request document would result in a 200 OK  
message -- the LCS received the request -- but inside the 200 OK  
response the LCS would put some kind of "bad HELD request" error  
message.

2. I suggest using something that doesn't look exactly like a HTTP  
status code, otherwise you'll see HTTP status codes used where HELD  
status codes ought to be.  E.g. a response with 402 in the HTTP  
status line when the intended meaning is "Authentication Error" (from  
HELD) rather than "Payment Required" (what HTTP 402 status really  
means).  It's particularly bad that authentication errors are  
different in HTTP and HELD.  See point 5.

This doesn't have to be very different to be differentiable.
  - You could simply prefix each HELD error code with a letter like  
'L' for Location, then have L200, L400, L401 etc.
  - You could use letters instead of number ranges to indicate class  
of status code: 's' for success, 'ec' for error by client and 'es'  
for error by server, and 'ep' for private errors. (e.g. s00, ec00,  
ec01, es00, ep05).

3.  Are all the other HTTP status codes not mentioned in this  
document legal or illegal?  MUST the client support redirects, or are  
servers REQUIRED NOT to use redirects?  102 Processing?  412  
Precondition Failed?

4. Since the set of error codes is explicitly extensible for private  
use, what is the client supposed to do with unrecognized HELD error  
codes?

5.  Why is there an authentication error at the HELD layer?   
Authentication does not appear to be done at the HELD layer.   OTOH  
it is not clear whether it can be done at the HTTP layer either  
(whether HELD clients are required to support HTTP authentication  
challenges).  This may be a layering violation.

Lisa

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 27 Jun 2007 18:25:26 -0500

Hi Lisa,

If this is going to cause any degree of headache then I am more than
happy to drop support for it. Extensibility for attributes can be done
purely through namespace registration.

Cheers
James

> From: Lisa Dusseault [mailto:[email-masked]]
> Sent: Thursday, 28 June 2007 5:47 AM
> To: Winterbottom, James
> Cc: Cullen Jennings; GEOPRIV
> Subject: Re: [Geopriv] draft-ietf-geopriv-http-location-delivery-00
> XMLExtentions
> 
----------------------------------------------------------------------
> > --------------------------
----------------------------------------------------------------------
> > --------------------------
> > [mf2]
> >
> >
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Jun 2007 05:49:55 -0400

I think it makes sense to have a common model between LoST and HELD,  
as the issues are relatively similar. For what it's worth, the LoST  
author team decided to follow the layering advice given below - all  
LoST responses are in an HTTP 200 OK message, as that indicates that  
HTTP was able to handle the request, even if LoST (or other protocol  
layered on top) had difficulties. In addition to the layering reasons  
given, I think it tends to make the implementation cleaner and avoids  
strange programming errors, where an implementor gets the response  
code for a particular HELD or LoST condition wrong. The HTTP status  
code adds no additional information, and only means that the  
implementation has to cope with a "HTTP says bad thing X happened,  
but next-layer says Y, which do I believe?". This seems to mainly  
result in more test cases. (FWIW, the 06 revision of LoST will make  
this behavior a bit clearer, but it's really just a one-sentence  
addition.)

Henning

On Jun 27, 2007, at 4:18 PM, Lisa Dusseault wrote:

> I don't know about LoST but I'd probably make the same  
> recommendation in either case: be clear about what HTTP error codes  
> mean in the context of an application extending HTTP.
>
> having problems and the LCS didn't even see the request.  Any  
> answer generated by the LCS implementation could arrive inside a  
> 200 OK response body -- the outer status message meaning "The  
> request was successfully delivered to the layered application and  
> the response is from the layered application".    That means that a  
> non-compliant "application/held+xml" request document would result  
> in a 200 OK message -- the LCS received the request -- but inside  
> the 200 OK response the LCS would put some kind of "bad HELD  
> request" error message.
>
> status line when the intended meaning is "Authentication  
> Error" (from HELD) rather than "Payment Required" (what HTTP 402  
> status really means).  It's particularly bad that authentication  
> errors are different in HTTP and HELD.  See point 5.
>
> document legal or illegal?  MUST the client support redirects, or  
> are servers REQUIRED NOT to use redirects?  102 Processing?  412  
> Precondition Failed?
>
> 4. Since the set of error codes is explicitly extensible for  
> private use, what is the client supposed to do with unrecognized  
> HELD error codes?
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 28 Jun 2007 18:34:43 -0500

Hi Henning,

I agree with yours and Lisa sentiments here. Certainly I didn't get when
I read the last LoST version. I also think that one sentence is all that
is required.

Cheers
James

> Sent: Thursday, 28 June 2007 7:50 PM
> To: Lisa Dusseault
> Cc: GEOPRIV WG
> >>>>> [MB] It does seem reasonable to consider the approach you
suggest.
> >>>>> But,
---------------------------------------------------------------------
> >> ---------------------------
---------------------------------------------------------------------
> >> ---------------------------
> >> [mf2]
> >>
> >>
> >>