Subject: Response to appeal regarding the disposition of draft-nottingham-rfc7320bis

From: IETF Chair <[email-masked]>
Date: Tue, 24 Mar 2020 11:49:31 -0400

John,

The IESG has reviewed your appeal to the disposition of
draft-nottingham-rfc7320bis, and has considered the issues you raised,
both in general and in the case of the particular document in
question.

On the general issue of whether it is appropriate for an IETF
consensus document to be “effectively declaring any document that
deviates from its recommendations partially obsolete and in need of
updating,” we note that there certainly are cases where this is done
and is appropriate, when the community discovers that certain
behaviour is detrimental to the security or stability of the Internet.
A good example of this happened when MD5 was compromised, and it was
clear that we had to put out broad advice that we should no longer use
MD5 -- and, in that case, any protocols using MD5 needed to be
reviewed and appropriately updated.

BCP 190 has similar aspects: certain behaviour has been seen to be
detrimental to the stability and operation/deployment of applications
and services that use URIs, and BCP 190 provides important advice in
that regard.

The paragraph you cite as problematic, which, as you note, has been in
BCP 190 from the start and was not changed in
draft-nottingham-rfc7320bis, advises the relevant communities to
“determine an appropriate outcome”.  As the IESG reads that, we do not
see it as declaring documents partially obsolete; rather, we see it as
advice to review those relevant documents and, as the text says, to
determine what the right course of action is.  The two options given
as examples -- updating the URI scheme (to allow the behaviour
explicitly) or to change the specification (to remove the deviating
behaviour) -- are just that: examples of possible outcomes of such a
review.

Additionally, the very purpose of updating BCP 190 with this document
was to soften certain recommendations because of exactly the type of
review described in that paragraph.  It seems to us that BCP 190 is
working as it should, and the community is treating it as was
intended.  In this specific case, the IESG has reconsidered the
approval of draft-nottingham-rfc7320bis as written, and does not see a
problem that needs correction.

Documents in the more general case will, of course, have to be
addressed as they come.  When an issue comes up that requires
retroactive review, it is, of course, preferable if documents can be
reviewed and updated directly.  Situations where the effect is broad
enough that many documents are called into question -- indeed, where
it might not be readily known how many and which documents those are
-- might warrant similar treatment to BCP 190, with similar results,
and we agree that it’s important to approach such situations with
care.

In accordance with the foregoing conclusions, the IESG plans to
instruct the RFC Production Center to resume processing of
draft-nottingham-rfc7320bis on 10 April 2020.

On the other issues you note:

> 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.

We believe that is somewhat of a misunderstanding.  We consider that
the text had consensus when RFC 7320 was approved and that it is,
therefore, part of BCP 190.  Taking into account that the goal of this
update was to present a minimal change to correct something that was
too restrictive, we consider it best to avoid changes that do not have
a strong basis.  The correct claim would, therefore, be that because
the text had consensus then, it would require significant support or
clear demonstration that it is wrong or harmful in order to have it
changed.  We see neither significant support nor such a demonstration
in this case.

The generalization is that text with established consensus certainly
can -- and should -- be reconsidered when there is a good reason (such
as demonstration of incorrectness, harm, lack of clarity) to make the
change.

> 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.

As we state above, “it is, of course, preferable if documents can be
reviewed and updated directly,”.  But as we also state above, there
are situations where it is not practicable to have direct reviews of
all relevant documents, and that, therefore, we need to retain the
flexibility to say that certain behaviour is detrimental and is
sufficiently widespread that it needs to be addressed centrally, with
a recommendation for broader review, as BCP 190 is doing.  The goal is
always to encourage those reviews, which will ultimately align things
with what you suggest here: that the relevant documents will
eventually reflect, directly, the actual, known best practice.

The IESG hopes that this response is clear, and we certainly invite
you to continue this dialogue with us and with the community as a
whole, particularly if you think an update to BCP 9 is warranted.  And
we thank you for raising some important points that needed to be
considered explicitly.

-- The IESG

> On Feb 4, 2020, at 1:54 PM, John C Klensin <[email-masked]> wrote:
> 
> 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
> infallibility.
> 
> 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.  
> 
> thanks,
>   john
> 
> 
> 
> 
> --On Tuesday, January 28, 2020 11:41 -0800 The IESG
> <[email-masked]> 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.
> 
>