Subject: [nfsv4] Sessions review - part 2

From: Trond Myklebust <[email-masked]>
Date: Tue, 08 May 2007 15:17:20 -0400

Here are the notes taken. Apologies for the delay which was due to a
series of circumstances beyond my control...

Cheers
  Trond

Tom Doeppner         (Brown)
Fred Isaman          (CITI)
Robert Gordon        (Sun)
Spencer Shepler      (Sun)    Moderator
Mike Eisler          (NetApp) Author
Trond Myklebust      (NetApp) Scribe
Peter Shah           (NetApp)
Tom Talpey           (NetApp) Reader
Benny Halevy	     (Panasas)
Rick Macklem	     (Guelph)

-----------------------------------

Talpey 2712:	Need to clarify that the 'return it on a subsequent operation'
		refers to the same compound
Gordon:		Return the error on the operation where processing stopped.
Talpey:		Server may preallocate.
Eisler:		Use the record marking header and return the error immediately.
Shepler:	Agrees with Mike.
Talpey:		append 'within the same compound'

Halevy 2717:	Also needs a 'within the same compound'
Isaman:		Beware of non-idempotent operations: if you execute it, you
		cannot return REP_TOO_BIG in the SEQUENCE op.

Talpey 2753:	Make clear this is all within the context of the same
		COMPOUND or CB_COMPOUND.
	
Halevy:		Add a short paragraph to the CREATE_SESSION section explaining
		that there are 2 sets of channel attributes (one for the
		fore channel and one for the back channel)
		no concensus yet.
	
Talpey 2771:	is the MAY correct? Shouldn't it be stricter, since the
		client is encouraged always to put a GETFH.
Eisler:		There are cases where the client might not care (just wants
		to revalidate a path). Just wants to walk a path.
Macklem:	LOOKUP isn't non-idempotent.
Eisler:		Agrees...
Macklem:	Separate out idempotent and non-idempotent, and put
		MUST for the non-idempotent.
	2756	'especially important' -> MUST.
		Everyone agreed.

Talpey	2771	suggests this May be dropped.
		No consensus on the latter.
----

Halevy 2794:	Missing parenthesis.
---
Noveck 2781:	Distinguish between client failure and server failure.
		No consensus since Dave not there to argue case
---

Talpey 2849:	Don't refer to a specific section in another document (seems
		unsafe).
Eisler:		Expect this document to be published at the same time.
		Update the section number when the document gets published.
Macklem:	Put in the title of the section?
		All agree: Concensus.

---

Talpey 2847:	maxima to which each session channel is bound

----

Talpey 2930:	require -> permit

----

Talpey 2.10.6.3	Please rearrange.
		Move text explaining how NFSv4 works down and make it
		supportive. Start with v4.1 explanation.
Eisler:		NFSv4.1 improves on unauthorised state changes over
		v4.0
Myklebust:	We're really only protecting against sequence number
		changes.
Eisler:		Yes. State changes are protected against by access control.
Myklebust:	Acts like a REVOKE
Eisler:		Make it more explicit that this is not allowed
Myklebust:	Can we move SSV to clientID?
Eisler:		Possibly. Worry about issues with retry/replay. May be
		a major protocol change. Need consensus.
	Myklebust to raise issue on ietf lists.
---

Myklebust 3215:	What does the server do if it finds itself out of TCP
		sockets, and how does that affect the client obligations.
Eisler:		The server closes the socket?
Myklebust:	How does that affect the client obligations w.r.t. the
		backchannel?
	No idea yet how to solve
Gordon:		not clear when the callback path flag is reset.
Eisler:		Reset when the client has established callback channel.

Shepler:	Might be worth specifying that client might receive
		multiple CB_PATHDOWN errors. Limit the number of
		callback paths.
---

Talpey 3028	Making an unnecessary normative statement: A
		transport connection MUST be bound to a session by the
		client.
		You might want to issue a NULL ping (PROC_NULL) which is
		not bound to a session.
Eisler:		Disagrees...
Macklem:	Should we be talking about COMPOUND instead?
Eisler:		Disagrees...

---

Shah 3058:	Is it possible for the server to receive something other
		than a SET_SSV first? What does the server do?
Shepler:	An attacker could issue a BIND_CONN_TO_SESSION first?
Eisler:		Yes. Scenario already explained later. See line 3161
Talpey:		Reword for clarity?

---

Talpey 3084:	Everybody commented on Eve & Bob.
		'the Eve', 'Eve is the first one', ...
	3130:	Strenghten 'clue' to 'inform'

	3171:	'less difficult' appears to be identifying a vulnerabilty
		needs clarification.

---

	3180:	'Go away' -> 'expire'

	3200:	Resource limitations do not allow the server to cull sessions.
Eisler:		Idea is to deal with clients that die and never recover.
Talpey:		Just want to narrow the server's leeway.
----

Gordon 3203:	'should consider' -> SHOULD destroy.
Talpey:		How does the client know that a mount point is unused?
Eisler:		Could use a cron job...
----

Halevy 3215:	Clients MUST establish a callback path when it has leased or
		delegated state.
Talpey:		not MUST, but state might be in jeopardy.
Eisler:		Recallable state could be revoked.
Talpey:		RENEW is contingent on having a callback channel?
Eisler:		Not what the spec states.
Talpey:		Want to allow for thin clients that don't want recallable
		state.
Myklebust:	server should be returning CB_PATHDOWN on ever op.
	No concensus for a change of text.
---

Talpey 3292:	We're stating that the client should have used
		BIND_CONN_TO_SESSION. We're discussing a SHOULD as a MAY.
		Soften the paragraph?
	No concensus on that.
		Cross reference to the preceding text that clarifies this.
---
Gordon 3230:	clarify SET_SSV only the _first_ time a principal uses the
		session.
---
Talpey 3278:	The client may not want the session. Change MUST to SHOULD
---
Talpey 3283:	Same comment as previous.
Eisler:		Reword to  "If you want the session, then you must do this"?
     Concensus
---
Talpey 3295:	MUST -> SHOULD
Macklem:	Depends on whether or not the client holds recallable state.
Eisler:		Client also has the choice of giving up recallable state, in
		which case he does not need to reestablish backchannel.
---
Talpey 3313:	MUST -> SHOULD
Eisler:		Same argument as previous. Client has option of returning
		recallable state.
---
Talpey 3318:	'may' to 'might'
---
Talpey 3328:	We can live without this. How would this modify client
		behaviour?
---
Gordon 3347:	What happens in the case where the client reuses a slotid
		and sequenceid for a different request.
Eisler:		The client has screwed himself. The server may treat as
		a replay.
Shepler:	Do we have an error to return to the client if the server
		detects that the replay isn't the same request?
Talpey:		BAD_SEQUENCEID doesn't really fit.
	Nobody could find an appropriate error...
---
Talpey 3352:	Add statement that these objects are linked to the clientid
---
Talpey 3374:	Do we have text for this section?
Eisler:		Nope.
	Concensus was to let Noveck ponder...
---
Talpey 3384:	Add context about the EXCHANGEID being used to detect the
		client reboot.
---
Talpey 3400:	Flip statement around (see spreadsheet)
---
Talpey 3424:	'next SEQUENCE reply' is dodgy: sequencing is only defined
		per slot. Put the sr_status_flag on every reply until the
		client has established a callback channel.
Eisler:		Agreed.
---
Talpey 3428:	What does 'last' mean?
Macklem:	When all contexts have expired?
Eisler:		Agrees
---

Clock expiration time... Need to reschedule for the sessions related stuff
in other sections...

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