Subject: Gen-ART LC review of draft-ietf-nfsv4-lfs-registry-02

From: Alexey Melnikov <[email-masked]>
Date: Wed, 11 Feb 2015 11:51:52 +0000

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.

In Section 5:

Label Description: - what is the allowed character set for this field? 
Is it ASCII? Is it UTF-8 with some restrictions?

 >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)? Is it 
possible to obsolete without such entry?

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.

Nits/editorial comments:

---

From: Tom Haynes <[email-masked]>
Date: Wed, 11 Feb 2015 13:14:05 -0800

Hi Alex,

Thanks for the review.

Comments inline.

Tom

> On Feb 11, 2015, at 3:51 AM, Alexey Melnikov <[email-masked]> 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.
> 
> 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

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

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

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

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2015 11:17:50 +0000

Hi Tom,

>     This document defines a mechanism to associate the Label Format Specifier to a
Sounds good to me.
>     Label Description:  A human readable ASCII text string that describes
This is a good change.
> 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.
> 2) Edit of “Reference” - Which is what I think you are asking about here.
I was asking about both.
>    updates the label syntax and/or model - approve the change.
I like this.
>> Nits/editorial comments:
Best Regards,
Alexey

---

From: Thomas Haynes <[email-masked]>
Date: Mon, 16 Feb 2015 09:55:39 -0800

> On Feb 16, 2015, at 3:17 AM, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Tom,
> 

Done

>>    Label Description:  A human readable ASCII text string that describes

This was the original text. :-)

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

>>   updates the label syntax and/or model - approve the change.

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Feb 2015 18:47:10 +0000

Hi Tom,

>>>> On Feb 11, 2015, at 3:51 AM, Alexey Melnikov <[email-masked]> wrote:
  [snip]
> This was the original text. :-)
Oops :-). I think you need to add a reference to RFC 20 for US-ASCII. It 
would also be better to say that control characters should not be allowed.
> This registry does not consider worthiness as a criteria.
Ok.
> I’ve applied the changes, let me know if you want to see an early copy of the next version.
I am satisfied with your responses where new text was discussed and 
agreed upon.

Thank you for replying so quickly and doing the updates!

Best Regards,
Alexey