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

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

--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