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