What's the value of specification consistency?

[Ted Hardie <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf