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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, deleting sections that seem resolved:

On Apr 25, 2013, at 8:12 PM, Fernando Gont <fgont@xxxxxxxxxxxxxxx> 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 :-)






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]