>>>>> On Fri, 16 Jul 2004 22:22:14 -0400, >>>>> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> As I said in a related discussion for rfc2462bis, the change in >> Section 4.6.2 seems overspecification according to the original >> consensus that led to the issue. See >> http://www1.ietf.org/mail-archive/web/ipv6/current/msg03034.html >> for more details. As I mentioned in this message, I think the >> restriction in Section 4.6.2 (the part marked with "---->") should be >> removed. > => Ok, but you said that 6 months after the text was added :) > The concensus back then was to add the current text. If you > want we can revisit the issue before LC. I apologize for the late comment (I also know this is a minor nitpick, so I won't be too much vocal on this). However, I could not see the discussion log (to the consensus) at the issue tracker page for this issue, so I raised it at this timing. >> Additionally, it is probably not enough to say "AdvPreferredLifetime >> MUST NOT be larger than AdvValidLifetime", since either one >> or both of >> the lifetimes can be configured so that it decrements in real >> time. For example, consider the case where >> >> AdvValidLifetime = 40000 (decrementing in real time) >> AdvPreferredLifetime = 30000 (fixed time). >> >> These configurations seem valid according to the specification. >> However, the advertised valid lifetime would be smaller than the >> advertised preferred lifetime about 10000 seconds later. > => There is one issue here: These restrictions are specified in the context > of the _advertised_ information on the wire. I'm sure that there are many > different ways of configuring both fields. The requirement is that _whenever_ > sending_this_on_the_wire_ the preferred liftime must not be larger than > valid lifetime. This is independent of how people configure fields or > implement their storage. But AdvPreferredLifetime and AdvValidLifetime are "Router Configuration Variables", which are "conceptual variables to be configured by system management" (from Section 6.2.1). So, IMO, just specifying a requirement between AdvPreferredLifetime and AdvValidLifetime does not necessarily make a requirement on the wire content. At the same time, however, I admit Section 6.2.3 appears to say these variables are also the wire content: - In the Valid Lifetime field: the entry's AdvValidLifetime. - In the Preferred Lifetime field: the entry's AdvPreferredLifetime. In that sense, >> A. if AdvValidLifetime decrements in real time, require >> AdvPreferredLifetime decrement as well >> B. require routers to ensure the valid lifetime be equal to or larger >> than the preferred lifetime at sending time, regardless of the >> values of AdvValidLifetime and AdvPreferredLifetime. > => B. is what's implied already since we're talking about protocol > fields. When we define protocol fields it is clear that the definitions are > in the context of communication over the wire. I tend to agree on this interpretation. I'd still add a note for the AdvPreferredLifetime like this: Default: 604800 seconds (7 days), fixed (i.e., stays the same in consecutive advertisements). This value MUST NOT be larger than AdvValidLifetime. (Note that the condition may change at a future point in time when AdvValidLifetime decreases in real time.) (Again, I know this is a minor corner case. So I won't strongly argue for the additional note) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
