The WG needs to decide what the scope and purpose this document should be. Overall, my sense is that the purpose of this document should be to provide guidance to implementors (and others, e.g., those creating IPv6 protocols for specific environments) on what IPv6 functionality they should implement in their products. That is, to provide a proper IPv6 stack, what needs to be provided.
Even within that, once could take narrow view and require just the minimal basics needed to get useful IPv6 communication. Alternatively, one could try and mandate more advanced features that might not be critical for basic communications over IPv6, but would be "nice to have". Or we could do something in between. My personal opinion is that this document should only mandate core functionality, features that we really want all nodes to implement in order to provide reasonable IPv6 service to upper layer applications. For less critical or extended functionality, the document should apply guidance and advice as to the scenarios or conditions where the feature has value, but leave the choice to the implementor (i.e., a MAY or SHOULD). I believe that is also consistent with what is currently in the document (though more context/guidance would be appropriate in some cases). Looking at RFC 2026 (thanks Brian), it does say: 3.2 Applicability Statement (AS) An Applicability Statement specifies how, and under what circumstances, one or more TSs may be applied to support a particular Internet capability. An AS may specify uses for TSs that are not Internet Standards, as discussed in Section 7. An AS identifies the relevant TSs and the specific way in which they are to be combined, and may also specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented. An AS also specifies the circumstances in which the use of a particular TS is required, recommended, or elective (see section 3.3). ... I believe that in essence, we want to provide an applicability statement for the various pieces of IPv6. That means we can make a statement about an RFC as whole (i.e, the entire RFC), or even say something about specific subfunctionality within an RFC. What we wouldn't do is have this document try and update or clarify ambiguities in the existing specifications. E.g., the M&O bits discussion, etc. For one thing, if try to do that, we will likely never get done. Second, the right way to fix problems with specs is to either reissue them, or just publish a short document that just corrects/updates the one issue. If we take the approach of being an AS, I think we can side step the question of inforomational vs. BCP for now. Whatever route we end up going, the content of the docuent would be the same. Thoughts? Does this make sense? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
