Subject: Genart last call review of draft-hakala-urn-nbn-rfc3188bis-00

From: Robert Sparks <[email-masked]>
Date: Tue, 01 May 2018 11:35:28 -0700

Reviewer: Robert Sparks
Review result: Ready with Issues

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 treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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

Summary: Almost ready for publication as an Information RFC but with issues
that need to be addressed before publication.

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.  

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.

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).

Nits/editorial comments: 

The section calling out this draft replaces 
draft-ietf-urnbis-rfc3188bis-nbn-urn should be removed (its enough to add
RFC editor instructions to the draft or to the ballot writeup).

"identifiers identifiers" occurs in the second paragraph on page 4.

The ABNF in "Declaration of syntactic structure of NSS part" needs to be
reformatted to meet the RFC constraints on line length.

Consider "physical" instead of "hand-held" in the first paragraph of 3.1.
A national library may choose to assign an NBN to something too large to pick
up.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 May 2018 13:24:00 -0600

> community know why this is proceeding as an individual draft.  

Because the shepherd (me) was unavailable last week. I'll provide a
writeup in the next few days. However, the short version is that this
document was slated to be completed by the URNbis WG but was decoupled
from URNbis deliverables because of changes we made to the namespace
registration process between RFC 3406 and RFC 8141 (i.e., IETF consensus
is no longer required for registration of formal namespaces) and because
there was still a desire to update the definition of URNs for national
bibliographic numbers to align with modernized syntax from RFC 8141.

> (especially using a 2119 SHOULD).

Agreed.

Peter

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 May 2018 15:46:57 -0400

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
<[email-masked]> wrote:

>...
 
>...
 
> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 May 2018 08:20:59 -0600

On 5/1/18 1:24 PM, Peter Saint-Andre wrote:
> writeup in the next few days. 

Done:

https://datatracker.ietf.org/doc/draft-hakala-urn-nbn-rfc3188bis/shepherdwriteup/

Peter