On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti
<lorenzo(_at_)google(_dot_)com> wrote:
I'm just saying it here so that everyone in the community can see it. If
it's an IETF document it has to have IETF consensus, and since I feel that
the arguments were not properly taken into account in the WG (read:
ignored), I think it's important that the community see them before we
publish this document.
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]
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 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. 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.
What may be more useful, though, would be to get more stakeholders involved
in a commonly agreed profile, and supercede this.
Dave.