Re: [Gen-art] Genart last call review of draft-hakala-urn-nbn-rfc3188bis-00

[Robert Sparks <[e-mail]>]

Thanks Peter!

The editorial pass looks really good. It let me spot a nit I missed before:

at

" necessary, a resource in outdated file format is migrated into a more"

you probably want "in an outdated file format"

In that paragraph, you added some MAYs that go against my first original 
point, telling the library what they may do rather than constraining a 
protocol. It looks like you removed some of these as you went through 
the rest of the document, but added others - I'm not easily seeing what 
drove the decision in each spot. That said, per John's note, it's a 
conscious decision of the folks working on the document to use 2119 this 
way, so I'll let it go.

RJS


On 6/4/18 9:47 AM, Peter Saint-Andre wrote:
> Robert, some fixes were posted over the weekend - if you have a chance,
> please check the diff here:
>
> https://tools.ietf.org/rfcdiff?url2=draft-hakala-urn-nbn-rfc3188bis-01.txt
>
> Thanks!
>
> Peter
>
> On 5/1/18 12:35 PM, Robert Sparks wrote:
>> 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.
>>
>>
>>
>