Skip to main content

Last Call Review of draft-spinosa-urn-lex-11
review-spinosa-urn-lex-11-opsdir-lc-bradner-2017-09-20-00

Request Review of draft-spinosa-urn-lex
Requested revision No specific revision (document currently at 24)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-09-14
Requested 2017-08-17
Authors PierLuigi Spinosa , Enrico Francesconi , Caterina Lupo
I-D last updated 2017-09-20
Completed reviews Opsdir Last Call review of -11 by Scott O. Bradner (diff)
Genart Last Call review of -11 by Paul Kyzivat (diff)
Opsdir Telechat review of -13 by Scott O. Bradner (diff)
Genart Telechat review of -13 by Paul Kyzivat (diff)
Assignment Reviewer Scott O. Bradner
State Completed
Request Last Call review on draft-spinosa-urn-lex by Ops Directorate Assigned
Reviewed revision 11 (document currently at 24)
Result Has issues
Completed 2017-09-20
review-spinosa-urn-lex-11-opsdir-lc-bradner-2017-09-20-00
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.

Scott