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

[Mark Nottingham <[e-mail]>]

John,

In my mind (albeit containing limited knowledge of URNs), exempting URNs isn't the right solution, because they potentially face the same issues as more traditional URIs.

For example, if someone were to come along and say "the string 'foo' in fragment identifiers is magical", that would affect URNs as well, probably to their detriment unless the proper work were done.

Of course, if the definition of a particular NID or whatever allowed such a thing to be done, it would be fine -- within that scope -- and I think that's already covered by the draft.

Likewise, if URNs want to define special conventions overall for URNs, that's also within scope -- provided that the scheme is updated properly.

If this isn't clear enough in the document, I'm happy to make it so.

Cheers,


> On 9 Jan 2020, at 3:33 pm, John C Klensin <[e-mail]> wrote:
> 
> 
> 
> --On Wednesday, January 8, 2020 12:11 -0600 Adam Roach
> <[e-mail]> wrote:
> 
>> To be clear, what I posted is my personal opinion (as are the
>> following two paragraphs), and isn't an official IESG
>> position, much less an IETF consensus position. Nothing in the
>> process prevents you from commenting on whatever you want.
>> 
>> That said, I think it is a bad idea to slow down or stop
>> improvements to a document by asking for unrelated and
>> possibly contentious changes, especially at (or, to be honest,
>> somewhat after) the last minute. The IETF has a long history
>> of letting "perfect" become the enemy of "good," leading to
>> author frustration, participant fatigue, and very long delays
>> in publication.
> 
> Adam,
> 
> To clarify in return: In part because I was painfully aware that
> the nominal closing date for the Last Call had passed, I was
> careful to ask myself two questions before posting anything.
> They were (1) Is there anything in this I-D that is sufficiently
> confusing or otherwise problematic that it could plausibly be
> used in the future to impede other work even thought the IETF,
> broadly, was not aware of that potential issue when it was
> approved?  I believe that question is reasonable whether the
> issue appears in the predecessor document or not. (2) Given that
> there is a predecessor document, is there anything in this I-D
> that could make things worse, rather than better?  Now, both of
> those questions, but especially the second, go to your comment
> about "improvements to a document".  Even if I had no other
> reservations about your model of incremental documents (at least
> as I understand it), if some changes make things worse, it seems
> to me unreasonable to me to ignore them and assert that the
> document should go through because some of the proposed changes
> are improvements.  I hope you agree.
> 
> For the same "lateness" reason and in recognition of your (and,
> incidentally, my own) concerns about "unrelated and possibly
> contentious changes", I was careful to propose an extremely
> simple fix in the form of a clarification about URI types to
> which the specification does not apply. 
> 
> The particular issues in this case are especially important
> because there is a history of text in RFC 3986 and associated
> documents (text that some would suggest was ill-considered) has
> been used in the past to block, impede, or nit-pick relatively
> recent work on URNs to the point that the WG gave up and
> concluded, essentially, that part of the work could not be done
> in the IETF.   That turns the implied question of plausibility
> above from a hypothetical into a known reality and, wrt this
> particular document, should force the question of whether it is
> part of the problem or part of the solution... again, going to
> questions about sweeping assertions of "improvement".  That
> seems especially important in this case given the recent
> [re-]appearance of "later, therefore superceding or more
> authoritative regardless of 'updates' or 'obsoletes' status"
> arguments in the IETF, reinforced by text in this I-D that
> appears to me to say that any specification that disagrees with
> the recommendations of this one is broken and requires a fix.
> 
> Of course, if one reads the I-D (and 7320) the way Barry does,
> as simply not applicable to URNs or other URIs whose structure
> is not hierarchical, then there is no problem at all.   A number
> of comments that followed my original message strongly suggest
> that reasonable people in the community do not find that reading
> as obvious as Barry does.  And, again, the best solution at this
> point is not a rewrite or other major change, just insertion of
> a short clarification about scope and/or applicability.
> 
> 
>> For further clarity: I think it would be completely reasonable
>> to turn around and propose yet another bis version of BCP 190
>> to fix any further perceived defects as soon as this version
>> is published, and then work towards building consensus that
>> such changes are required.
> 
> My apologies, but I think the above is sufficiently hypothetical
> to be, in practice, spurious. draft-nottingham-rfc7320bis is an
> AD-sponsored document, sponsored, if I read the tracker
> correctly, by you.   Now, suppose that someone were to post an
> I-D tomorrow, or at some point pre-publication of
> draft-nottingham-rfc7320bis, proposing to replace it with a new
> version and address other issues.    Would you be willing to
> AD-sponsor that draft or would you (as I hope you would) say
> "the community has spent enough time on this issue for a while,
> so, unless a critical emergency causing serious harm can be
> demonstrated, let's let it sit for a year or three" (or impose
> criteria for level of obvious community interest that would
> amount to the same thing).  Even if your answer is "yes, you
> would sponsor it", can you guarantee that someone would do so
> after March 27 (versus putting it off for an extended period or
> forever)?  
> 
> We've seen enough things die in the IETF because the problem
> wasn't big and pressing enough and no AD felt like sponsoring
> the work (for whatever good, bad, or arbitrary reasons) that
> saying "it would be completely reasonable to turn around and
> propose yet another bis version..." is unpersuasive in the
> absence of guarantees that I don't believe any sensible AD would
> make. 
> 
>> The changes in the current bis are
>> needed to address a demonstrable and ongoing problem. It seems
>> imprudent to delay needed tactical changes based on
>> last-minute musings about what else might be changed.
> 
> If this were a technical specification and there were
> significant technical issues (e.g., requirements that
> implementation experience had demonstrated were infeasible), I'd
> certainly agree with "imprudent to delay".  But, this is a BCP
> and, as others have pointed out, almost all of the changes are
> dropping 2119/8174 requirements language in favor of lower-case
> statements and more general guidance.  If the one-sentence
> description of "Changes from RFC7320" in Appendix A of the I-D
> is accurate, that is _all_ of the changes.   Getting from there
> to "demonstrable and ongoing problem" and/or "needed tactical
> changes" seems to me like a stretch. YMMD, but it is clear from
> other comments that I'm not the only one to react that way.
> 
>  best,
>    john
> 
> 

--
Mark Nottingham   https://www.mnot.net/