Hi, Brian, Thanks so much for the review! -- Please find my comments in-line...
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). > 2. Section 3 : > > * The PRF is fed several variables in order to generate a random number. > I appreciate that the issues with different identifiers being generated > for the same prefix due to varying values of DAD_Counter are discussed > (Section 4). What is missing is discussion of when the Interface_Index > value changes. On many systems, the value returned via the socket APIs > is based on the ifIndex value assigned to the interface. There are a > variety of situations where the ifIndex can change within a system and > these should be mentioned. This can impact design goal #2. 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." Maybe in the corresponding "bullet"? Or right after the paragraph that says "Including the SLAAC prefix in the PRF computation causes the..."? > * 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. > 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". ? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
