Robert,
To save time, let me response to a few of the questions you
raise. (Peter, feel free to plagiarize.)
--On Tuesday, May 1, 2018 11:35 -0700 Robert Sparks
<rjsparks@xxxxxxxxxxx> wrote:
> Reviewer: Robert Sparks
> Review result: Ready with Issues
>...
> Document: draft-hakala-urn-nbn-rfc3188bis-00
> Reviewer: Robert Sparks
> Review Date: 2018-05-01
> IETF LC End Date: 2018-05-21
> IESG Telechat date: Not scheduled for a telechat
>...
> Why is there no shepherd's writeup? It would be good to
> explicitly let the community know why this is proceeding as an
> individual draft.
The URNBIS WG, which had the predecessor version on its agenda
as draft-ietf-urnbis-rfc3188bis-nbn-urn, explicitly discussed
processing of this document and decided it was more
appropriately handled as an individual submission. That was
largely because the procedure for registering new URN namespaces
was being changed from IETF review and approval (in RFC 3406) to
a modified form of Expert Review (in RFC 8141). The author,
encouraged by participants in the WG and the WG decisions about
transition documented in RFC 8254 (including the need to deal
with RFC 3188 in an orderly way), still considered RFC
publication appropriate, so here we are.
> Issues:
>
> The document uses 2119 in some inappropriate ways. It's fine
> to use 2119 terms when defining how to construct NBN URNs.
> It's not ok to use them in places like "the national library
> MUST", and "A national library ... SHOULD specify ... a
> policy" and "libraries MUST agree". Please find a way to say
> that if a national library wants things to work, they will or
> should do these things.
I read that text in the draft while I was working on it and
decided to let it go, partially by applying different reasoning.
In part because of the voluntary standards issue (also known as
"where are the protocol police when we need them"), I've always
construed the 2119 language as specifying conditions for a
specification to work as intended. For example, violation of a
"MUST" implies that the spec is very unlikely to work as
intended or, whether that is appropriate, to interoperate.
The URN model vests responsibility for defining and
administering a namespace to the NID registrant / namespace
manager. For NBNs, this document defines the namespace and the
permanent management policies that make it real. If the
registrant believes that these very strong requirements on uses
of the namespace are needed, it seems to me that the use of
normative language of the 2119 character is entirely appropriate.
Put differently, while this document is Informational as far as
IETF processing is concerned, that does not prevent it from
being entirely normative for management of that particular
namespace.
I note that we have taken the position from time to time that we
don't want 2119 language at all in Informational RFCs. However,
if that position is taken wrt this document, the uses of which
you approve would be barred too. If we are going to allow
that language at all, the question then becomes where to draw
the line and I think the author's choices are reasonable.
> While I agree with the values expressed, it seems odd for the
> URN registration to try to put constraints on fees that a
> national library might collect (especially using a 2119
> SHOULD).
Same issue as above.
>...
Just my opinion but one that is, for better or worse, somewhat
informed by working on 8141 and 8254 as well as some preliminary
drafts of this document, the latter two groups of specs with
this author.
best,
john
