I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-spinosa-urn-lex-11 Reviewer: Paul Kyzivat Review Date: 2017-09-14 IETF LC End Date: 2017-09-14 IESG Telechat date: TBD Summary: This draft has serious issues, described in the review, and needs to be rethought. General Comments: I had great difficulty deciding how to approach this review. Rather that pick at lots of small points I have elected to focus on the the ones I find most notable. As part of doing this review I investigated prior discussions of prior versions of this draft (by Barry Leiba, Patrik Fältström and Dale Worley), that have occurred over several *years*. I found some substantial issues raised that IMO were not adequately addressed. The following is a useful starting point into that discussion: https://www.ietf.org/mail-archive/web/urn-nid/current/msg01270.html I have borrowed some points from that discussion and from other information that Dale Worley sent privately to you. Issues: Major: 2 Minor: 5 Nits: 0 (1) MAJOR: Scope of the document This document is nominally the specification of a URN. However the actual scope of the document is much broader - partially specifying a complete system for federating the naming and access to legal documents. Much of the contained information goes well beyond what is useful for defining the URN, and yet is frustratingly incomplete when it comes to defining the broader system. It would be better to split this into multiple documents. One would cover solely the specification of the URN, while the other(s) would define the broader system in which the URN operates. (2) MAJOR: Name or query? A URN is by definition a *name*. Some parts of this document do focus on the lex URN as a name. But the document also proposes using the lex URN as a *query*. The following text from section 2 highlights this: "To cope with possible incomplete or inaccurate uniform names, the implementation of a catalogue, based on a relational- database, able to associate a URN to related URLs, is suggested, as it will lead to a higher flexibility in the resolution process. A resolver can provide names normalization, completion of inaccurate or incomplete names, and finally their resolution in network locations (see Section 8.2 and 8.3 for characteristics and behaviour of a catalogue for resolution)." This behavior is inconsistent with the intent of URNs. (3) MINOR: Jurisdiction identifiers: URNs are required to remain valid indefinitely. But country codes are occasionally reassigned. The draft doesn't fully resolve this problem. Specifically, section 11.2 doesn't address the case where a request comes from a jurisdiction that corresponds to a country and the jurisdiction code is the same as a top level ccTLD, which *is* already registered for a different entity. A solution could be to simply follow the rules for a multinational or international organization in this case. The suggestion in section 11.2 to use names of the form '.lex' in effect appropriates 'lex' as a TLD, even though it has not been so assigned. Or else it presumes that it never will be assigned. This is a bad assumption. Some other naming convention should be chosen for this case. (4) MINOR: Full utility of this URN form as described in this document seems to require a browser extension for resolving lex urns, or for urns in general. It is not at all clear that such an extension will be widely deployed as part of standard browser distributions, limiting this function to users who extend their browser with a plugin. And browser support for plugins is decreasing. I would hope to see an explanation for using lex URNs without such a browser extension. However, the mechanism for resolving URNs probably belongs in a companion document. (5) MINOR: Use of Punycode The document calls for use of %-encoding to handle non-ASCII characters. The inclusion of %-encoding within allows this widely. However, section 4.4 recommends that non-ASCII characters be handled by Punycode-encoding them. Because Punycode contains "-" it isn't valid according to the current syntax in the many fields that are defined as 'alfanum *normal'. The inclusion of Punycode appears to have been an afterthought. If it is to be supported then it needs much better specification. (6) MINOR: Ambiguity between components and features The syntax for : manifestation = format *(";" specification) ":" editor *(";" specification) [":" component *(";" specification)] [":" feature *(";" specification)] is syntactically ambiguous in that in a form like: urn:lex:it:stato:legge:2000-04-03;56 $application-pdf;1.7:parlamento.it:xxx it is not clear whether "xxx" is a "component" or a "feature". (7) MINOR: Purpose of the Attachment D There are no references to Attachment D within the body of the document, and it seems entirely unnecessary to the understanding of the document. This ought to be removed - perhaps incorporated into another document describing a proposed system for using and resolving lex URNs.