[urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-urnbis-rfc2141bis-urn-21: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I am not convinced that doubling the amount of text vs. 2141
and 3406 here is really helpful. The draft also seems to
spend more time saying what it does not specify rather than
what it does. My not-that-well-informed guess is that this
product of stalwart effort does not improve the Internet,
despite the earnest extended multi-year efforts of the few
folks involved. I'd further bet that the world in general
would be fine if this did not become and RFC.  Normally,
I'd just ballot no-objection and let that go, but given
that this has consumed cycles for 6 years that could
perhaps have been more usefully engaged in dealing with
3986 issues, I think abstaining is a better position to
take on the off-chance that that sends some tiny form of
signal. (Apologies to those who engaged in this work, I
don't mean any disrespect, but I don't think the result
here is really worth the effort expended.)

- What deployed code supports the ?+ or ?= constructs?  If
some arguably "important" code does, I'd change my abstain
to a no-objection, as then there'd be an at least modest
new feature to justify the new RFC.

- Section 8 should I think recognise the dangers inherent
in long-term stable identifiers helping with
(re-)identification of people and/or network entities.
While that is not the "fault" of URNs, I'd say it is worth
warning folks who may just possibly think twice before
creating new URNs with those failings. (Though I recognise
that that may call for a reference to RFC6919;-)