ietf
[Top] [All Lists]

Re: Gen-ART LC Review of draft-ietf-6man-stable-privacy-addresses-06

2013-04-25 22:13:31
Hi, deleting sections that seem resolved:

On Apr 25, 2013, at 8:12 PM, Fernando Gont <fgont(_at_)si6networks(_dot_)com> 
wrote:

[...]



-- 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).



Point taken.

[...]



-- 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. :-)


Ah, I see your point :-)