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

From: peter_blatherwick@mitel.com
Date: Thu Jun 14 2007 - 13:27:39 EDT

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

> 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

"Winterbottom, James" <James.Winterbottom@andrew.com>
11.06.07 18:35
 
        To: <peter_blatherwick@mitel.com>
        cc: "GEOPRIV" <geopriv@ietf.org>, "Henning Schulzrinne"
<hgs@cs.columbia.edu>
        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: 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 Thu, 14 Jun 2007 13:27:39 -0400

This archive was generated by hypermail 2.1.8 : Thu Jun 14 2007 - 13:27:51 EDT