>>>>> On Sat, 16 Oct 2004 12:13:46 -0400, >>>>> Margaret Wasserman <[EMAIL PROTECTED]> said:
>>> (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. [...] > 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. Okay, I think I understand your point, thanks for the detailed explanation. I think many other comments from depend on this issue, so I'll concentrate on this one at the moment. Regarding your basic question, it probably depends on the meaning of "change/clarify". But we are at least going to *change* some part of the specification that was described in RFC2462. To explain the background motivation of the *change*, I'd refer to a past message in this ML from Christian Huitema: >>>>> On Sat, 24 Apr 2004 22:08:28 -0700, >>>>> "Christian Huitema" <[EMAIL PROTECTED]> said: > The normal IETF practice is that when a document progresses from PS > do DS and then to standard, parts of the specification that are not > actually present in implementations get removed from the spec. As > much as I can tell, we don't have much actual implementation of the > M/O bits. If we follow the logic of the process, we should remove > the corresponding sections from the spec. (Or see http://www1.ietf.org/mail-archive/web/ipv6/current/msg02372.html to get the entire message with the context of the discussion) In the actual discussion, this was just an intermediate post, and we did not actually "remove" the corresponding sections for the M/O flags altogether. But I believe our consensus in this discussion was that we'd need more time to bake the precise behavior for the M/O flags and that the status of the specific action had not reached the level of a DS. That's why we decided to leave the specific behavior to a separate document. I'd first like to know whether the decision so far is acceptable. If this is acceptable, the "resolution" for this issue is to make rfc2462bis (and perhaps 2461bis) less confusing (if it currently is) on the status of the M/O flags. I personally do not think it is that confusing to say like: "The details of how a host may use the M flag, [...] will be described in a separate document" (rfc24622bis-06, Section 4). In fact, when RFC2462 became a DS, we even did not have a (standardized) specific "stateful protocol", but we could still say in the RFC that "the details of autoconfiguration using the stateful protocol are specified elsewhere." (abstract of RFC2462) A possible approach that may help is to clarify why we decided to leave the specific usage to a separate document, explaining the current maturity of the M/O flags, without referring to a particular document. This is my first (and preferred) proposal. If this is not enough, we'd need to refer to the "separate document". In this case, we seriously have to consider the reference category as you pointed out. But I personally think we can refer to it (whatever it is) as an Informational reference, considering the current maturity. I also believe we'll then have to wait for at least one wg document for this (since individual documents are so fragile even as an informational reference). Thus, my second proposal is to wait for a wg document and to refer to it as an informational reference. (This is the "second" proposal because I *personally* believe we can safely explain the current situation without specifying a concrete reference and also because even wg I-Ds are still often subject to change.) Again, I'd like to know whether the background motivation is acceptable, and if it is, whether one of the above proposals can be a resolution for the issue. Thanks, 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 --------------------------------------------------------------------
