Hi, Ben, On 04/25/2013 09:44 PM, Ben Campbell wrote: >>> -- section 3, 2nd paragraph from end: >>> >>> You describe the affects of including Network_ID in some detail. >>> It would be helpful to note the consequences of _not_ including >>> it. >> >> Well, should we really do it? -- after all, you MUST include it. > > Hmm. Section 3 says Network_ID is optional. Ooops, sorry -- you're right! I was thinking about the prefix, rather than the Network_ID. I will address this in the next rev. >>> -- 1, paragraph 11: "This document does not update..." >>> >>> How is adding an alternative algorithm _not_ an update? >> >> Well, you still send an RS, receive an RA, and generate an IID. >> >> Me, I'd probably update RFC 4862, so that we make sure that folks >> implementing SLAAC take a look at this document, but.... > > ...? > > (The reason you mention is one of the best reasons I can think of to > call it an update--but if the working group consciously chose not to > make it an update, I can live with it.) I'm not sure whether this was "consciously chosen" -- I will check with a few folks about their thoughts (for the most part, I wouldn't want to trigger a controversy just because of this). >>> --1, paragraph 12: "... may already address" >>> >>> Is the "already addressing" part in question? Or is it a matter >>> of addressing it in some circumstances, but not others? If the >>> latter, it would help to elaborate. >> >> Not sure what you mean. The idea is that, in many scenarios, >> draft-ietf-stable-privacy-addresses may be good enough to address >> your privacy concerns. > > The way it's worded, it looks like you think it might address the > concerns, but aren't sure. I doubt that's the intent. Simply saying > "may address certain privacy concerns", or "in some circumstances, > will address...". OTOH, elaborating on the specific concerns > addressed would be even better. Do you mean to say it addresses the > concerns already mentioned in this draft? If so, you could use > language stronger than "may". > > Your answer to my next comment is instructive for this as well. Ok, I will add some text about this. >>> -- references: RFC1948 is obsoleted by 6528. Is there a reason to >>> reference the obsolete version? >> >> Yes: RFC1948 is only referenced in the Acks section, where I note >> that this document was inspired by Bellovin's work on RFC1948. >> While RFC6528 obsoletes RFC1948, the algorithm in that RFC is the >> same as that in RFC1948. > > So 6528 equally illustrates Steve Bellovin's work, and is also more > current, right? Yes. But I'm a co-author of RFC 6528 -- so it'd be a bit arrogant (and incorrect) to say that I was inspired by RFC 6528 :-) -- I was inspired by Bellovin, rather than myself. :-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492