Hi, Ole, I've rev'ed the I-D according to your feedback and our recent email exchange. Some additional notes below:
On 12/21/2012 08:20 AM, Ole Troan wrote: [discussion of what this algorithm is similar to] FWIW, I've added an ack to the Acks section, noting that this algorithm was inspired by Steve Bellovin's work on TCP sequence numbers. For instance, what this algorithm does is to separate the IID-space on a "per-network" basis. >>> - The algorithm in the document is underspecified. >>> o It should specify the hash function. E.g. MD5 as RFC4941. >> >> Why should it? Put another way, is this needed for the algorithm to >> work? -- it's not. I've added some text in this area -- noting why we do not require any specific algorithm. >>> o It would be useful to include an example algorithm as has been done >>> in some other documents. >> >> You mean as in RFC4941? Or a algorithm in pseudo-code? > > as in 4941. RFC 4941 needs an algorithm because it is more complex than this IID. As far as this alg is concerned, the only algorithm one could come up with is: 1) generate the IID with this expression 2) tweak the U/G bit 3) Check for reserved addresses, and consider this a DAD conflict if it is a reserved address DAD shouldn't be included in this "algorithm" because we're not updating RFC4862 at all. -- we're just specifying an alternative algorithm for generating IIDs. >>> - Clarify what lifetimes these addresses have. >> >> You mean lifetimes in the sense of "same thing as tradtional slaac >> addresses" or lifetime in the sense of "the address will be stable as >> long as you don't change the secret key". > > an address cannot have a longer lifetime than the lifetimes advertised in RAs > of course. > could you say something along the lines of: Stable Privacy Addresses have the > same lifetime properties > as SLAAC addresses [4862] and expire as described in section 5.5.3 of 4862. I've clarified this. However, I should note that there's no reason to believe that these lifetimes change, since we're not changing SLAAC (RFC 4862). >>> - Specify the default for DAD retries (IDGEN_RETRIES) >> >> Will do. I did specify this -- however, IMHO this is out-of-scope, since this value should be specified somewhere else. Please check the rev'ed I-D -- I believe it is ready to ship. Thanks so much, and have a Happy New Year! 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 --------------------------------------------------------------------
