Like a lot of other IESG folk, I've tried to catch up on the threads of the past few days. Lurking at the bottom of some of them is, I believe, a more general question to the IETF: what level of effort should we put in as the IETF (by whatever group) in ensuring that the specifications we produce are consistent?
As it stands now, the RFC Editor staff puts in a great deal of effort to ensure that the individually submitted RFCs form part of a coherent series, as well as being useful contributions to Internet Engineering. Similarly, the IESG puts in a fair amount of effort working on questions of consistency. Some of these are ID-nits level (work that is currently being shifted to the WG Chairs, according to the PROTO framework). But many of them are at level above that. As an example: if a document out of one working group was asked to create a registry for something, should a document from a different working group using the same underlying technology also create a registry?
Note that this is not purely hypothetical; I asked the same question of the IESG in a comment on draft-ietf-pkix-pkixrep-03.txt:
For draft-ietf-impp-srv-04, we required an IANA maintained registry that allowed someone to map _im._bip to a specification of how _bip used SRV records. Seems very similar, in that PKIXREP will actually map to different using protocols like OCSP, LDAP, or HTTP; these aren't just transports, like tcp or udp, they have different syntax (and frankly the use of HTTP for this means a convention at a level even SRV can't handle).
If these folks don't want to go the DDDS road, would requiring a similar registry make sense here?
(Note: please don't get bogged down in the example; it's not at the core of what I'm asking).
It's my personal believe that the IETF standards form a body of work, rather than just being individual specifications, and that some level of effort should be put in to make sure that the individual documents fit into the body. We've done some of that through mechanisms like the RFC 2119 language and the IANA considerations guide, so I think there is some community consensus that this is useful.
I'm very interested, though,in opinions on where that line should be drawn. I get lots of late review comments from experienced people of the form "The IETF doesn't do specs of the form $FOO", which imply that the IESG at a late stage should enforce this consistency. This happens even when the document is the product of a working group which came to consensus on a spec of form $FOO. I also get comments, sometimes from the same folks, which say that the IESG should never block a document upon which a working group came to consensus unless they can demonstrate that doing so is necessary to protect the Internet. If I weren't in a good mood today, I would suspect that what they really mean is "Don't block *my* document, unless you can prove it will harm my document." As I am in a good mood, I'm more inclined to believe that the experienced folk are, in fact, trying to create a sense of the IETF standards over time, and that the "IETF doesn't do specs of the form $FOO" is trying to represent the consensus over time and the impact it should have on consensus being actively formed now.
Working out where the consistency bar should be set is sometimes easy, as documents fit comfortably within our community's shared sense of the range. When it is hard, though, the effort and time it takes to get things agreed is enormous, and the ill-mannered can play a war of attrition to get their way.
To get this back to the form of a question: what is the right value of consistent for the statement: "The IETF should produce a consistent set of specifications?" Same language, format, and no more? Anything already documented in an RFC like 2219? Same set of core assumptions/built from the same tools? Something less? Something more? Something along a different axis entirely?
regards, Ted Hardie
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf