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

From: Tom Haynes <[email-masked]>
Date: Mon, 6 Oct 2014 14:54:55 -0400

And here it is, I ended up having to resubmit as draft-haynes-nfsv4-versioning. ;-)

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-haynes-nfsv4-versioning-00.txt
> Date: October 6, 2014 at 2:54:14 PM EDT
> To: David Noveck <[email-masked]>, "David Noveck" <[email-masked]>, Thomas Haynes <[email-masked]>, "Thomas Haynes" <[email-masked]>
> 
> 
> 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
>

---

From: Benny Halevy <[email-masked]>
Date: Sat, 11 Oct 2014 16:49:00 -0400

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.

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

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?

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.

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 <[email-masked]>
wrote:

> *From: [email-masked]
> *Subject: **New Version Notification for
> draft-haynes-nfsv4-versioning-00.txt*
> *Date: *October 6, 2014 at 2:54:14 PM EDT
> *To: *David Noveck <[email-masked]>, "David Noveck" <
> [email-masked]>, Thomas Haynes <[email-masked]>,
> "Thomas Haynes" <[email-masked]>
>
>
> 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:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: Thomas Haynes <[email-masked]>
Date: Sat, 11 Oct 2014 17:28:02 -0400

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

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

>    Such feature definition documents would contain a number of Addition

This is not an issue in the current draft.

>       the new union arm is not supported by the server.

Good point, I've fixed it up.

> Rather than stating that there are no considerations I'd basically repeat what was said above:
> 
> 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.
> 
> On Mon, Oct 6, 2014 at 2:54 PM, Tom Haynes <[email-masked]> wrote:

---

From: Benny Halevy <[email-masked]>
Date: Sat, 11 Oct 2014 22:20:52 -0400

when in the process?
if one a the features
> 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.

wrote:
>>>> To: David Noveck <[email-masked]>, "David Noveck" <