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.
