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(_at_)si6networks(_dot_)com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492