Skip to main content

Appeal re Protocol Action: 'URI Design and Ownership' to Best Current Practice (draft-nottingham-rfc7320bis-03.txt) (John Klensin; 2020-02-04) - 2020-02-04
Appeal - 2020-02-04

From: John C Klensin <>
Subject: Appeal re Protocol Action: 'URI Design and Ownership' to Best
Current Practice (draft-nottingham-rfc7320bis-03.txt)
Date: February 4, 2020 at 13:53 EST
To: The IESG <>


As I promised Adam I would do, I am appealing the approval of
draft-nottingham-rfc7320bis-03. The core issues below were
raised during Last Call (and earlier) and, in my opinion,
basically blown off.

The Issue

The IETF has had a long-standing concern about users of our
specifications not being able to tell what "the standard" for a
particular topic really consists of. We've responded to that
concern with a few Applicability Statement documents (the
classic examples are RFCs 1122 and 1123), some "roadmaps" (e.g.,
RFCs 6071 and 7414), and even a working group or two (notably
NEWTRK). The IESG itself has also responded with guidelines for
authors and the RFC Editor that require that any document that
updates or changes the technical content or applicability of
another be very explicit about what is being updated or altered
and what the changes are.

Section 1.1 of this specification appears to be at variance with
that history and the underlying principles. It says, at the end
of that Section:

"There may be existing IETF specifications that already
deviate from the guidance in this document.  In these
cases, it is up to the relevant communities (i.e., those
of the URI scheme as well as that which produced the
specification in question) to determine an appropriate
outcome; e.g., updating the scheme definition, or changing
the specification."

effectively declaring any document that deviates from its
recommendations partially obsolete and in need of updating -- a
sort of super-erratum but immediately binding and effective in
ways that errata never have been -- and one that does not
specify the documents to which it applies.

If it had said, instead, something like:

"The intent of this Best Practices specification,
supported by the reasoning and examples below, is that
any IETF specifications that do not align with its
recommendations SHOULD be examined when they are next
opened and aligned as appropriate"

that would still not be ideal from the standpoint of clarity
about which documents are affected and how, but it would at
least be clear that this is a recommendation about best
practices rather than a specification that obsoletes parts of
specifications and requires that they be updated.

Additional Issues in Need of Clarification

The problem text quoted above appears to be bound up with two
other issues, ones that I urge the IESG to address explicitly.

(1) It has been claimed that this text is ok because it appeared
in RFC 7320 and therefore should not, perhaps cannot, be
considered inappropriate and in need of change. A
generalization of that argument would prevent our ever producing
a new document that changes the requirements of an earlier one.
That which would be absurd as well as abandoning our principle
of reflecting running code in our standards and other work.
Perhaps one could argue that this text is nonetheless ok by
asserting that nothing has changed since the IETF first approved
a document containing the text, but that would imply that we
(the community generally and the IESG in particular) have never
overlooked an issue or made a mistake and never will. Perhaps
some will disagree or see such claims differently, but I think
the IETF should be extremely skeptical about implied claims of

If the IESG intends to allow "we have said or done it before and
therefore it is ok" claims to be considered during Last Call and
IESG evaluation, it would be very helpful to get a clear
statement about when precedents can be cited in that way and to
get community consensus for it rather than having it slide
through on a document by document basis with no explicit
community discussion.

(2) RFC 2026 appears to be very clear that a Proposed Standard,
at least, "should have no known technical omissions with respect
to the requirements placed upon it" and provides for the IESG to
make specific exceptions (and document them). While it can be
argued either that this provision does not (or should not) apply
to BCP documents or that "technical omissions" can be defined
narrowly enough to make the requirement a non-issue, it seems to
me that it would be very helpful for the community if the IESG
were to take a position on how much a technical BCP-type
specification could get into areas in which there was
considerable controversy about whether the recommendations were
actually consistent with deployed and proven best practices
and/or could make technical changes to [non-BCP] standards track
documents. In particular, while it seems completely reasonable
for a BCP to update or clarify sections of a Proposed Standard
(or even an Internet Standard) that are essentially
Applicability Statements or other guidance, a BCP that alters a
technical specification itself seems problematic from both a
procedural (e.g., RFC 2026) and standards-setting point of view.

I think this may be especially important in the light of the
now-expired draft-roach-bis-documents-00. Some of the arguments
and suggestions made there about incremental documents were used
to justify avoiding revisiting some issues as
draft-nottingham-rfc7320bis was being developed. It would be,
at least IMO, undesirable to effectively modify provisions of
2026 on the basis of an I-D that did not get clear community
review and consensus.

Again, I think things have reached the point at which it would
be very helpful for the community if the IESG clarified its
position on the issues sufficiently to make it clear whether
there was community consensus or not.


--On Tuesday, January 28, 2020 11:41 -0800 The IESG
<> wrote:

The IESG has approved the following document:
- 'URI Design and Ownership'
(draft-nottingham-rfc7320bis-03.txt) as Best Current Practice

This document has been reviewed in the IETF but is not the
product of an IETF Working Group.

The IESG contact person is Adam Roach.