Subject: [nfsv4] NFS4.1 Spec Review: Exchange ID and destroy Client ID (Part II)

From: "Erasani, Pranoop" <[email-masked]>
Date: Sun, 9 Sep 2007 19:54:38 -0700

Please find below the review comments captured from the second review
session scheduled for inspection of "Exchange ID and Destroy Client ID"
related chapters.

#Date#

August 30, 2007, 11 AM - 2 PM PST

#Participants#

Mike Eisler		- Network Appliance	(Moderator/Author)
Dave Noveck		- Sun Microsystems	(Inspector)
Ricardo Labiaga	- Network Appliance	(Reader)
Saadia Khan		- Network Appliance	(Inspector)
Pranoop Erasani	- Network Appliance	(Scribe/Inspector)
Trond Myklebust	- Network Appliance	(Insepctor)
Robert gordon	- Sun Microsystems	(Inspector)
Benny Halevy	- Panasas			(Inspector)
Fred Isaman		- CITI			(Inspector)

#Review Comments#

Line No.	Raised By		Comment
--------	---------		-------
23370		Khan,Erasani	Use SHOULD instead of MUST or current
MAY
		Labiaga

23399-23340	Labiaga,Khan	Probably there is another better place
to describe the note.
		Noveck

23434		Noveck		Can EXCHANGEID be issued along with
with SEQUENCE op? Has to be explained better. Maybe described elsewhere?
If so, refer that here.

23488		Eisler		Case 3: No state and no lease expired,
it should not return CLID_INUSE.

23506		Trond			Verifier matches and we have SSV
protections, what happens when the retry does not have SSV? (Suggestion:
REJECTED)

23483		Khan			Can Response to EXCHANGEID could
be different (although CLIENTID be the same), when minor id be
different?

23511		Fred			(line 23164 referred) It would
be nice to explain when clientid can be reused or when it is not.

23165		Fred			It is referring to subsequent
ExchangeID operation on a confirmed clientid

23511		Fred			4 & 5 should be made consistent.
Discussion lead to consensus on changing line 23548 clientid_ret ->
old_clientid_ret.

22972		Fred			Is this accurate? These
properties may be updated by subsequent EXCHANGEID request on a
confirmed clientid. Right?

23548		Fred			4 & 5 should be merged.

23611		Khan			s/clientid_ret/old_clientid_ret

23617		Khan			Original clientid_ret -> new
clientid_ret.

23620		Labiaga		Do we need to check the principal?
(Suggestion: Need not)

23661		Eisler		Expand 10 to include verifier mismatch.
Also, don't check principal if there is a verifier mismatch.

General	Eisler		A server can maintain maximum of 1 confirmed and
1 unconfirmed record for each client owner.

General	Khan			Same scenarios (1 - 10) are present in
CREATE_SESSION and need to be updated.

25735		Khan			what's the value of SSV the
first time around. (Suggestion: Zero). Seems to have been referred at
3404.

25740		Trond			Preferred algorithm for
generating SSV should be more of a pseudo-random number generator. That
suggestion should be mentioned here or
					whereever appropriate.

25753		Labiaga		Revisit Change of SSV wording. What this
really means? Additionally, Eisler agreed to review
BIND_CONN_TO_SESSION.

23768		Labiaga		Add that "ssa_ssv" not be zero.

25775		Labiaga		Clarify this paragraph. Say that it's a
bad idea to use SET_SSV with SSV GSS. Refer to core infrastructure
chapter.

25783		Eisler/Labiaga	This needs to be moved to core
infrastructure or description section. This is not an implementation
detail but part of the specification.

25783		Eisler/Labiaga	Is internal counter an implementation
detail? How is it realted to ssa_sequence?

26031		Eisler		s/unsued/unused.

That's all for the c Sep 2007 02:55:19.0359 (UTC)
	FILETIME=[05CFCCF0:01C7F356]
Subject: [nfsv4] NFS4.1 Spec Review: Exchange ID and destroy Client ID (Part
	II)

Please find below the review comments captured from the second review
session scheduled for inspection of "Exchange ID and Destroy Client ID"
related chapters.

#Date#

August 30, 2007, 11 AM - 2 PM PST

#Participants#

Mike Eisler		- Network Appliance	(Moderator/Author)
Dave Noveck		- Sun Microsystems	(Inspector)
Ricardo Labiaga	- Network Appliance	(Reader)
Saadia Khan		- Network Appliance	(Inspector)
Pranoop Erasani	- Network Appliance	(Scribe/Inspector)
Trond Myklebust	- Network Appliance	(Insepctor)
Robert gordon	- Sun Microsystems	(Inspector)
Benny Halevy	- Panasas			(Inspector)
Fred Isaman		- CITI			(Inspector)

#Review Comments#

Line No.	Raised By		Comment
--------	---------		-------
23370		Khan,Erasani	Use SHOULD instead of MUST or current
MAY
		Labiaga

23399-23340	Labiaga,Khan	Probably there is another better place
to describe the note.
		Noveck

23434		Noveck		Can EXCHANGEID be issued along with
with SEQUENCE op? Has to be explained better. Maybe described elsewhere?
If so, refer that here.

23488		Eisler		Case 3: No state and no lease expired,
it should not return CLID_INUSE.

23506		Trond			Verifier matches and we have SSV
protections, what happens when the retry does not have SSV? (Suggestion:
REJECTED)

23483		Khan			Can Response to EXCHANGEID could
be different (although CLIENTID be the same), when minor id be
different?

23511		Fred			(line 23164 referred) It would
be nice to explain when clientid can be reused or when it is not.

23165		Fred			It is referring to subsequent
ExchangeID operation on a confirmed clientid

23511		Fred			4 & 5 should be made consistent.
Discussion lead to consensus on changing line 23548 clientid_ret ->
old_clientid_ret.

22972		Fred			Is this accurate? These
properties may be updated by subsequent EXCHANGEID request on a
confirmed clientid. Right?

23548		Fred			4 & 5 should be merged.

23611		Khan			s/clientid_ret/old_clientid_ret

23617		Khan			Original clientid_ret -> new
clientid_ret.

23620		Labiaga		Do we need to check the principal?
(Suggestion: Need not)

23661		Eisler		Expand 10 to include verifier mismatch.
Also, don't check principal if there is a verifier mismatch.

General	Eisler		A server can maintain maximum of 1 confirmed and
1 unconfirmed record for each client owner.

General	Khan			Same scenarios (1 - 10) are present in
CREATE_SESSION and need to be updated.

25735		Khan			what's the value of SSV the
first time around. (Suggestion: Zero). Seems to have been referred at
3404.

25740		Trond			Preferred algorithm for
generating SSV should be more of a pseudo-random number generator. That
suggestion should be mentioned here or
					whereever appropriate.

25753		Labiaga		Revisit Change of SSV wording. What this
really means? Additionally, Eisler agreed to review
BIND_CONN_TO_SESSION.

23768		Labiaga		Add that "ssa_ssv" not be zero.

25775		Labiaga		Clarify this paragraph. Say that it's a
bad idea to use SET_SSV with SSV GSS. Refer to core infrastructure
chapter.

25783		Eisler/Labiaga	This needs to be moved to core
infrastructure or description section. This is not an implementation
detail but part of the specification.

25783		Eisler/Labiaga	Is internal counter an implementation
detail? How is it realted to ssa_sequence?

26031		Eisler		s/unsued/unused.

That's all for the comments capture in the meeting. This session
finished the inspection of Exchange ID and Destroy ClientID. Apologies
in advance, if I have associated a wrong name with the comment.

Thanks,
- Pranoop

-----Original Message-----
From: Eisler, Michael
Sent: Tuesday, August 14, 2007 6:25 AM
To: 'Spencer Shepler'; Van Belleghem,Audrey; [email-masked];
[email-masked]; Talpey, Thomas; Labiaga, Ricardo;
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Noveck, Dave; Khan, Saadia
Subject: RE: Kickoff: Exchange ID and destroy Client ID

Here are the lines of the spec,
http://www.nfsv4-editor.org/draft-13/draft-ietf-nfsv4-minorversion1-13-l
n.txt

that should be inspected (or simply read as noted below).

Definitions
815-849

866-844

Client and Server Owners
1193-1521

Trunking
2263-2424 - Previously inspected. Will not be re-inspected
            but useful for background material.

State Protection Model
3315-3722 - Previously inspected. Will not be re-inspected
            but useful for background material.

EXCHANGE_ID
22726-23661

SET_SSV
25681-25786

DESTROY_CLIENTIID
25995-26034 

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

omments capture in the meeting. This session
finished the inspection of Exchange ID and Destroy ClientID. Apologies
in advance, if I have associated a wrong name with the comment.

Thanks,
- Pranoop

-----Original Message-----
From: Eisler, Michael
Sent: Tuesday, August 14, 2007 6:25 AM
To: 'Spencer Shepler'; Van Belleghem,Audrey; [email-masked];
[email-masked]; Talpey, Thomas; Labiaga, Ricardo;
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; Noveck, Dave; Khan, Saadia
Subject: RE: Kickoff: Exchange ID and destroy Client ID

Here are the lines of the spec,
http://www.nfsv4-editor.org/draft-13/draft-ietf-nfsv4-minorversion1-13-l
n.txt

that should be inspected (or simply read as noted below).

Definitions
815-849

866-844

Client and Server Owners
1193-1521

Trunking
2263-2424 - Previously inspected. Will not be re-inspected
            but useful for background material.

State Protection Model
3315-3722 - Previously inspected. Will not be re-inspected
            but useful for background material.

EXCHANGE_ID
22726-23661

SET_SSV
25681-25786

DESTROY_CLIENTIID
25995-26034 

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