Ballot for draft-ietf-urnbis-rfc2141bis-urn
Yes
No Objection
Abstain
Note: This ballot was opened for revision 20 and is now closed.
= General = I agree with Stephen that this spec seems unnecessarily long. There are a bunch of instances of repeated text in different sections that reference each other. I realize this doc was a negotiated outcome but if doing a streamlining pass is a possibility, it wouldn't hurt IMO. = Section 2.3.1 = Given that r-components are expected to be standardized elsewhere, I’m wondering if the expression of the normative requirements might be more prudent if it were phrased more along these lines: --- OLD Thus r-components SHOULD NOT be used for actual URNs until additional development and standardization work is complete, including specification of any necessary registration mechanisms. NEW Thus r-components SHOULD NOT be used for URNs before their semantics have been standardized. --- Since the expectation is that the future standardization efforts will take place elsewhere, it doesn’t seem justified to try to constrain those efforts by normatively recommending registry mechanisms or imposing an undefined notion of what it means for future standards to be “complete.” Better to be clear that all this document is doing is specifying syntax and therefore cannot constrain how people decide to use r-components in the future. I also was not sure what an “actual” URN is. = Section 4.4 = "Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by copy-and-paste techniques)." I know this was in 2141, but it seems needlessly constraining on applications and I would be surprised if every application that is aware of URNs actually does this. In general I think it would be preferable to avoid specifying normative requirements about what applications are to display, including the other requirements added to this section that were not in 2141. = Section 8 = Agree with Stephen's comment here. = Appendix C = "Truly experimental usages MAY, of course, employ the 'example' namespace [RFC6963]." It seems inappropriate to have normative language in this appendix.
I agree with Alissa's comment about the "r-component" section. It seems to me that defining the syntax without the semantics risks finding out later the syntax was wrong. I agree with the general comments that this seems longer than it needs to be, and that we should remember that excess text has a cognitive cost. But it seems too late in the process to do much about that. The review tracker indicates there has been no GENART or SECDIR reviews. That's unfortunate, but I guess not a show stopper.
I agree with Stephen about the document length. Although if the WG has spent 6 years on this already, I wouldn't want to see too many more cycles go into it.
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;-)