Re: [nfsv4] New Version Notification for draft-haynes-nfsv4-versioning-00.txt

[Thomas Haynes <[e-mail]>]

On Oct 11, 2014, at 4:49 PM, Benny Halevy <[e-mail]> wrote:

> Glad to see progress on this and I like the overall direction.
> From first reading I have a couple editorial level comments.
> 
> 1) Did you avoid capitalization of "may" and "must" on purpose?
> 
> For example:
> Minor versions may append attributes
> Minor versions must not modify the structure of an existing operation's arguments or results.
> 

Hi Benny,

I pushed a new version yesterday, but I'll respond to these comments.

The text in Section 4 is for the most part from 3530, 3530bis, 5661, and NFSv4.2.

So, pretty sure the use of "may" and "must" has been reviewed plenty of times. :-)

Anything after that Section is open for review.


> However:
> 
> A client and server that support minor version X SHOULD support minor versions 0 through X-1 as well.
> 




> 2 There seems to be an extra sentence pasted here:
>    Such feature definition documents would contain a number of Addition
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    of features to an existing minor version will take advantage of the
> 

This is not an issue in the current draft.

> 3) The following paragraph need to refer to servers supporting v4.2 and up.
>    o  Existing server implementations that do not recognize the new arm
>       of a switched union will return will return NFS4ERR_INVAL or
>       NFS4ERR_UNION_NOTSUPP, enabling the client to determine that the
>       the new union arm is not supported by the server.
> 

Good point, I've fixed it up.

> 4) Security and IANA considerations
> Rather than stating that there are no considerations I'd basically repeat what was said above:
> 
>    o  Minor version and feature specification will include the
>       "Security Considerations" / "IANA considerations" (respectively) section
>       as required for RFC publication.
> 
> 5)  IANA considerations
> So who's assigning values to added bits / enums for new features and when in the process?

Christoph has called this out. It is the major debate point.

> I envision multiple features being worked on in parallel by individuals so they may clash.
> When accepted as a W/G document we can serialize the enumerations, yet if one a the features
> lingers behind and may eventually be aborted we might end up with a "hole" in the enumeration.

Does having a hole matter?


> Hence I think we (W/G with the help of the RFC Editor) must assign the final values upon becoming an RFC.
> 
> This could be documented as a non-consideration for IANA in this section.
> 
> Does this make sense?
> 
> Benny
> 
> On Mon, Oct 6, 2014 at 2:54 PM, Tom Haynes <[e-mail]> wrote:
> And here it is, I ended up having to resubmit as draft-haynes-nfsv4-versioning. ;-)
> 
> Begin forwarded message:
> 
>> From: [e-mail]
>> Subject: New Version Notification for draft-haynes-nfsv4-versioning-00.txt
>> Date: October 6, 2014 at 2:54:14 PM EDT
>> To: David Noveck <[e-mail]>, "David Noveck" <[e-mail]>, Thomas Haynes <[e-mail]>, "Thomas Haynes" <[e-mail]>
>> 
>> 
>> A new version of I-D, draft-haynes-nfsv4-versioning-00.txt
>> has been successfully submitted by Thomas Haynes and posted to the
>> IETF repository.
>> 
>> Name:		draft-haynes-nfsv4-versioning
>> Revision:	00
>> Title:		Minor versioning Rules for NFSv4
>> Document date:	2014-10-06
>> Group:		Individual Submission
>> Pages:		12
>> URL:            http://www.ietf.org/internet-drafts/draft-haynes-nfsv4-versioning-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-haynes-nfsv4-versioning/
>> Htmlized:       http://tools.ietf.org/html/draft-haynes-nfsv4-versioning-00
>> 
>> 
>> Abstract:
>>   This document specifies the minor versioning rules for NFSv4.  It
>>   also specifies how those minor versioning rules may be modified.
>> 
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
>