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

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