Re: [urn] URNs and Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

[John C Klensin <[e-mail]>]

--On Tuesday, January 7, 2020 10:35 -0600 Adam Roach
<[e-mail]> 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