--On Tuesday, January 7, 2020 10:35 -0600 Adam Roach <adam@xxxxxxxxxxx> wrote: > To help with framing this conversation, the changes from RFC > 7320 are highlighted here: > > https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingha > m-rfc7320bis-03 > > I have some rather extensive thoughts on the process of > creating bis documents [1]. While I'm not going to reiterate > all of them here, I want to highlight a specific passage that > seems to bear on John's comments: > >> One major concern that drives these incremental document >> updates is that an attempt to republish an RFC as >> originally described in RFC 2026 can result in such an >> effort being bogged down by issues that exist in text >> unrelated to the desired changes. Such issues can >> arise from a change in the consensus of the IETF around best >... Adam, I studied those comments when you first posted them. I believe that I sent comments at that time, but to summarize and highlight them in a shorter note, I see a key problem (and several others that may be less important and that were addressed in my earlier comments) with an replacement document that does not address all open issues in its predecessor: It leaves the reader with the understanding that the new document represents the IETF's best understanding of the topic covered (not merely a view of the most urgent problems to be fixed). Put differently, it implies that any issues not address are unimportant. That can be mitigated somewhat by including a section identifying known outstanding issues, but draft-nottingham-rfc7320bis-03 does not appear to contain such a section. In addition, as your quoted comment above implies, an incremental document that nonetheless replaces an earlier one is a change to what 2026 specifies. I do not believe it is appropriate to change the procedures of 2026 by ignoring it, nor do I believe that examples of its being ignored in the past constitute justification for ignoring it in the future. Just as we tried to do with NEWTRK and ISDs (arguably a different approach to at least part of the problem you are trying to address), a change to how we handle replacement documents that ignores (if nothing else) 2026's "no known defects" rule requires an update or other change to 2026 before the desired approach is appealed to in order to justify a particular document. That, and my p.s., aside, I had hoped my note would rather carefully avoid dragging us back into either this issue or the ones raised by Phillip and Barry (like Barry, I don't fully agree with the former). It seems to me that both that comment and part of Barry's raise fundamental questions about how RFC3986 is defined and what it specifies. Those issues are probably best addressed at another time. Instead, I was trying to raise a far more narrow question: Given that RFC 3986 separates names and locators and that we have already had confusion about what is appropriate in URNs based on the language there, does this document make things worse? I think it may. Even a statement fragment (from the first paragraph of Section 3 and inherited from 7320) like "...as links that are exchanged as part of the protocol, rather than statically specified syntax" are inconsistent with the use of keyword values in some URN namespaces as static indicators. If you want to ask the slightly different question of whether, if RFC 7320 made things worse, does this I-D make things even worse than that, I don't have an easy answer except to note at least one example: The last paragraph of Section 2.3, which appears to be new, says > Extensions MUST NOT define a structure within individual URI > components (e.g., a prefix or suffix), again to avoid > collisions and erroneous client assumptions. But, as I understand that rule, it is precisely what some rules, and provisions for namespace-specific rules, in RFC 8141, do. Again, the solution at this point appears to be either to be much more careful about binding the statements in the I-D to the concept of ownership or to indication that this specification does not apply to URNs (or, if preferred, to what 3986 describes as "name" URIs) at all. best, john
