RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt

Date: Mon Jun 11 2007 - 13:03:13 EDT


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" <>
08.06.07 19:39
        To: "Henning Schulzrinne" <>, "GEOPRIV"
        Subject: RE: [Geopriv]

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


> -----Original Message-----
> From: Henning Schulzrinne []
> Sent: Saturday, 9 June 2007 6:26 AM
> Subject: Re: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-
> delivery-00.txt
> 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
> _______________________________________________
> Geopriv mailing list

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.

Geopriv mailing list

Geopriv mailing list
Received on Mon, 11 Jun 2007 13:03:13 -0400

This archive was generated by hypermail 2.1.8 : Mon Jun 11 2007 - 13:03:28 EDT