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