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

From: Winterbottom, James ^lt;James.Winterbottom@andrew.com>
Date: Mon Jun 11 2007 - 18:35:03 EDT

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: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] 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, 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" <James.Winterbottom@andrew.com> 08.06.07 19:39 To: "Henning Schulzrinne" <hgs@cs.columbia.edu>, "GEOPRIV" <geopriv@ietf.org> cc: Subject: RE: [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-00.txt 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:hgs@cs.columbia.edu] > Sent: Saturday, 9 June 2007 6:26 AM > To: GEOPRIV > 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 > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------ ------------------------ 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] _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ------------------------------------------------------------------------------------------------ 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 11 Jun 2007 17:35:03 -0500

This archive was generated by hypermail 2.1.8 : Mon Jun 11 2007 - 18:35:17 EDT