Subject: [nfsv4] FW: New Version Notification for draft-dnoveck-storage-control-01

From: "Erasani, Pranoop" <[email-masked]>
Date: Mon, 14 Mar 2011 16:07:34 -0700

Just FYI. A new version of the storage control extensions draft has been posted.

Thanks to the earlier omission of nfsv4 in the draft name, it does not show up in the NFSv4 documents list. We will fix that for the next version. It turns out that, to change the name of the draft, we need to submit a 00 version. We will take care of that after Prague IETF.

This document merely addresses some typos and some contact information. Thanks to Sorin for review of this document.

- Pranoop

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 4:01 PM
To: Erasani, Pranoop
Cc: [email-masked]; Bairavasundaram, Lakshmi; [email-masked]; [email-masked]
Subject: New Version Notification for draft-dnoveck-storage-control-01 

A new version of I-D, draft-dnoveck-storage-control-01.txt has been successfully submitted by Pranoop Erasani and posted to the IETF repository.

Filename:	 draft-dnoveck-storage-control
Revision:	 01
Title:		 Storage Control Extensions for NFS Version 4
Creation_date:	 2011-03-14
WG ID:		 Independent Submission
Number_of_pages: 33

Abstract:
Developments in storage systems have made it important for
applications to have control over the characteristics of the storage
that will be used for their particular files.  The development of
pNFS has added to the usefulness of such control mechanisms as it has
created the opportunity for the hierarchical organization of file
names to be separated from the control of storage characteristics for
individual files, including the assignment to storage locations to
reflect the performance or other needs of those specific files.  This
document proposes extensions to NFS version 4 to allow storage
requirements to be communicated to the NFS version 4 server.

The IETF Secretariat.

---

From: "Sorin Faibish" <[email-masked]>
Date: Mon, 14 Mar 2011 19:59:19 -0400

On Mon, 14 Mar 2011 19:07:34 -0400, Erasani, Pranoop  
<[email-masked]> wrote:

> Thanks to the earlier omission of nfsv4 in the draft name, it does not  
> show up in the NFSv4 documents list. We will fix that for the next  
> version. It turns out that, to change the name of the draft, we need to  
> submit a 00 version. We will take care of that after Prague IETF.
But as we made the deadline for 01, you can in principle submit a new 00
with new name and retire this 01 after Prague. Just to get the  
notification.
Not sure it worth but I hope there is no problem with the inclusion in 4.2
as it is still a private draft not a WG draft. Just formalistics. Hope
no comnplains from ADs. Thanks for updating the draft.

>
> This document merely addresses some typos and some contact information.  
> Thanks to Sorin for review of this document.
You very welcome.

/Sorin

> A new version of I-D, draft-dnoveck-storage-control-01.txt has been  
> successfully submitted by Pranoop Erasani and posted to the IETF  
> repository.
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Best Regards
Sorin Faibish
Corporate Distinguished Engineer
Unified Storage Division

        EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Mon, 14 Mar 2011 19:13:57 -0700

Hi Mike,

Mike had the same feedback as well.

I will go ahead and submit another one with correct name. To preserve the version history (and dates on them) correctly, I will submit draft-dnoveck-nfsv4-storage-control-00 (same as draft-dnoveck-storage-control-00 but with nfsv4 in it) and draft-dnoveck-nfsv4-storage-control-01 (same as draft-dnoveck-storage-control-01 with nfsv4 in it).

After Prague IETF, as you say, we can just retire the old set and make updates to the new ones.

- Pranoop

> From: Sorin Faibish [mailto:[email-masked]]
> Sent: Monday, March 14, 2011 4:59 PM
> To: Erasani, Pranoop; [email-masked]
> Subject: Re: [nfsv4] FW: New Version Notification for draft-dnoveck-
> storage-control-01
> 
> > Just FYI. A new version of the storage control extensions draft has
> been
> > posted.
> >

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Mon, 14 Mar 2011 19:22:09 -0700

> Hi Mike,

Sorry, I meant to say "Hi Sorin". Apologies.

> I will go ahead and submit another one with correct name. To preserve
> the version history (and dates on them) correctly, I will submit draft-
> dnoveck-nfsv4-storage-control-00 (same as draft-dnoveck-storage-
> control-00 but with nfsv4 in it) and draft-dnoveck-nfsv4-storage-
> control-01 (same as draft-dnoveck-storage-control-01 with nfsv4 in it).
> 
> > > version. It turns out that, to change the name of the draft, we
> need
> > to
> > Not sure it worth but I hope there is no problem with the inclusion
> in
> > 4.2
> > > Cc: [email-masked]; Bairavasundaram, Lakshmi;
> [email-masked];
> > > [email-masked]
> > > Subject: New Version Notification for draft-dnoveck-storage-
> control-
> > 01
> > >
> > >

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 18 Mar 2011 23:23:37 -0500

Nits:
=====

Looking at: http://www.ietf.org/id/draft-dnoveck-storage-control-01.txt

Section 5.2:

  The following are the three property specifications that fit the description.

I count 8 of them.

-----

   For most purposes, a fattr4_storage_ctl which appears in OPEN,
   CREATE, and SETATTR requests are handled the same and a
   fattr4_storage_ctl which appears in the responses for OPEN, CREATE,
   and SETATTR are handled similarly, while the VERIFY and NVERIFY
   requests form a third similarity group.

It should be "is handled" - there is only 1 fattr_storage_ctl under discussion.

-----

   If an enforceable property specified as with the manadatory
   enforcement level cannot be satisfied then the operation fails with
   the error NFS4ERR_SCTL_FAIL.  The response contains, for the case
   NFS4ERR_SCTL_FAIL, a fattr4_storage_ctl value which consists all such
   enforceable properties which could not be satisfied.

Perhaps: "cannot be satisfied, then the"

And: "which consists all" -> "which consists of all"

---

   If there is a situation which is not as serious as the failure above,
   but still of note, then information relevant to that situation is
   stored as a pending storage control note, where it can be fetched (in
   the same COMPOUND) by the FETCH_SCNOTE operation.

We are halfway through the document and the fact that there is a new
operation is a surprise to the reader.  It should be mentioned/built up
in the Introduction.

---

   o  The namespace version number.  The version number is in the form a
      series of small (< 256) integers.  The length of the series will
      probably be restricted to something between four and six.  The
      version numbers will not be checked for order but only that they
      are unique for a given extension.

Between four and six what?

Is the intent 12.2.3.1.0.5 as a version number?

----

      Successive version may add properties but may not delete them,
      ^^^ "Successive versions"
      clarifications to the semantics of existing properties may be made
      but substantive changes in their semantics should not be made.

      Existing properties may not be defines as invalid or mandatory-to-
                                                        ^^^ "be defined"
      not-implement but they may be defined as incompatible with some
      set of new properties.

-----

   extension adequately.  It should not be rejected simply because the
   expert would do things differently or believe the specified
   properties are useful.

So, the expert would only accept extensions with properties they deem to
not be useful?

-----

   Storage properties may be extended via a standards-track document in
   a number of ways.  Such an extension may be part of a new minor
   version, but may also be done independent of in a standards-track
   document other than for a new NFSv4 minor version.  When the
   extension occurs in a new minor version the document should make
   clear whether the additional properties are recommended (as is
   normally the case) or mandatory.

   The following forms of extension are all valid options:

      Adding additional properties to existing standardized property set
      such as PROP_BASE.

      Creating a new property set its own property set id.

      Converting a previous experimental property set to standards-track
      status based on the publication of the RFC [Need to clarify any
      possible transfer of ownership issues.]

When an extension does not occur in a new NFSv4 minor version,
what does the document have to make clear?

I'll save this for the Lice discussion below....

-----

8.3.  The storage_ext attribute

   The storage_ext attribute is a per-fs attribute which contains
   information on the storage_ctl extensions suported by the server when
   used on the associated file system.  Servers will often report the
   same value of the storage_ext attribute for all file systems, but
   client should not assume that this is the case.
^^clients

      struct section_se {
         spacenum_sc   SpaceSction;    /* Section number. */
         bitmap_sc     WhichProperties;/* Supported properties. */
      };

      typedef section_se fattr4_storage_ext&lt&#65533;>;

   The storage_ext attribute consists of section_se arrays, each of
   which specify the supported properties for a specific space_id.  The
   section_se arrays should be reported in ascending numeric order of
   spacenum_sc values.

How/where is fattr4_storage_ext used? Again, something new is
introduced out of the blue, but this time it is not tied into anything.
I.e., no clue as to which operation sends/receives it.

-----

   These constraints apply to properties introduced by extensions to the
   storage_ctl attirbute unless explicitly overridden in the document
   defining the extension.  Such a document may add other contextual
   constraints that apply to the properties defined by that extension.

attribute

------

======

Lice
======

The biggest issue with this document is that it allows for systems which claim
to be NFSv4.X compliant to not interoperate with other systems which claim
to be NFSv4.X compliant. Further, it allows for systems from the same vendor
to not be compatible with each other.

Given a train which departs every 5 years, it is understandable for a desire
to get small changes into the base protocol and not be frozen out by large
features.

But we've adopted a model where the train will be leaving every year. We
should not be considering laying the groundwork to introduce a compatibility
matrix nightmare. We have a standard for a reason and it is to keep our
customers happy.

---

From: sfaibish <[email-masked]>
Date: Mon, 21 Mar 2011 17:59:20 -0400

> So, the expert would only accept extensions with properties they deem to
I think what Dave was intending to say was that "experts" that review the
extension would not deffer to accept them because he has a different
implementation idea, but only if it has a real issue with the extension
as breaking the protocol definitions.

> what does the document have to make clear?
I want to clarify that this idea of extenssion w/o a change in the
draft is still new and need more elaborated discussions. This was the
first proposal. I would wait for Prague and or Quebec to better define
this extensions idea. Same applies to the Licensing and the IP release
if this is a proprietary proposal for extension specific to a vendor.

> matrix nightmare. We have a standard for a reason and it is to keep our
This actually opens an interesting discussion about the entire extensions
ide; why not making the changes using I-Ds targeted at specific 4.x
versions. I agree that the extensions business can be messy if you
will need "expert" aproval to who the "extperts" will be.

/Sorin

-- 
Best Regards

Sorin Faibish

Phone: 508-249-5745
Cellphone: 617-510-0422
Email : [email-masked]