I've recently reread draft-ietf-6man-node-req-bis-02.txt, and I think it might be good to think about the overall purpose/scope of this document.
We have often said/assumed that the document is informational, and does not make any new requirements that don't already exist in standards track RFCs. I believe such an assertion is false. Consider the introduction: > 2. Introduction > > The goal of this document is to define the common functionality > required from both IPv6 hosts and routers. Many IPv6 nodes will > implement optional or additional features, but this document > summarizes requirements from other published Standards Track > documents in one place. > This document tries to avoid discussion of protocol details, and > references RFCs for this purpose. This document is informational in > nature and does not update Standards Track RFCs. Not entirely true. It does include MUSTs of entire RFCs or subsections of RFCs (e.g., DAD). But, some/many of those existing RFCs are all "optional" in the sense that they don't say you MUST implement them. IETF Documents rarely say "you MUST implement me to be compliant with IPv6 (or IPv4)". I'm not saying that any documents are wrong or need updating. However, the basic nature of IETF specs are that they are optional. For example, the document says: > The IPv6 Addressing Architecture [RFC4291] MUST be supported. But 4291 doesn't use 2119 terminology at all, and I don't see any wording suggesting that an IPv6 node must implement it to be compliant > 5.6.2. IPv6 Stateless Address Autoconfiguration - RFC 4862 > > IPv6 Stateless Address Autoconfiguration is defined in [RFC4862]. > This specification MUST be supported for nodes that are hosts. > Static address can be supported as well. 4862 doesn't anywhere say it must be implemented, though it is pretty obvious that any IPv6 implementation that doesn't include 4862 is pretty deficient and won't interoperate with other IPv6 nodes. But my point is that no Standards Track document mandates implementation of 4862. Then, take another example: > 5.6.3. Privacy Extensions for Address Configuration in IPv6 - RFC 4941 > > Privacy Extensions for Stateless Address Autoconfiguration [RFC4941] > SHOULD be supported. It is recommended that this behavior be > configurable on a connection basis within each application when > available. It is noted that a number of applications do not work > with addresses generated with this method, while other applications > work quite well with them. I took a quick glance at 4941, and I don't see any reference to being able to configure stuff on a per-connection basis. (I.e., it's not mentioned in "3.6. Deployment Considerations"). That said, rather than looking at any of these and picking on them, I'd like to up-level and ask what this document is trying to achieve. When I read through the bis document, I found it contained very little info in some cases (just a sentence pointing to a spec) or more detailed information where specific requirements were extracted from a particular RFC, as if to emphasize them more (e.g., consider Section 5.1, which talks about 2460). Maybe there was a reason for having all that specific text back when we did (anyone remember why?). But some of the text seems redundent and unnecessary at this time. Should we trim it down? My opinion is that there are a number of groups that have (or will) be doing profiles of IPv6 over the next few years (e.g., as NIST and DoD have done). What is in those profiles is very important. Many of those documents will use the IETF node requirements doc as starting point. Thus, to be useful, IMO, we should be providing more context and guidance as to which to include and in what environments. That would be more useful than just a "you SHOULD implement X". The current document is simply too sparse to achieve that. Consider privacy extensions again. It has a simple SHOULD recomendation that it be implemented. IMO, that is not helpful. There is no need for routers to implement the spec. There is no need for traditional servers to implement it. It only makes sense for mobile devices to implement the extensions. And probably only devices that are "personal" in the sense they belong to one (or a small number of) individuals. But, if the IETF just says SHOULD, other folk doing profiles may blindly include it in their profiles, when that doesn't really make sense. I'd like to propose that we turn this document into more of an applicability statement. That is, mention specific RFCs, but include context/applicablity wording that would guide an implementor (and profile writer) as to what the RFC is useful for and when one might want to implement it. Thoughts? Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
