Re: [nfsv4] Barry Leiba's No Objection on draft-ietf-nfsv4-lfs-registry-05: (with COMMENT)

[Tom Haynes <[e-mail]>]

Hi Barry,

Again, thanks for the comments. I’ll hold off on these minor fixes for a bit,
but I have no objection to making them.

Tom

> On Apr 9, 2015, at 11:33 AM, Barry Leiba <[e-mail]> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-nfsv4-lfs-registry-05: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Version -05 addresses my most significant comment, and thanks very much
> for that.
> 
> Some non-blocking, minor comments here:
> 
> Very much a nit, but drafts have this sort of thing all the time, and we
> should probably say something more generally (I think I'll post to the
> IETF discussion list about the general point):
> 
> In the abstract...
> 
>   To allow multiple MAC mechanisms and label formats to co-exist in a
>   network, this document proposes a registry of label format
>   specifications.  This registry would contain label format identifiers
>   and would provide for the association of each such identifier with a
>   corresponding extensive document document outlining the exact syntax
>   and use of the particular label format.
> 
> When the draft was written, it was "proposing" a registry, and should
> that registry be created it "would contain" and "would provide" things. 
> But it's now up for approval for RFC publication, and these
> characterizations are inapt; when it's published, the registry will have
> been created and will be providing all that.  Drafts should be written --
> at least by the time they enter last call -- to have the right tone as
> published RFCs.  Here, I suggest these changes:
> 
> 1. "proposes" -> "creates"
> 2. "would contain" -> "contains"
> 3. "would provide" -> “provides"

Ack, can do.

> 
> -- Section 5 --
> As best I can tell, this question from IANA wasn't answered in the last
> call discussion, and it needs to be:
> 
>> Where should this new registry be located? Should it be placed at an
>> existing URL? If not, should the title of the new webpage be "NFS
>> Security Label Format Selection," or do you expect other registries
>> that would require a different title to be placed there? Also, should
>> it be filed under a new or an existing category at
> http://www.iana.org/protocols? <http://www.iana.org/protocols?>

It took me some time, but I believe there was a reply to Amanda Baber on Feb 23rd:

> Hi Amanda,
> 
> I think it is a new category and I like your suggested title.
> 
> Thanks,
> Tom
> 
>> On Feb 23, 2015, at 12:02 PM, Amanda Baber via RT <[e-mail]> wrote:
>> 
>> Dear Authors,
>> 
>> Thanks for getting back to us. I think we just have one (set of) question(s) left: will this be placed at an existing URL, or a new one? If the latter, does this belong in an existing category at http://www.iana.org/protocols, or in a new category? And finally, if we should create a new category, should it be called "Security Label Format Selection," or would another title be appropriate? 
>> 
>> thanks,
>> Amanda
 


> 
> IANA will sort this out with you in any case, but it would be good for
> the document to say where you would like IANA to put the registry.

Can do

> 
> In Table 1, I think "Available for IANA Assignment" would be better than
> "Reserved for IANA Assignment", but it's a really small point.
> 
> In Section 5.2, I suggest using the full name for the registry (add the
> word "Security”)

Ack


> .
> 

> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4