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

On Oct 11, 2014 5:28 PM, "Thomas Haynes" <thomas.haynes@primarydata.com>
wrote:
>
>
> On Oct 11, 2014, at 4:49 PM, Benny Halevy <bhalevy@primarydata.com> 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?

In matters less with enums and more with bitmaps where we want to pack the
space to reduce the xdr on wire footprint. And we said above we want new
ops to be consecutively assigned avoiding holes to improve e.g. coding and
decoding call vector memory footprint.

>
>
>> 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 <thomas.haynes@primarydata.com>
wrote:
>>>
>>> And here it is, I ended up having to resubmit as
draft-haynes-nfsv4-versioning. ;-)
>>>
>>> Begin forwarded message:
>>>
>>>> From: internet-drafts@ietf.org
>>>> Subject: New Version Notification for
draft-haynes-nfsv4-versioning-00.txt
>>>> Date: October 6, 2014 at 2:54:14 PM EDT
>>>> To: David Noveck <davenoveck@gmail.com>, "David Noveck" <
davenoveck@gmail.com>, Thomas Haynes <thomas.haynes@primarydata.com>,
"Thomas Haynes" <thomas.haynes@primarydata.com>
>>>>
>>>>
>>>> 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
>>> nfsv4@ietf.org
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>>
>