Re: Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-30 Thread Ray Hunter
Tim Chown wrote: > On 29 Apr 2013, at 20:39, Ray Hunter > wrote: > >> Christian Huitema wrote: The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but t

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Tim Chown
On 29 Apr 2013, at 20:39, Ray Hunter wrote: > Christian Huitema wrote: >>> The "problem" here is that don't have all the names/IDs we'd like. For >>> example, using the MAC address as the Interface_ID would do for this >>> purpose... but the the IPv6 address is tied to the MAC address, and woul

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Fernando Gont
On 04/29/2013 07:04 PM, Doug Barton wrote: >>> Let's assume that >>> there are 2 broad categories that cover a statistically significant >>> percentage of the possible use cases, home and business. I don't see any >>> scenario where the home user would be benefited from stable privacy >>> addresses

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Brian Haberman
All, I just want everyone to be aware that I have stopped the publication process on this document and sent it back to the WG. There was significant feedback that I felt needed to be dealt with and that the resulting changes may alter the document significantly. The author and the docum

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Doug Barton
On 04/29/2013 01:12 PM, Fernando Gont wrote: On 04/29/2013 05:00 PM, Doug Barton wrote: I only peripherally followed the early discussion about this topic (only so many hours in the day). I confess that I never "got" the need for this, but lots of people seemed enthusiastic about it, so I put it

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Fernando Gont
On 04/29/2013 05:00 PM, Doug Barton wrote: > I only peripherally followed the early discussion about this topic (only > so many hours in the day). I confess that I never "got" the need for > this, but lots of people seemed enthusiastic about it, so I put it in > the category of things to figure out

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Doug Barton
On 04/29/2013 12:39 PM, Ray Hunter wrote: Christian Huitema wrote: The "problem" here is that don't have all the names/IDs we'd like. For example, using the MAC address as the Interface_ID would do for this purpose... but the the IPv6 address is tied to the MAC address, and would change upon r

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Fernando Gont
On 04/29/2013 12:03 PM, Christian Huitema wrote: >> The "problem" here is that don't have all the names/IDs we'd like. >> For example, using the MAC address as the Interface_ID would do for >> this purpose... but the the IPv6 address is tied to the MAC >> address, and would change upon replacement

Re: RE: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Ray Hunter
Christian Huitema wrote: >> The "problem" here is that don't have all the names/IDs we'd like. For >> example, using the MAC address as the Interface_ID would do for this >> purpose... but the the IPv6 address is tied to the MAC address, and would >> change upon replacement of the NIC (which is

RE: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Christian Huitema
> The "problem" here is that don't have all the names/IDs we'd like. For > example, using the MAC address as the Interface_ID would do for this > purpose... but the the IPv6 address is tied to the MAC address, and would > change upon replacement of the NIC (which is generally undesirable)... Un

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-29 Thread Fernando Gont
On 04/29/2013 01:13 AM, Mark Smith wrote: >>> This gets a bit interesting when thinking about the USB NIC >>> situation. Plugging the USB NIC into different USB slots would >>> change the interface ID if the slot is used to assign it a >>> persistent interface ID. >> >> I'd argue that this would

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-28 Thread Brian E Carpenter
On 29/04/2013 16:13, Mark Smith wrote: ... > I don't think it is specifically defined. For example, I > understand Linux just uses an incrementing allocation > counter, which is why the order of interface initialisation > or insertion matters. On routers etc., this sort of scheme > also seems to be

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-28 Thread Mark Smith
gt; Sent: Friday, 26 April 2013 9:01 AM > Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name > > Hi, Mark, > > Thanks so much for your feedback! -- Please find my comments in-line > > On 04/25/2013 06:13 PM, Mark Smith wrote: >> >&

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-26 Thread t . petch
Original Message - From: "Fernando Gont" To: <6...@ietf.org> Cc: <6man-cha...@tools.ietf.org>; "RJ Atkinson" ; "Brian Haberman" ; "t.petch" Sent: Thursday, April 25, 2013 3:01 PM > Folks, > > During IETF LC, a couple of folks noted that Interface Indexes might not > be stable. > > I add

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Ray Hunter
> Mark Smith > 25 April 2013 23:13 > Hi Fernando, > > > > I think listing those desired properties would be useful, and then > describing examples of actual interface identifiers that would qualify > if available e.g., persistent ifindex values or persistent inter

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Fernando Gont
Hi, Mark, Thanks so much for your feedback! -- Please find my comments in-line On 04/25/2013 06:13 PM, Mark Smith wrote: > > I think listing those desired properties would be useful, and then > describing examples of actual interface identifiers that would > qualify if available e.g., persis

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Mark Smith
y, 26 April 2013 2:47 AM >Subject: Re: LC comments on stable-privacy-addresses: Interface Index vs. name > > >Hi, Ray, > >On 04/25/2013 11:21 AM, Ray Hunter wrote: >> Since both "Interface_Index" and "Interface name" are anyway both >> implementat

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Fernando Gont
Hi, Christian, Thanks so much for your feedback! Please find my comments in-line... On 04/25/2013 10:41 AM, Christian Huitema wrote: >> My take would be to replace "Interface Index" in the expression >> with an abstract "Interface_ID", and then explain that >> "Interfae_ID" can be either the Inte

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Fernando Gont
Hi, Ray, On 04/25/2013 11:21 AM, Ray Hunter wrote: > Since both "Interface_Index" and "Interface name" are anyway both > implementation dependent, why would you need to precisely standardise > the exact meaning, or the exact source of the information? AFAICS this > wouldn't significantly affect in

Re: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Ray Hunter
Fernando Gont wrote: > Folks, > > During IETF LC, a couple of folks noted that Interface Indexes might not > be stable. > > I added some text on the subject to my working copy (mostly based on the > discussion with Brian Haberman and Mark Smith), but the issue came up > again (Tom Petch commented

RE: LC comments on stable-privacy-addresses: Interface Index vs. name

2013-04-25 Thread Christian Huitema
> My take would be to replace "Interface Index" in the expression with an > abstract "Interface_ID", and then explain that "Interfae_ID" can be either > the > Interface Index or the Interface name, and include some of the text above > (explaining why an implementation might want to include one