> On Feb 16, 2015, at 3:17 AM, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote: > > Hi Tom, > > On 11/02/2015 21:14, Tom Haynes wrote: >> Hi Alex, >> >> Thanks for the review. >> >> Comments inline. >> >> Tom >> >>> On Feb 11, 2015, at 3:51 AM, Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote: >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please resolve these comments along with any other Last Call comments you may receive. >>> >>> Document: draft-ietf-nfsv4-lfs-registry-02 >>> Reviewer: Alexey Melnikov >>> Review Date: 2015-02-11 >>> IETF LC End Date: 2015-02-16 >>> IESG Telechat date: N/A. >>> >>> Summary: This draft is nearly ready for publication as a standard track RFC (with nits). >>> >>> Major issues: >>> Minor issues: >>> >>> In Section 4: >>> >>> "LSF" is used for the first time without being expanded. I suggest you introduce the abbreviation in the terminology section. >> I think I prefer to expand it as there are two possible expansions and only one use of it: >> >> >> 4. Security Considerations >> >> This document defines a mechanism to associate LFS identifier with a >> >> -> >> >> 4. Security Considerations >> >> This document defines a mechanism to associate the Label Format Specifier to a > Sounds good to me. Done >>> In Section 5: >>> >>> Label Description: - what is the allowed character set for this field? Is it ASCII? Is it UTF-8 with some restrictions? >> >> Label Description: A human readable ASCII text string that describes > This is a good change. This was the original text. :-) >>>> Status: A short ASCII text string indicating the status of an entry >>>> in the registry. The status field for most entries should have >>>> the value "active". In the case that a label format selection >>>> entry is obsolete, the status field of the obsoleted entry should >>>> be "obsoleted by entry NNN". >>> What is entry NNN? Is it a document reference (e.g. An RFC)? >> It is another entry in the registry. That new entry will provide the mapping to a document reference. > Some registries allow obsoletion of entries which are just not considered to be a good idea anymore. I don't know if your document should allow for that or not. This registry does not consider worthiness as a criteria. >>> Is it possible to obsolete without such entry? >> No, Section 5.3 is clear on that. >> >>> In Section 5.3 - is it possible to update a label description document without requesting a new label? For example if changes are editorial and don't significantly affect label syntax and model. >>> >> >> Two considerations: >> >> 1) Edit of “Description” - I don’t see a problem with allowing this to occur. >> >> 2) Edit of “Reference” - Which is what I think you are asking about here. > I was asking about both. >> If we consider IETF created RFCs, we know that a -bis is a legitimate need for an update as it obsoletes the earlier RFC. >> >> And if we consider non-IETF created documents, I think we need to fall back Designated Expert reviewer to answer whether the new document requires a new label or we can allow an edit. >> >> This is rough, but I’d envision a new Section 5.4: >> >> 5.4. Modifying an Existing Entry in the Registry >> >> A request to modify either the Description or the published >> label format specification will also require the Specification >> Required IANA policy to be applied. The Designated Expert reviewer >> will need to determine if the published label format specification >> either >> >> obsoletes the Label Format Specifier - follow the process in Section 5.2. >> >> updates the label syntax and/or model - approve the change. > I like this. >>> Nits/editorial comments: > Best Regards, > Alexey > And Alexey, thank you very much for that last point, I think it makes the document more complete. I’ve applied the changes, let me know if you want to see an early copy of the next version.