Subject: [nfsv4] word smithing changes for Chapter 18 - LOCK through OPEN

From: "Mike Eisler" <[email-masked]>
Date: Thu, 10 Apr 2008 07:56:58 -0700 (PDT)

http://eisler.com/nfsv4-wg/2008-04-10-ch-18-lock-open.html

Also includes fix to the retention typo Robert Gordon found.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 10 Apr 2008 13:09:06 -0400

> Also includes fix to the retention typo Robert Gordon found.

	"32-bit servers are servers that support locking for byte
	offsets that fit within 32 bits (i.e. less than or equal to
	NFS4_UINT32_MAX). If the client specifies a range that overlaps
	one or more bytes beyond offset NFS4_UINT32_MAX, but does not
	end at offset NFS4_UINT64_MAX such a 32-bit server MUST return
	the error NFS4ERR_BAD_RANGE."

That still needs a comma before the final "such".

	"The test for conflicting locks should exclude locks for the
	current lock-owner, but the NFSv4.1 specification is flexible in
	this regard.  Note that if such locks are not examined, the
	possible existence of overlapping ranges might not affect the
	results of LOCKT, but might affect the results of LOCK. If the
	server does examine locks that match the lock-owner for the
	purpose of range checking, NFS4ERR_LOCK_RANGE may be returned in
	the rely to LOCKT. In the event the server returns NFS4_OK in
	the reply to LOCKT, it is possible when the client sends LOCK
	request, the server will reject	it with NFS4ERR_LOCK_RANGE due
	to the flexibility the NFSv4.1 specification allows the server."

There should be an article in "the client sends LOCK request".

But my real complaint is that this paragraph is confusing as heck.
That's the fault of the situation, not the particular text!  So I'm not
quite sure what to do about it.

Hm.  The final sentence is odd: we begin by recommending that servers
not check locks for the current lock-owner, but say that the
specification is "flexible" in that it does not require this.  In other
words, we recommend that the server *not* return LOCK_RANGE on LOCKT,
but grant it the "flexibility" to do so.  The situation described in the
final two sentences, therefore, is a result of our recommendation, not
(as the final sentence might be taken to suggest) of the just-mentioned
"flexibility".  (Probably this second "flexibility" is meant to refer to
the different flexibility to allow non-posix locking behavior.)

A reference back to the lock text might help.  And should "should" be
"SHOULD"?  That might give us:

	"As noted in <xref target="OP_LOCK_IMPLEMENTATION">, some
	servers may return NFS4ERR_LOCK_RANGE to certain (otherwise
	non-conflicting) lock requests that overlap ranges already
	granted to the current lock-owner.

	"The LOCKT operation's test for conflicting locks SHOULD exclude
	locks for the current lock-owner, thus should return NFS4_OK in
	such cases.  Note that this means that a server may return
	NFS4_OK to a LOCKT request even though a LOCK request for the
	same range and lock owner would fail with NFS4ERR_LOCK_RANGE."

--b.