Subject: draft-02-00 posted

From: Spencer Shepler <[email-masked]>
Date: Sun, 4 Aug 2002 13:00:37 -0500

I have posted the latest working draft at:
http://www.nfsv4.org/rfc3010updates/draft-02-00/draft-ietf-nfsv4-rfc3010bis-02-00.txt

The matching issues list is at:
http://www.nfsv4.org/rfc3010updates/issues.html

As always, the individual issues have pointers to the diffs that were
a result of the updates for the issue.  Therefore, diffing this
version of the draft with previous versions is not necessary.  All
updates should be reflected in the individual issues updates.

This draft incorporates the set of changes supplied by Dave Noveck,
Mike Kupfer and Mike Eisler.  Mike Eisler's changes were the only ones
that were not posted directly to the WG alias.  Issue 91 represents
the changes Eisler proposed for the SETCLIENTID issues and you will
find the complete text of his suggested modifications under that issue.

Here are the issue numbers that were resolved one way or another in
this draft:

02, 16, 41, 44, 45, 50, 51, 53, 57, 60, 61, 67, 68, 69, 72, 74, 77,
80, 83, 85, 86, 87, 91, 94, 95, 96, 97, 98, 103, 104, 105, 106, 108,
109, 110, 112, 113, 117, 118, 119, 131, 132, 138, 140, 145, 153, 154,
160, 167, 169, 173, 174, 175, 176, 181, 184, 195, 197, 199, 206, 208,
209

To find all issues resolved in this updated draft, search for
"RESOLVED-02-00" in the issues page.

Spencer

---

From: [email-masked]
Date: Sun, 04 Aug 2002 14:46:01 -0700

Issue 77 is

  Clarification in Section 8.1.4. It says 

    "A stateid of all bits 1 (one) allows READ operations to bypass
    record locking checks at the server."

  It needs to state whether the server MAY grant the read, versus the
  server MUST grant the read. 

The indicated resolution is

  Resolved by previous re-writes of the special stateid discussion 

So I reviewed the special stateid discussion in Section 8.1.4.  My
reading is that the server MUST grant the read.  Does anyone disagree?

mike

---

From: Benny Halevy <[email-masked]>
Date: Sun, 4 Aug 2002 19:30:58 -0700 (PDT)

I would vote for "the server SHOULD grant the read".
It might be impossible for some servers to provide
bypass around exclusive locks - e.g. NFSv4 gateways
which export a file system which support only strict
locking.

This could also allow finer semantics in the future
like having a "strict_byte_range_locks" attribute per
file/file system or allow-deny modes per lock
-allow=READ, deny=WRITE for share locks (READ_LT);
allow=WRITE|BOTH, deny=BOTH for exclusive locks
(WRITE_LT); allow=WRITE|BOTH, deny=WRITE for weak
write locks. That way the semantics can be determined
in an application specific manner to support both
databases which may require strict exclusive locks and
"regular" files which could have looser semantics.

- Benny

> reading is that the server MUST grant the read. 

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Mike Eisler <[email-masked]>
Date: Mon, 05 Aug 2002 02:54:57 -0700

> http://www.nfsv4.org/rfc3010updates/draft-02-00/draft-ietf-nfsv4-rfc3010bis-02-00.txt
...
> find the complete text of his suggested modifications under that issue.

Heads up for the WG ... setclientid_confirm verifier that was in
RFC3010 has returned in draft-02-00. There's no way to safely update
the callback and callback_ident with SETCLIENTID and SETCLIENTID_CONFIRM
without it.

struct SETCLIENTID4resok {
        clientid4       clientid;
        verifier4       setclientid_confirm;
};

Unlike RFC3010, the SETCLIENTID_CONFIRM arguments has both the
clientid and setclientid_confirm values, instead of just
setclientid_confirm as RFC3010 has, and instead of just clientid
as the most recent i-d at ietf.org has. The reason both are
there is to make it easier for the server to look up the
unconfirmed client record via the clientid. Since all
NFSv4 implementations of SETCLIENTID_CONFIRM are currentlly searching 
by clientid, this change should not be to much of a burden. It is
either do this or one of the following:
	- remove the capability from the specification to update
		callback and callback_ident. I gather this is
		important to have, so not tenable.
	- add a SETCALLBACK routine. This would delay implementation
		progress even more.

The least of the three evils is what is in draft-02-00, IMHO of course.
So:

struct SETCLIENTID_CONFIRM4args {
        clientid4       clientid;
        verifier4       setclientid_confirm;
};

	-mre

---

From: [email-masked]
Date: Mon, 05 Aug 2002 09:44:51 -0700

> I would vote for "the server SHOULD grant the read".

Ah, well then it looks like Issue 77 is not in fact resolved yet.

I don't care whether it's SHOULD or MUST, but it sure seems like the
spec ought to be unambiguous on this point.

mike