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 <john-ietf@xxxxxxx> 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 > <iesg-secretary@xxxxxxxx> 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. > >
