On Wed, Sep 4, 2013 at 10:25 AM, Lorenzo Colitti <lorenzo@xxxxxxxxxx> 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.