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
--------------------------------------------------------------------
