Subject: [nfsv4] draft-11 EXCHANGE_ID

From: Fredric Isaman <[email-masked]>
Date: Thu, 21 Jun 2007 11:41:50 -0400 (EDT)

I've started to update some sessions code to draft-11, and have been 
parsing through EXCHANGE_ID, taking notes.  I have several 
questions/comments, as well as noting several typos, that I've indicated 
below.

 	Fred

1199: client ID "is changed whenever the client or the server reinitializes"
       Not true, perhaps something like "may be changed..." 
1209: s/established, are/established are/
1331-1333: DELETE - this paragraph is a bit unclear and is
       superceded/contradicted by the section starting on line 1442
1332: s/principal established/principal which established/

SESSIONS
========
3341: s/not be have/not have/

ERROR LISTS
===========
16051 s/_BADSESSION/_DEADSESSION/

EXCHANGE_ID
===========

22552: s/and all except as noted, sessions/and, except as noted, all sessions/
      : QUESTION - what/where are exceptions noted?
22662: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
22664-22695: These descriptions don't seem to match very well with the
        cases given in 17.35.5:
        The paragraph at 22664 overlaps with cases 2 and 4
        The paragraph at 22675 overlaps with cases 7 and 4
        The paragraph at 22691 overlaps with cases 1, 5, 6, and 8.
22833: s/the option issuing/the option of issuing/
23084: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
23147: Case 5: Updating the client ID here seems inconsistent
        with cases 6 and 8, especially if cases 6 and 8 update properties,
        as the various lines stating "the server MAY refuse to change...
        <confirmed records>" and the paragraph starting at 22691 would suggest.
23160: s/is deletes/is to delete/
23167: DELETE - this is redundant with sentence starting at 22660,
               - if want to include, then why not in cases 6 and 8 too?
23169: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
23206: QUESTION - Case 7: It is not made clear here that the new record
        updates/replaces the old.  This is the only case that leaves this
        ambiguous. This would leave both the old confirmed and the new
        unconfirmed clientids associated with ownerid_arg.  But I note that
        the phrase "Any cases in which there is more than one record with
        identical values for ownerid_arg represent a server implementation
        error." was removed.  So is this intentional?
23244: Case 8: you want to update the principal too a la case 6, so...
23255: s/.co_verifier and/.co_verifier and the principal field and/
23259: s/, *,/, principal_arg,/

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 21 Jun 2007 12:01:02 -0400

>       Not true, perhaps something like "may be changed..." 

Why is this not true?  Not sure what you are getting at here. 

-----Original Message-----
From: Fredric Isaman [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 11:42 AM
To: [email-masked]
Subject: [nfsv4] draft-11 EXCHANGE_ID

 	Fred

1199: client ID "is changed whenever the client or the server
reinitializes"

SESSIONS
========

ERROR LISTS
===========

EXCHANGE_ID
===========

22552: s/and all except as noted, sessions/and, except as noted, all
sessions/
      : QUESTION - what/where are exceptions noted?
22662: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
22664-22695: These descriptions don't seem to match very well with the
        cases given in 17.35.5:
        The paragraph at 22664 overlaps with cases 2 and 4
        The paragraph at 22675 overlaps with cases 7 and 4
        The paragraph at 22691 overlaps with cases 1, 5, 6, and 8.
22833: s/the option issuing/the option of issuing/
23084: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
23147: Case 5: Updating the client ID here seems inconsistent
        with cases 6 and 8, especially if cases 6 and 8 update
properties,
        as the various lines stating "the server MAY refuse to change...
        <confirmed records>" and the paragraph starting at 22691 would
suggest.
23160: s/is deletes/is to delete/
23167: DELETE - this is redundant with sentence starting at 22660,
               - if want to include, then why not in cases 6 and 8 too?
23169: s/NFS4ERR_ENOENT/NFS4ERR_NOENT/
23206: QUESTION - Case 7: It is not made clear here that the new record
        updates/replaces the old.  This is the only case that leaves
this
        ambiguous. This would leave both the old confirmed and the new
        unconfirmed clientids associated with ownerid_arg.  But I note
that
        the phrase "Any cases in which there is more than one record
with
        identical values for ownerid_arg represent a server
implementation
        error." was removed.  So is this intentional?
23244: Case 8: you want to update the principal too a la case 6, so...
23255: s/.co_verifier and/.co_verifier and the principal field and/
23259: s/, *,/, principal_arg,/

---

From: Fredric Isaman <[email-masked]>
Date: Thu, 21 Jun 2007 12:31:38 -0400 (EDT)

> Why is this not true?  Not sure what you are getting at here.

The client can reboot and change it's verifier w/o calling EXCHANGE_ID to 
get a new client ID.

The server can reboot and retain enough info that the client is not forced 
to call EXCHANGE_ID and get a new client ID.

I read "is changed *whenever* the client or the server reinitializes" to 
imply that in the above situations a new client ID must be generated, 
which is not true.

 	Fred

---

From: Mike Eisler <[email-masked]>
Date: Thu, 21 Jun 2007 09:54:30 -0700 (PDT)

> The client can reboot and change it's verifier w/o calling

How can it change its verifier without calling EXCHANGE_ID?

> imply that in the above situations a new client ID must be generated,

I agree that server reinitialization, for some definitions of
reinitialization, does not imply the client ID is tossed.
I will attempt to clarify this in draft-12. I'll also go over
your other comments.

---

From: Fredric Isaman <[email-masked]>
Date: Thu, 21 Jun 2007 13:06:43 -0400 (EDT)

> How can it change its verifier without calling EXCHANGE_ID?

Oops, my mistake.

> I will attempt to clarify this in draft-12. I'll also go over

Thanks.

 	Fred

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 21 Jun 2007 15:36:49 -0400

> to call EXCHANGE_ID and get a new client ID.

Sure but this is an introductory section.  Trying to deal with
all those possibilities is going to make it hard to convey the
concepts to the user.  After all, we are saying "is changed"
and not "MUST be changed".

In particular, saying "may be changed" is going to give the
reader a completely wrong idea, i.e. that this is in some way
optional, in that you can simply decide not to do it.

The fact that you can save enough state so that you can reboot
and still not reinitialize, from the v4 protocol point of view, 
is a subtlety that may be worth mentioning somewhere but if
we do it here, I'm afraid it might make someone's head explode.

-----Original Message-----
From: Fredric Isaman [mailto:[email-masked]] 
Sent: Thursday, June 21, 2007 12:32 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: RE: [nfsv4] draft-11 EXCHANGE_ID

> Why is this not true?  Not sure what you are getting at here.

The client can reboot and change it's verifier w/o calling EXCHANGE_ID
to 
get a new client ID.

The server can reboot and retain enough info that the client is not
forced 
to call EXCHANGE_ID and get a new client ID.

 	Fred

---

From: Mike Eisler <[email-masked]>
Date: Fri, 22 Jun 2007 05:41:28 -0700 (PDT)

>         <confirmed records>" and the paragraph starting at 22691

The intent was that EXCHGID4_FLAG_UPDATE_A flag is not set
for cases 5, 6, and 8; this was not explicit in draft-11, 
but will be in draft-12.

Also, cases 5, 6, and 8 are all for unconfirmed records. 
I didn't see any place where the spec says the server MAY 
refuse to change properties of unconfirmed records.

The _UPDATE_A flag is rejected on unconfirmed records. Conversely,
if _UPDATE_A is not set, the operation may update properties
of unconfirmed records. I think draft-12
will make this clearer (I'll change the flag name too).

There are now a total of 10 cases, the first 7 are for when
the _UPDATE_A flag is not set, and the  last 3 are for when it
is set. The text in the description subsection now just
refers to the cases.

I've incorporated the rest of your suggestions and comments.