Hi Thomas, I think AS is a good idea to tell people what are prerequisites to make IPv6 works. There are already a lot of controversy in other places, e.g. BBF, on what are the subsets we must have in an IPv6 network. An AS document in IETF is very useful reference for the industry.
Hongyu > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of Thomas Narten > Sent: Wednesday, July 22, 2009 5:36 AM > To: ipv6@ietf.org > Subject: Node requirements: Issue 12 - status/scope of document > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
