Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4-lfs-registry-04: (with DISCUSS and COMMENT)

[Tom Haynes <[e-mail]>]

> On Apr 7, 2015, at 8:43 AM, Barry Leiba <[e-mail]> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-nfsv4-lfs-registry-04: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Setting up this registry is a fine thing, and I just have two points I'd
> like to sort out before we approve this:
> 
> -- Section 5.2 --
> 
> 1. Is it your intent that the Designated Expert still has to do expert
> review when the specification is a Standards Track RFC?


I think that would be the easiest review of all.

But yes, the expert reviewer would verify that it was a Standards Track RFC
and approve it.


> 
> 2. You have no instructions to guide the Designated Expert; some
> instructions are needed.

Agreed.


>  Is the DE expected to just give a basic sanity
> check to the specification?  Is more thorough review of the specification
> expected?  Will the DE be making any judgments about whether the
> specified label format is useful, or is or isn't a "good idea", or is the
> DE expected to approve any request with a suitable specification?  Both
> DEs and applicants need to know what's expected.
> 


I think the judgement is not whether the specified label format
useful or a “good idea”, but rather does it provide for a sound
MAC implementation?




> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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"
> 
> -- 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?
> 
> 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.
> 
> 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").
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4