Last Call Review of draft-spinosa-urn-lex-11
review-spinosa-urn-lex-11-genart-lc-kyzivat-2017-09-14-00

Request Review of draft-spinosa-urn-lex
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-09-14
Requested 2017-08-17
Authors PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo
Draft last updated 2017-09-14
Completed reviews Opsdir Last Call review of -11 by Scott Bradner (diff)
Genart Last Call review of -11 by Paul Kyzivat (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Review review-spinosa-urn-lex-11-genart-lc-kyzivat-2017-09-14
Reviewed rev. 11 (document currently at 13)
Review result Not Ready
Review completed: 2017-09-14

Review
review-spinosa-urn-lex-11-genart-lc-kyzivat-2017-09-14

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 '<name>.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 <alphanum> 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>:

               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.