Hi.
As others have pointed out, the length of this thread became fairly
daunting. I've skimmed through those 50-odd messages, but it seems
to me that they make one of my main points. However, unlike the four
area reviews listed on the document's datatracker page, I don't think
this document is ready or nearly ready. Instead, it appears to me to
need fairly significant work as well as providing an example of the
difficulties that can come with a document produced by an AD,
sponsored by an AD, and shepherded by an AD. At the risk of
overlapping with points made by others, a bit of a different
perspective:
(1) Independent of its substantive content, this document is not
ready for prime time. As an obvious example from reading the text,
the mention of BCP 97 in the I-D title and in Sections 1 and 2. is an
important reference, probably a normative one. The last paragraph of
Section 2 even appears to specify ways in which BCP 97 is, or is not,
overridden. Yet neither BCP 97, nor any of the RFCs that make it up,
are listed in the "Updates" or "Obsoletes" headers, nor do any of
them appear in the References.
I can't help thinking that sort of issue would not have escaped WG
review if a WG were involved. At least in my experience, it would
not have escaped review by an AD considering a document produced by a
member of the community as an individual submission. It might be
just a coincidence, but the appearance is that the documents went
into IETF Last Call because of special treatment of a document
written by one AD and sponsored by another who is also the Shepherd,
an issue that was called out with an earlier version of this I-D over
two years ago [1].
I don't believe that Erik has done anything wrong here -- as far as I
can tell, he is being extra-careful once issues are called to his
attention -- nor do I believe Murray has done anything wrong given
current rules and practices, but the optics are not good. I wonder
if it would be plausible for us to require that any document with an
AD author at least have a non-AD co-author who could take a little
bit more community-facing responsibility and/or that we require that
at least one of {author, sponsoring AD, and Shepherd} not be a
current IESG member and maybe not even a recent AD, IAB member, LLC
employee, or other "leadership" person.
(2) As others have pointed out, it is not really clear what the
document accomplishes. It may give more authority to the IESG in
some areas, but I think the IESG has much, perhaps all, of that
discretionary authority anyway. For the special case of a document
written by an IESG member, sponsored by an IESG member, and pushed
into Last Call without objections for anyone in the IESG, a document
expanding the IESG's discretionary authority may not be consistent
with our notions of community consensus, bottom-up processes, etc.
(3) Possibly not relevant, but, as we continue to adjust the number
of cases and circumstances in which the RFCXML form (which an
external document would presumably not reference because doing so
would involve a conversion method that we do not guarantee to be
stable) or presentation form may change, all of the bullet items in
Section 2 except the last might be said of IETF documents by some
external party, particularly an SDO.
(4) "Authors and editors should try to avoid such references due to
the challenges they present, as they affect the IETF's ability to
ensure the quality of its output." I think that sentence can
reasonably be interpreted as "the IETF has developed a strong "not
invented here" culture and any reference to work done elsewhere and
not documented in IETF-produced documents should be viewed with
suspicion and IETF work, even IETF work with known deficiencies
relative to common practices documented elsewhere, should be
preferred. We cannot mean that (or at least I hope we do not). As
others have more or less suggested, a model closer to the one used
for dependencies on work with IPR restrictions would be more
appropriate: if a document needs to use a reference to materials not
controlled by the IETF, authors/editors (and, where relevant, WGs)
should be required to consider the tradeoffs and justify and document
the reasons for their decisions. I'd prefer to leave it up to the
IESG to decide on a case-by-case basis whether those justifications
must be incorporated in the source document or can be supplied in
other ways as long as they are available to the community during
review.
(5) While I am reasonably comfortable trusting the IESG's discretion
as described in the third paragraph of Section 2 ("Authors/editors of
source documents..."), I think the IESG should have more flexibility
to negotiate access than the paragraph appears to imply. As one
example, we have sometimes been able to negotiate freely available
(and free) access to excerpts of documents or preliminary versions of
documents but not the documents themselves and, IMO, it would be
unfortunate to accidentally prohibit that option. As another, it is
not clear whether "during the source document's life cycle" applies
to, e.g., an I-D that is actively under development and/or review but
ends when an RFC is published or the I-D is abandoned or is more
expansive. It would make much more sense to me to allow the IESG to
work out appropriate limits on a per source (and target) document
basis than to have language in this document that appears to
constrain things. A third, and probably more important, example
involves "any member of the community that chooses to participate in
Last Call discussions". Given that many of us who were not involved
earlier with a document and unless we have specific review
responsibilities (most covered by other parts of that sentence), are
likely to look at the Last Call announcement and document abstract,
decide on that basis whether to read the document and maybe look at
some references, and only then decide whether to comment, we could
easily need access to referenced materials whether we actually
comment or not. That turns that "which includes" list into "any IETF
participant who is interested" and, essentially makes such documents
fully public (inconsistent with the following paragraph). I assume,
given the rest of that Section, that is not what was intended but at
least some clarification would be in order especially given (7) below.
(6) The summary option listed in the last paragraph of Section 2
should be made as attractive as possible because, as the paragraph
points out, it avoids many of the other problems. However,
especially if the intended target document is, itself, long and/or
complex, it raises two other issues that should probably be
mentioned. (i) The question of whether the IETF document accurately
"captures the important parts of the intended target document" or
represents some sort of more or less significant fork is critical as
it may make a claim about conformance to the original target document
dubious. This document would be strengthened if authors/editors were
strongly encouraged to reach out to the group or body that produced
the target document to get verification (or help in verifying) that
the IETF's extract or summary is accurate. The IESG should have the
authority to require such outreach and/or to specify that its
conclusions be documented along with the new RFC. (ii) RFC 3339 is,
unfortunately, an example of the other issue. The underlying
specification, referenced in the new RFC, may change. If it does,
the IETF may be faced with a choice between conforming to the newly
specified practice (which might be very broadly adopted and used in
other contexts) or sticking to whatever is described in our extract
or summary. Either this document should require that the
possibility or tradeoffs be described in the summary document or the
IESG should be enabled (and, IMO, encouraged) to require such a
discussion in the summary document, the source document that
references it, and/or any future IETF standards track documents that
reference the summary.
(7) There is a more general issue with other SDOs and their work
(this is more a comment on some other comments than on anything
specific in the -05 version of the I-D): Attractive as it might seem
for us to wrap ourselves in broad principles about openness and free
access to free documents, OpenStand statements, and the like, if our
goal is really an Internet that works better, reality is as, or more,
important. Part of that reality is that the IETF is not in charge of
the universe and that pretending that we are just aggravates whatever
credibility problems we are perceived as having. In particular, ISO,
IEC, their collaboration in ISO/IEC JTC1, and many of the national
member bodies associated with them derive a significant fraction of
their revenues from selling standards. Some of them have gotten
more flexible about free distribution of particular documents, or
documents in particular topic areas, in recent years, others have
not. Most are quite reasonable about sharing their draft/working
documents to get broader perspective and input with other standards
developers whom they consider peers (and after a great deal of work
many years ago, ISO and ISO/IEC do consider the IETF to be a peer
standards developer). They are also quite good about sharing
finished standard with peer standards bodies to aid them (including
us) to facilitate our developing work that depends on, or interacts
with, theirs. But, in either case, we need to ask. As a foundation
for asking and as part of it, we need to treat them, their work, and
their rules and constraints (including their business models and
other relationships) with respect. If we do, my experience is that,
at least since the OSI Wars fizzled out, we find ourselves dealing
with reasonable people.
On the other hand, if we really want to restart the old wars or start
a new one, we should remember at least two things: First, one of the
major, if not the major, reason TCP/IP prevailed the last time was
that it was demonstrably deployed and worked while their protocols
had been in "coming real soon" state and had been for years. That is
an advantage we probably would not have today. Second, in part
because of the relationships to (and between) national member bodies,
a few of whom are actually part of the relevant governments, and in
part because of the range of technologies they support, their
standards are far more likely to end up as requirements in laws and
regulations (and hence pressure on large corporate implementers) than
ours are. Not a war I'd be comfortable predicting that we would
win. Visibly losing would be bad for the IETF and possibly worse for
the future of an open, globally interoperable Internet.
john
[1] See, e.g., the thread including
https://mailarchive.ietf.org/arch/msg/ietf/UzHNmX058z0h21RAk8aO1Y2v_hQ
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
