Rémi, On 04/02/2013 09:11, Rémi Després wrote: > Hi, Roger, > > Please see inline. > > 2013-02-03 22:40, Roger Jørgensen <rog...@gmail.com> : > >> On Sun, Feb 3, 2013 at 9:56 PM, joel jaeggli <joe...@bogus.com> wrote: >>> On 2/3/13 11:39 AM, Joel M. Halpern wrote: >>>> On 2/3/2013 2:36 PM, Brian E Carpenter wrote: >>>>> On 03/02/2013 17:26, Joel M. Halpern wrote: >>>>>> To a significant degree Randy, I agree with you in your comment about >>>>>> magic bits. If I were designing IPv6 from scratch (counter-factual in >>>>>> so may ways at once) I would not do it that way. >>>>>> >>>>>> But, unless there is an actual problem with the design the IETF has >>>>>> adopted, I am reluctant to change it "just because". >>>>> >>>>> Which is why the draft actually proposes nothing that would change >>>>> any running code. >>>>> >>>>> Brian >>>> >>>> But it does propose to change the spec. Why? What problem does changing >>>> the spec solve? >>> If it prevents someone from ascribing new utility to these bit(s) in the >>> future that seems like a worthwhile goal. While I'm sure that we can come up >>> with new and different was to apply meaning to global unicast addresses I >>> think the world is a simpler place when we don't. > > It depends on what is done with the new design, especially if it is backward > compatible and optional. > > The question that started this discussion is whether reserving a currently > unused IID range having u=1 is compatible with the IPv6 addressing > architecture (i.e. RFC 4291). > AFAICT, the answer is YES. > Changing RFC 4291 to make it become a NO would have consequences well beyond > this new request.
Indeed. That is not in any way proposed by the draft. Rather to the contrary, in fact, since one of the co-authors of 4rd is my co-author. Brian >> KISS is always a good approach - Keep It Stupid Simple, or Simple Stupid. > > Agreed. > >> (or in short, special meaning attached to bits seems to cause more >> confusion than good) > > - Not a consequence of KISS. > - Changing a specification without a pressing need, and although it has been > used, isn't a way to increase confidence in any design. IPv6 needs confidence. > > >> And on the topic of DAD vs assume uniqueness - I learned this from an >> earlier colleague > > No one proposes to abandon DAD! > The point is that, while a specification *clarification* on u/g appears to be > useful, specification *change* would be harmful. > > Regards, > RD > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
