Subject: [nfsv4] work items to complete rfc3530bis (what are they?)

From: Spencer Shepler <[email-masked]>
Date: Thu, 3 Sep 2009 08:48:33 -0500

Hello.

We have a charter item that reads:

(1) NFS version 4.0 maintenance

Under this charter item, the WG correct errors and ambiguities in the
protocol currently specified in RFC 3530 and advances it along the
standards track. Extensions of any other kind are out of scope under
this charter item.

Tom Haynes has been good enough to volunteer as editor and
has published a -00 that should match the current rfc3530

http://tools.ietf.org/id/draft-ietf-nfsv4-rfc3530bis-00.txt

I would like to identify the work items for rfc3530bis so we
know when the work is complete and the update can be
published as an RFC.

Please send your items/suggestions to Tom and myself.  We will
reflect those back to the WG alias to ensure we have a complete
list.

Please have your items in by Sept 8th.

Thanks,
Spencer

---

From: Tigran Mkrtchyan <[email-masked]>
Date: Thu, 03 Sep 2009 18:41:38 +0200

Hi Spencer,

the one thing which I would like to mentions is
that ACL chapter is inconsistent (ops to access bit matching).
It was corrected later on in 4.1 but actually can be moved
into rfc3530bis.

Regards,
	Tigran.

On 09/03/2009 03:48 PM, Spencer Shepler wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 8 Sep 2009 02:57:25 -0500

Due date is today.  We have had some input -- please send along more.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 8 Sep 2009 11:28:17 -0400

One area that I believe needs clarification is the treatment of what are
often called "courtesy locks".  There have been a number of discussions
that have suggested to me that exact intentions of the spec are not
clear here.

Most recently, Trond and I had a discussion, in which these had a role.
I promised to put together a series of questions about what the spec
intends relative to these.  I believe we will get a number of different
sets of answers, while, if the spec were clear, we should only get one.

Since I haven't put together the questions, I can't prove that
clarification is needed, but I believe it is.  Let me try to put
together the questions in the next week or so, and see what we get. 

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, September 08, 2009 3:57 AM
To: [email-masked]
Cc: Tom Haynes
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)

Spencer

On Sep 3, 2009, at 8:48 AM, Spencer Shepler wrote:

> Tom Haynes has been good enough to volunteer as editor and has 
> published a -00 that should match the current rfc3530
>
> I would like to identify the work items for rfc3530bis so we know when

> the work is complete and the update can be published as an RFC.
>
> Please send your items/suggestions to Tom and myself.  We will reflect

> those back to the WG alias to ensure we have a complete list.
>

---

From: Tom Haynes <[email-masked]>
Date: Fri, 18 Sep 2009 11:34:52 -0500

> know when the work is complete and the update can be

To summarize:

1) Fix ACL chapter to reflect correct ops to access bit matching. Look 
at fixes in 4.1.

2) Explain what associated means in this context:

> In sec. 14.2.2 DESCRIPTION
>
>     The share reservations and other state information released
>     at the server as a result of this CLOSE is only associated
>         with the supplied stateid.

3) There are places where "lock_owner" is used in sec. 8.n.n and I
found it confusing. Maybe a statement near the beginning of that
section, noting that "lock_owner" is used to refer to both open_owner4
and lock_owner4s? Same goes for "lock" referring to an open share as
well as a byte range lock.

4) What are "courtesy locks"? Dave Noveck to clarify what he wants here
to the WG.

5) How do we handle Referrals in v4.0.
------

The first 4 are somewhat straight forward and the last would be a 
significant upgrade.

Does anyone recall anything else that was deemed missing?

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 18 Sep 2009 13:17:36 -0400

I also had a list of items that came up when we were doing v4.1. I had a
keyword that indicated if somethng also had rfc3530 implications.

4) I think "courtesy locks" is Trond's term.  He is referring to the
following text in section 8.6.3:

   As a courtesy to the client or as an optimization, the server may
   continue to hold locks on behalf of a client for which recent
   communication has extended beyond the lease period.  If the server
   receives a lock or I/O request that conflicts with one of these
   courtesy locks, the server must free the courtesy lock and grant the
   new request.

I've found that people are very unclear about a number of points
which regard to how such locks should work if you implement them.
I promised to try to prove that by coming up with a qustionaire
and seeing that everybody disagreed about the questions.  I have 
started on that but put it aside for a bit.

-----Original Message-----
From: Tom Haynes [mailto:[email-masked]] 
Sent: Friday, September 18, 2009 12:35 PM
To: Spencer Shepler
Cc: [email-masked]
Subject: Re: [nfsv4] work items to complete rfc3530bis (what are they?)

To summarize:

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 18 Sep 2009 13:51:47 -0400

> Does anyone recall anything else that was deemed missing?

There is the issue of NFS4ERR_DELAY vs NFS4ERR_RESOURCE that keeps
popping up now and again.
IIRC, the AIX server wanted to delay clients in either SETCLIENTID or
SETCLIENTID_CONFIRM while they cleaned out stale locking information,
and since NFS4ERR_DELAY wasn't available, they tried NFS4ERR_RESOURCE.
So.... Clarify when the server should be using NFS4ERR_RESOURCE vs
NFS4ERR_DELAY, and what the client is supposed to do in either case.

We need SECINFO workarounds on LOOKUPP and PUTROOTFH.

Clarify the sections on sequence ids. Currently, the text is
inconsistent about whether or not you need to initialise them to zero.
It would also be nice to have a section that clarifies the life cycle of
a sequence id. IOW: when do the client and server have to cache the
sequence id info, and when are they allowed to forget about it.

We should clarify the passage on NFS4ERR_LOCKS_HELD. Since lock owners
and open owners are different things, we need to clarify which locks may
trigger an NFS4ERR_LOCKS_HELD error on a CLOSE for a given open_stateid.
In the same vein, which locks does section 9.8 allow the server to free
when the client does a CLOSE? This all harks back to the mailing list
discussions about lock_stateids being
<per-file,per-open_owner,per-lock_owner> vs. just being
<per-file,per-lock_owner>

Recommendations/workarounds for dealing with the OPEN and CB_RECALL
race.

Clarify the use of the delegation vs lock vs open stateid in SETATTR.

Clarify the various scenarios that should result in a delegation recall
(mainly SETATTR by self).

Perhaps clarify how clients should be managing delegations? There appear
to be server implementations that expect clients to limit the number of
delegations they are holding.

There's the unimplemented-by-everybody mandatory UTF-8 formatting of
filenames...

SPKM3/LIPKEY is not implemented by anyone. Remove its
mandatory-to-implement status?

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 18 Sep 2009 14:01:57 -0400

> started on that but put it aside for a bit.

Another minor locking item: the blocking-lock cancelling recommendation
in 9.6 should work for 4.0 clients and servers too:

	If a server receives a blocking lock request, denies it, and
	then later receives a nonblocking request for the same lock,
	which is also denied, then it should remove the lock in question
	from its list of pending blocking locks.  Clients should use
	such a nonblocking request to indicate to the server that this
	is the last time they intend to poll for the lock, as may happen
	when the process requesting the lock is interrupted.  This is a
	courtesy to the server, to prevent it from unnecessarily waiting
	a lease period before granting other lock requests.  However,
	clients are not required to perform this courtesy, and servers
	must not depend on them doing so.  Also, clients must be
	prepared for the possibility that this final locking request
	will be accepted.

--b.