Hi, Brian, On 04/09/2013 12:21 PM, Brian Haberman wrote: >> On 04/08/2013 11:46 AM, Brian Haberman wrote: >>> 1. Section 1 : I understand that the fourth paragraph is indented since >>> it is quoting from another document. I do not see why the fifth >>> paragraph is indented. The same confusion exists for the second >>> paragraph of Section 3. >> >> Indented ṕararagraphs, unless otherwise noted, are parenthetical notes, >> rather than quotes from other documents (i.e., text that provides >> additional information, but that you may skip reading if you want). > > We have had this discussion before... I am not a fan of these > parenthetical notes, but to each his own.
I wasn't arguing in favor of them, but rather explaining what they were. (FWIW, these notes predate our "discussion" on the subject... and, in all fairness, you're not the first one to not like them :-) ). I'll try to incorporate them into the main body -- fwiw, the reason for which I including those paragraphs as such (parenthetical notes), is so that the reader that is not interested in those details can easily skip them. >> HOw about the following text: >> >> "The Interface Index is expected to remain constant across system >> reboots and other events. However, we note that it might change upon >> removal of a network interface (typically one with a smaller value for >> the Interface Index, when such naming scheme is used). When such >> Interface Index changes occur, the IPv6 addresses resulting from this >> algorithm for an interface index is likely to change, thus affecting the >> stability property of this approach. We note that we expect these >> scenarios to be unusual." > > I don't like "likely to change". Yep, that was stupid -- how about s/for an interface index is likely to change/for an interface will change/? > Additionally, I will note that this scenario may not be as unusual as > you think. For example, the ifIndex on some Cisco gear will change > enough that IOS has a configuration command to make it stable. what's the "event" upon which the interface index will change? "Interface removal", as in the suggested text, or something else? If that's the case, I'd not expect that to happen frequently -- and even less for hosts/servers doing SLAAC (those routers are more likely using statically-configured addresses). Anyway... should I add something along this lines of: "Some implementations are known to provide configuration knobs to set the Interface Index for a given interface. This could be leveraged to prevent maintain the same Interface Index for an interface when e.g. the removal of a network interface causes Interface Indexes to change" ? >> Maybe in the corresponding "bullet"? Or right after the paragraph that >> says "Including the SLAAC prefix in the PRF computation causes the..."? >> > > The latter would be preferable, but it raises another question. If > there is discussion on input values changing in section 3, the text on > the impact of DAD_Counter changes in section 4 should probably be moved > to section 3. Me, I have no objections against that. I should note that DAD_Counter is described in Section 4 because that section is the subject of a whole topic. I guess we have two options: 1) Add a small sentence pointing to Section 4, or, 2) Move Section 4 into Section 3. I'd probably go with 1), but wouldn't bother doing 2). -- Please pick one, and I'll apply it. >>> * What are the assumptions on this algorithm with respect to multi-homed >>> devices that could have different network interfaces available to attach >>> to the same network? For example, if I have a quad-port network card, I >>> could attach to a network via eth0 and get an identifier for prefix X. >>> The next time I attach to that network, I use eth2 and I will not get >>> the same identifier even though I still get a PIO containing prefix X. >>> This issue directly contradicts design goal #1. >> >> This algorithm aims to produce stable addresses for each interface. SO >> as long as the same interface gets the same addresses, the algorithm is >> achieving it's goal. >> > > Then something needs to be said in the document about this limitation. > This approach does not create stable addresses *per prefix*. This is my rationale: The internet architecture has no concept/namespace for "node". So, from a practical point of view, different network interfaces all look like different nodes (in the same way that you cannot use any of your addresses for the same TCP connection, etc.). That aside, you could also have the case where the same node connects to the same network with two NICs, at the same time. In such scenario, you're forced to have each NIC get a different IPv6 address. -- In a scenario such as this, each NIC will get the same address (both in this case and also when the node connects to that network with a single interface). So I'd argue that this is a desired property, rather than a drawback. >>> 3. I think it would be good to explicitly state that this IID generation >>> mechanism is incrementally deployable since there are no >>> interoperability issues with IID generation. >> >> Good point. >> >> How about adding this to the Intro, right after the para that starts >> with "This document specifies a method to generate interface >> identifiers...": >> >> "We note that this method is is incrementally deployable, since it >> doesn't pose any interoperability implications when deployed on networks >> where other nodes do not implement or employ it". >> >> ? > > The above is fine as long as you remove the redundant "is". Great. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
