Hi Jinmei,
Thanks for the response!
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)
I agree that we would need to make some similar changes to RFC 2461bis, but I don't see that as a huge change. It could read something like:
O 1-bit "Other DHCPv6 configuration" flag. When
set, hosts use DHCP to configure other (non-address)
information. The use of this flag is described in
[ADDRCONF].The bigger problem is that the use of this flag is not described in the new version of ADDRCONF, so 2461bis will need a normative reference to the new document that does describe the use of these flags (unless we put it back here).
There is, of course, also a big ambiguity here about whether this flag indicates that hosts MUST, SHOULD or MAY use DHCPv6 to configure other information. As you indicated below, we've known about, and struggled with, that ambiguity for a while, so I hope it will be resolved in RFC 2461bis or 2462bis.
(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)
So, I interpret your main concern is about mentioning other document(s) without a concrete reference. Is this correct?
Yes, but maybe not quite in the way you think. RFC 2461bis and RFC2462bis are closely related documents that I think should probably go forward together on a single ballot (as I said elsewhere in my message). By moving the description of the M&O bits to another document, you aren't really simplifying anything (IMO), you are merely creating a third document that is essential to understanding these two. It also presents some problems, because the document is not complete yet and will have to start out at PS before moving to DS, which may block the publication of 2461bis and 2462bis at DS.
There is really a basic question here:
Are we _changing_ how the M&O bits are interpreted, or are we merely clarifying how they are interpreted?
If we are merely clarifying, then I think we should do it here and keep the documents at DS.
If we are changing it, I think we need to figure out how to handle this so that neither 2461bis nor 2462bis needs to have a normative reference to the new document. To accomplish this, we would need to say enough (or perhaps little enough) in these documents that readers can completely implement address autoconfiguration and ND without knowing anything about the meaning of those bits. This may be possible, if they are truly ignored in deciding how/if to perform ND, DAD, address autoconfiguration, etc. But, that isn't currently clear in the documents.
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 issue.
I could accept this if you make it very clear what hosts that implement rfc2461bis and rfc2462bis are supposed to do when these bits are set.
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 PS.
As I'm sure you know, we can't just declare a reference informative because the referenced document isn't at a state that would allow this document to be published at DS.
IMO, it is quite clear that one can implement ND and addrconf without implementing DHCPv6, so it is fine for DHCPv6 to be an informative reference. We either need to make sure that the M&O bits can be handle the same way (ignore them in implementations of ND and autoconf, worry about them only if you implement DHCPv6), or we need to explain them appropriately here. Either one works, but a hanging textual reference to an as-yet-unpublished document doesn't.
I don't think we have any fundamental disagreements here, we just need to figure out how to get this right before we send it to IETF LC.
Thanks for all of your work on this document -- you are doing a very good job and this is important work!
Margaret
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
