On Mon, Sep 9, 2013 at 7:19 PM, Dave Cridland <dave(_at_)cridland(_dot_)net>
wrote:
I'm not sure the consensus requirement you're suggesting actually exists.
This is aiming at Informational, and as such:
An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation. The Informational
[RFC 2026 §4.2.2]
Fair enough. But the document then proceeds to use RFC2119 normative
language, which is not appropriate because it's not a standards track
document. Normative language is not appropriate for informational
documents; there was a big discussion over that for RFC6092, and that ended
up being published with a note well saying, "this document is not a
standard, and conformance with it is not required in order to claim
conformance with IETF standards for IPv6." You may note that no such
"conformance is not required" text is present here. This is at best
confusing and at worst misleading.
If this document were to plainly state that it simply represents the set of
features that a particular set of operators feels is necessary for IPv6
deployment on mobile networks, but that it is not an IETF standard, and
compliance with it is not necessary to deploy IPv6 on mobile networks or to
claim conformance with IETF standards, I would have no objection to it.
But the IETF doesn't define profile documents. The IETF defines technical
standards on the basis of rough consensus and running code. What you're
saying is "since we don't have running code that does what we want, we're
trying to define a profile in the hope that someone will write the code".
That's not the way it works.
No, the IETF has published profile documents in a number of cases. One
could argue that RFC 1122 and RFC 1123 are both profile documents,
actually, but there are other specific examples, like the Lemonade profile,
for example.
I had written a few paragraphs explaining why this document and RFC 1122 /
1123 are not even remotely comparable, but I think that's beside the point
of this discussion. I think the main point is that RFC 1122/1123 are
standards and this document is not intended to be one.
I suspect, however, that this document is actually a standard, or intended
as one. There's discussion about conformance, about testing for
conformance, and so on, which suggests that an operator (in particular)
might treat any resultant RFC as a standard without regard for its IETF
status.
Absolutely. Such an operator might well decide to say that the requirements
for all devices on their network are captured in this standard, and the
IETF would have nothing to say about it. But the point is that it would be
the operator setting the requirements, not the IETF. The IETF cannot set
requirements in an informational document.
That's a concern, though in practise, if this is to be a document detailing
"what operators want", I'd be happier that it's published through the IETF
as Informational than not published at all - and in any case, no amount of
pretence will alter the fact that people will treat any RFC as a standard
if it suits them anyway.
Sure, but if said document said "this is not a standard" in so many words,
then that would be a difficult position to convince others of.