[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    RE: Proposed changes to IPv6 Address Architecture draft
From:       "Manfredi, Albert E" <albert.e.manfredi () boeing ! com>
Date:       2005-05-20 21:19:00
Message-ID: EF40C42ACAB7A649B2EAE70C19B6CD6E037C39F9 () xch-ne-02 ! ne ! nos ! boeing ! com
[Download RAW message or body]

I would go further than Brian on this single point of the high order flag bit.

If you do not specify that it must be set to zero on transmission, then in the \
future, when you do want to start using it, you'll be stuck with having to modify \
servers, overnight, that haven't yet implemented that flag.

Other than that single item, I'm agreeing with Thomas.

Bert


> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: Friday, May 20, 2005 3:53 PM
> To: Thomas Narten
> Cc: Bob Hinden; ipv6@ietf.org
> Subject: Re: Proposed changes to IPv6 Address Architecture draft 
> 
> 
> 
> On May 20, 2005, at 16:43, Thomas Narten wrote:
> 
> > > How about if it just says:
> > 
> > > The high-order flag is reserved and must be zero.
> > 
> > Actually, the issue that I'm trying to get around is to avoid having
> > the spec say the flag "must be xxx" where xxx is any value. 
> It should
> > just (mostly) be ignored. If you say it must be zero, than some
> > implementation might think if it is non-zero it should be changed to
> > zero, or something equally silly.
> > 
> > Thus, I think:
> > 
> > The high-order flag is reserved.
> > 
> > might be better than saying the full sentence.
> > 
> > I.e., a future spec will set it to 1 and presumably all the existing
> > implementations should continue doing what they did before hand --
> > i.e., just ignore the bit, not treating it having any 
> special meaning
> > one way or the other.
> > 
> > With reserved fields in protocol headers, we typically say 
> "ignored on
> > receipt". But that is not true for an address, because the 
> value isn't
> > completely ignored, as its considered part of the address when doing
> > lookups or when comparing against other addresses.
> > 
> > But this is all a pretty minor point overall.
> > 
> 
> I emphatically agree that it is a minor point.  The current text has 
> been
> in the spec from day 1 and has not caused problems.  Given that,
> I would prefer to leave the text as is.
> 
> Regards,
> Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]