Subject: [nfsv4] Scribe for 5/10

From: "Reyes-Ortiz, Talia" <[email-masked]>
Date: Fri, 11 May 2012 16:35:30 +0000

Talia, Tom, Jared, Dave, Trond, Bryan, Peter, Sanjen, Pranoop, Dros, Andy, Bruce, Spencer

Note well agreement

All the AI completed minus the minor version

START Chapter 8 (2417)

No changed on summary introduction

2667 - Trond: If the attribute/change type is not defined then the server Should make an effort to implement the time-meta recommended attribute.

2609 - Parnoop: move to 2605

2615 - Dave: When can this attribute can change to a filesystem attribute? Open item

3702 - Trond: can we go back to the working group and get the use case for this?

3720 - Dave: Add "will not reply to any destroy session created by this client ID"

2114-2122 - Trond: "Must" must be capitalized

2151 - Trond: Add in somewhere (reference)/List of client and server responsibilities

2175 - Tom: The server should always make that determination

2176 - AI for Tom: Figure out what the sentence really mean, start discussion on mailing list

2193 - Jared: Removal of the last sentence that says "For example..." (doesn't belong in this paragraph)

END Section 7.3.5

Cheers!
Talia Reyes-Ortiz
Program Manager
CTO Office
NetApp Inc.
408.822.1566 Direct Phone
[email-masked]
[Description: http://media.netapp.com/images/esigs-innovative-company-480x75.png]<http://www.forbes.com/special-features/innovative-companies.html>

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 11 May 2012 13:17:29 -0700

> Talia, Tom, Jared, Dave, Trond, Bryan, Peter, Sanjen, Pranoop, Dros, Andy,

[...]

> 3702 - Trond: can we go back to the working group and get the use case for

Tom Haynes tells me this refers to:

const EXCHGID4_FLAG_SUPP_FENCE_OPS      = 0x00000004;

This was discussed in Beijing (
http://www.ietf.org/proceedings/79/slides/nfsv4-10.pdf slide 5) but to
re-capitulate: Client has an application that automatically starts when
the client's operating system starts or restarts. If the previous
incarnation of the operating system had a modification in flight when the
incarnation experienced abnormal termination, then it is possible that the
modification is in flight when the current incarnation starts. New
modifications race with old modifications. Thus without this flag, we have
yet another instance of the dangling write problem.

Another use case is cluster of NFS client hosts with failover support.
Host A has some requests in flight, crashes, Host B takes over. Again,
dangling modifications are not a good idea. Note that in a clustered set
up, Host A might have informed Host B of the session ID it has on the
NFSv4.2 server, and so in the event of failover, Host B doesn't even need
to use EXCHANGE_ID to clear out operations from Host A that are still in
progress: it suffices to send a DESTROY_SESSION operation.

Tom Haynes told me that Spencer asked whether the client wants to know
which operations need to be completed and which were aborted. The above
two use cases don't need it. There might be use cases that do. Along
related lines, I would like NFSv4.3 to include a mechanism to abort
operations on specific slots. We could have a single mechanism that
indicates whether to abort or complete an operation on slot by slot basis.
We might have special read-only attribute called session-state, which
retrieves the slot table, with an indication of what is complete (and if
cached, what it is) and what is in progress, and what slots have never
been used. But all this is scope creep that should not be part of NFSv4.2.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 11 May 2012 20:46:22 +0000

On 5/11/12 3:17 PM, "Mike Eisler" <[email-masked]> wrote:

> Along

Good point Mike and with Spencer's announcement for IETF '84 today, this
is a great reminder to start cranking up material for NFSv4.3.

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 14 May 2012 14:12:27 -0700

> 2667 – Trond: If the attribute/change type is not defined then the server
>               Should make an effort to implement the time-meta recommended
>               attribute.
>  

Done

> 2609 – Pranoop: move to 2605

Done

> 
> 2615 – Dave: When can this attribute can change to a filesystem attribute?
>               Open item

Added a bit of text and pushed the reader to 5661.

   has changed.  While Section 5.4 of [2] discusses per file system
   attributes, it is expected that the value of change_attr_type not
   depend on the value of "homogeneous" and only changes in the event of
   a migration.

> 
> 3702 – Trond: can we go back to the working group and get the use case for this?

Mike did this in email.

> 
> 3720 - Dave: Add “will not reply to any destroy session created by this client ID”

Strengthened the text here:

   o  The server will not reply to any DESTROY_SESSION invoked with the
      client ID until all operations in progress are completed or
      aborted.

> 
> 2114-2122 - Trond: “Must” must be capitalized

Done

> 
> 2151 – Trond: Add in somewhere (reference)/List of client and server responsibilities

Pointed the reader to 5661:

7.3.1.  Delegations

   In the event that a security attribute is changed on the server while
   a client holds a delegation on the file, both the server and the
   client MUST follow the NFSv4.1 protocol (see Chapter 10 of [2]) with
   respect to attribute changes.  It SHOULD flush all changes back to
   the server and relinquish the delegation.

> 
> 2175 – Tom: The server should always make that determination
> 

Made the following change to the sentence:

   creation.  When a client is MAC-Functional it must always provide the
   initial security attribute upon file creation.  In the event that the
   server is MAC-Functional as well, it should determine by policy
   whether it will accept the attribute from the client or instead make
   the determination itself.  If the client is not MAC-Functional, then
   the MAC-Functional server must decide on a default label.  A more in
   depth explanation can be found in Section 7.6.

I.e., explain what a client's responsibility, what a server does if the
client is not allowed by the server to set the attribute, and what the
server has to do if the client does not send an attribute.

> 
> 2193 – Jared: Removal of the last sentence that says “For example...”
>               (doesn’t belong in this paragraph)

Done

-- 
[email-masked], ex-cfb

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 15 May 2012 10:10:00 -0400

On Fri, May 11, 2012 at 01:17:29PM -0700, Mike Eisler wrote:
> re-capitulate:

Could we get some version of this explanation into the "motivation"
section of the draft?

--b.

> Client has an application that automatically starts when
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 16 May 2012 18:13:49 +0000

On 5/15/12 7:10 AM, "J. Bruce Fields" <[email-masked]> wrote:

>> > Talia, Tom, Jared, Dave, Trond, Bryan, Peter, Sanjen, Pranoop, Dros,
>>Andy,
>> > Bruce, Spencer
>> 
>> [...]
>> 
>> >
>> > 3702 - Trond: can we go back to the working group and get the use
>>case for
>> > this?
>> >
>> 

Actually, I think the proper place for this would have been the individual
draft that got this piece accepted into NFSv4.2. We should have been
asking these use case questions a year ago and not now.

This document is not about use cases, motivation for doing the changes,
etc. It is focused on what is needed to implement. As such, I've been
removing such text as I move the text from the individual draft into this
document.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 16 May 2012 15:29:44 -0400

> removing such text as I move the text from the individual draft into this

As an implementer I'd find this explanation useful, and I think I'll
have a hard time finding it a year from now if it's not findable from
this document.

A lot of argument may go into the question of whether we include a given
feature or not, and I agree that not all of that belongs in the final
spec, but at a minimum we can certainly include an explanation of the
problem that a given feature is meant to solve.  I can't see that we've
made it a rule to remove that kind of thing from rfc 3530 or 5661.

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 16 May 2012 20:53:00 +0000

>have a hard time finding it a year from now if it's not findable from

Okay a good argument on why to do it.

>made it a rule to remove that kind of thing from rfc 3530 or 5661.

Those documents didn't have anyone trying to stay under 100 pages. :->

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 16 May 2012 17:01:57 -0400

> Those documents didn't have anyone trying to stay under 100 pages. :->

Well, a paragraph will do in this case.

But if we're that close to going over, and if the schedule's slipping (I
thought we were trying for annual, and it's been more than a year now?)
then maybe we've taken on too many features?

I understood the agreement to be that we'd sacrifice features to keep
the schedule and scope under control.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 16 May 2012 21:28:50 +0000

Size of document is a target not a hard limit (I know there was a smiley at the end of the statement).

With respect to timeline... A volunteer effort moves as quickly as its volunteers.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Wednesday, May 16, 2012 2:02 PM
To: Haynes, Tom
Cc: [email-masked]
Subject: Re: [nfsv4] Scribe for 5/10

On Wed, May 16, 2012 at 08:53:00PM +0000, Haynes, Tom wrote:
> >A lot of argument may go into the question of whether we include a 
> >given feature or not, and I agree that not all of that belongs in the 
> >final spec, but at a minimum we can certainly include an explanation 
> >of the problem that a given feature is meant to solve.  I can't see 
> >that we've made it a rule to remove that kind of thing from rfc 3530 or 5661.
> >
> >--b.
> 

But if we're that close to going over, and if the schedule's slipping (I thought we were trying for annual, and it's been more than a year now?) then maybe we've taken on too many features?

I understood the agreement to be that we'd sacrifice features to keep the schedule and scope under control.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 May 2012 10:47:40 -0400

> With respect to timeline... A volunteer effort moves as quickly as its volunteers.

Yipes--I certainly didn't mean to suggest anyone's slacking.

Given the choice of how to use our limited resources, we previously
decided to aim for a fixed schedule rather than a fixed set of features:

	" The eventual conclusion was to focus NFSv4.2 as a time limited
	deliverable.  The premise is that solid proposals exist today
	for NFSv4.2.  Setting a deadline for NFSv4.2 delivery will act
	as a forcing function to complete existing proposals and if
	other less mature proposals reach a similar level of maturity,
	they can be included in NFSv4.2 as well.

	"The timeline chosen during the meeting was 1 year; for example,
	NFSv4.2 ready for working group last call by March 2012."

So maybe we bit off too much this time, and should consider moving some
to 4.3.

--b.

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 17 May 2012 17:03:38 +0000

>So maybe we bit off too much this time, and should consider moving some

I think a year was too aggressive. I think we, or at least I, learned some
lessons on doing it this way. I'm very happy with the state of the effort
right now.

I think the remaining effort is the same for whether we keep everything or
jettison some things.

Where I think we would get in trouble is if we tried to add anything to
4.2 at this time.

>> But if we're that close to going over, and if the schedule's slipping
>>(I thought we were trying for annual, and it's been more than a year
>>now?) then maybe we've taken on too many features?
>>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 17 May 2012 14:40:33 -0400

> lessons on doing it this way. I'm very happy with the state of the effort

Would you like to hazard a guess at a last call time for NFSv4.2?  (And
what about 4.3?)

> Where I think we would get in trouble is if we tried to add anything to

Also, if review finds a section that needs substantial changes.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 17 May 2012 18:46:04 +0000

Tom published the document review schedule.  When that review is complete, we will start last call.

4.3 is when the WG generates interest/content and we take that forward for a recharter of the WG.

Spencer

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 11:41 AM
To: Haynes, Tom
Cc: Spencer Shepler; [email-masked]
Subject: Re: [nfsv4] Scribe for 5/10

On Thu, May 17, 2012 at 05:03:38PM +0000, Haynes, Tom wrote:
> >So maybe we bit off too much this time, and should consider moving 
> >some to 4.3.
> 
> I think a year was too aggressive. I think we, or at least I, learned 
> some lessons on doing it this way. I'm very happy with the state of 
> the effort right now.

Would you like to hazard a guess at a last call time for NFSv4.2?  (And what about 4.3?)

> I think the remaining effort is the same for whether we keep 
> everything or jettison some things.
> 

--b.