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

Re: AD Review of draft-ietf-ipv6-rfc2462bis-06.txt


Sorry about the long delay.  I'll first comment on the two major

>>>>> On Wed, 6 Oct 2004 09:05:53 -0400, 
>>>>> Margaret Wasserman <margaret@xxxxxxxxxxxxxx> said:

> I finished my AD review of draft-ietf-ipv6-rfc2462bis-06.txt.  I have 
> several comments on this document that I believe should be resolved 
> before this document is sent to IETF Last Call for publication as a 
> Draft Standard.

> All of my comments are included below, but my most serious concerns are:

> (1) Having decided that "the stateful configuration" mechanism is 
> DHCPv6, I don't think that there is a reason to maintain the awkward 
> and confusing wording about "the stateful mechanism" in many places. 
> I've pointed out the worst cases, but there are many others.  I know 
> that this is largely an editorial concern, but the awkwardness and 
> lack of clarity are bad enough in some places (see below) that I 
> consider this a blocking problem for publication at DS.

I actually wanted to remove the word "stateful" for clarity.  But this
would also require changes to more normative statements in rfc2461bis.
For example, RFC2461 hardcodes the term "stateful" for the 'O' flag of

      O              1-bit "Other stateful configuration" flag.  When
                     set, hosts use the administered (stateful) protocol
                     for autoconfiguration of other (non-address)
                     information.  The use of this flag is described in

If we remove "stateful" from rfc2462bis, I think we'd also need to
change the name of the bit in rfc2461bis accordingly.  Otherwise, the
result would rather be more confusing.  So I asked the wg whether

- we should clean up all the occurrences of "stateful" and replace
  them with "DHCPv6" in rfc2461bis and rfc2462bis, or
- we should keep the wording but clarify what "stateful" actually
  means (and clarify the possible confusion RFC3736 is also called
  "stateless" while it's a part of DHCPv6)

See the following message and the succeding thread for more details:

Unfortunately, I didn't see many responses to the question, so I
decided to take the second action, considering the "conservative"
nature of the 2462bis work.

But if we, as a wg, can agree on the first choice, which includes
modifications to rfc2461bis, I'm willing to make that change.  (I'd
object to just changing 2462bis with keeping the current wording in
2461bis.  That would just introduce further confusion.)

> (2) I am not comfortable with the idea that we would punt the 
> interpretation of the M & O bits to a "separate document" with no 
> reference.  I believe that information about how to interpret these 
> bits is essential to implementing IPv6 address autoconfiguration. 
> See below for the specific text that concerns me.

Please let me check: regarding the M/O flags, we basically introduced
the following two changes from RFC2462:

1. remove some "mandatory" wording on these flags and clarify that
   these flags are just hints of availability of the corresponding
   services (DHCPv6).
2. leave more details to other document(s)

And, I believe how to "interpret" these bits is very clear with change
1.  In fact, the "mandatory" nature of these flags in RFC2462 has been
confusing people, and I believe the change in rfc2462bis makes the
interpretation much clearer.

Actually, the course of this change was based on a pretty clear
consensus in the wg.  See, for example, the following messages and
succeeding threads:

So, I interpret your main concern is about mentioning other
document(s) without a concrete reference.  Is this correct?

If so, there is an ongoing work in this area, although it's still
an individual document: draft-daniel-ipv6-ra-mo-flags-00.txt. (A new
revision of this document will be submitted before the coming IETF

With this ongoing work, I can think of the following three choices:

1. simply remove the "other document".  As I said above, the
   "interpretation" of these flags should already be pretty clear.
   And removing the "other document" solves the dangling reference
2. assuming the above ongoing work or a different (non existing)
   document is adopted as a wg document, refer to it as an
   *informative* reference.  At the moment, we only have an individual
   I-D, but even a wg I-D cannot be a normative reference in a draft
   standard.  Also, based on our consensus the separate document will
   be published as a BCP.  I'm not sure if a DS can safely have a
   normative reference to a BCP regarding the reference dependency
   issue (the rule is too complicated and it is very hard to find an
   appropriate document!).  BTW: in this sense, we can even not refer
   to the DHCPv6 RFCs as normative references, since those are still

I don't have a particular preference between these two, but if none of
them is acceptable, I can't imagine how we can proceed.  Please let me
know what you think.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.

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