Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

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

 



On 04/23/2013 07:45 PM, Christian Huitema wrote:
>> If I'm the guy producing a spec, my goal is to produce a spec that
>> is clear as possible, and only leave open those bits that are
>> necessary to leave open.
> 
> Well, that might work for internal specs when you are managing a
> project, but that's probably not the right way to approach standards.

That probably depends on *what* you're specifying (please see below).


> A standard, being the rules of the network, shall only constrain what
> must be constrained for interoperability.

This document is not about a rule of the network, but about a local
policy. Therefore, by definition, as long as the address you select is
unique, nothing in this document will affect interoperability.



> All implementations are tradeoffs. Developers will necessarily make
> them, based on the different resource, priorities, usage scenarios.
> It is much better to explain to give clear guidelines than to merely
> mandate an implementation.

We probably have different views here. We're not mandating an
implementation (e.g., we're not mandating any specific PRF for F(), nor
how you store addresses in memory if you do store them).

I see the algorithm in this document as giving more room for tradeoffs
to developers than RFC4941, and the same room for tradeoffs as e.g. RFC6528.

Based on the above, me, I don't find the idea of re-writing the I-D
compelling -- particularly at this point in time.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492








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