Last Call Review of draft-spinosa-urn-lex-11

Request Review of draft-spinosa-urn-lex
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-09-14
Requested 2017-08-17
Authors PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo
Draft last updated 2017-09-20
Completed reviews Opsdir Last Call review of -11 by Scott Bradner (diff)
Genart Last Call review of -11 by Paul Kyzivat (diff)
Opsdir Telechat review of -13 by Scott Bradner
Genart Telechat review of -13 by Paul Kyzivat
Assignment Reviewer Scott Bradner
State Completed
Review review-spinosa-urn-lex-11-opsdir-lc-bradner-2017-09-20
Reviewed rev. 11 (document currently at 13)
Review result Has Issues
Review completed: 2017-09-20


his is an OPS-DIR review of A Uniform Resource Name (URN) Namespace for Sources of 
Law (LEX) draft-spinosa-urn-lex-11.txt.

The document describes a URN syntax and provides a set of principles relating to
 a resolution service for the URNs.

I do not quite know how to approach this document for an OPD-DIR review since such 
reviews primarily focus on any issues that might impact a network operator or the operator
 of a service and this document mostly consists of the URN syntax and support for the syntax.

The document mentions that "the "lex" namespace resolver will be expected to cope with a wide 
variety of "dirty" inputs" (section 8.1).  The document attempts to describe a design of a "flexible and 
robust" resolver but I expect that the foibles of the real world will too frequently cause resolution failures - 
I do not have any suggestions to make this less likely although it seems to me that being quite as forgiving 
in what the resolver tries to deal with (partial matches, etc.) may not be worth the effort.  It seems to 
me that the only way for someone to have a LEX URN to resolve is to get it from a publisher (since it will 
be essentially impossible for someone to guess one) why is it not reasonable to assume the URN is an 
accurate copy of what the user received and simply reject it if it does not parse.  (I say that it seems 
impossible for someone to guess since the URN hierarchy and components seems so locally defined.)

So, personally I would recommend removing the fuzzy matching part and thus simplify 
operation and reduce operational issues.