Subject: RE: questions and comments on draft-ietf-nfsv4-rfc3010bis-02-03.t xt

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 9 Aug 2002 09:51:08 -0700

> Regarding:
> 
>    To provide a greater degree of compatibility with previous versions
>    of NFS (i.e. v2 and v3), which identified users and groups by 32-bit
>    unsigned uid's and gid's, owner and group strings that consist of
>    decimal numeric values with no leading zeros can be given a special
>    interpretation by clients and servers which choose to provide such
>    support.  The receiver may treat such a user or group string as
>    representing the same user as would be represented by a v2/v3 uid or
>    gid having the corresponding numeric value.  A server is not
>    obligated to accept such a string, but may return an NFS4ERR_BADOWNER
>    instead.  To avoid this mechanism being used to subvert user and
>    group translation, so that a client might pass all of the owners and
>    groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER
>    error when there is a valid translation for the user or owner
>    designated in this way.  In that case, the client must use the
>    appropriate name@domain string and not the special form for
>    compatibility.
> 
> I predict that the above will indeed produce mass
> subversion.  The original Secure-RPC (aka AUTH_DH) paper
> from Goldberg and Taylor (both then of Sun), promised
> a scheme similar to user@domain, but it ended up being
> implemented as number@domain. Pity.

Possibly.  On the other hand, even without it we have the 
possiblity of number@domain.  We don't specify what a name
means (how we decide it is valid etc), so "My read-only 
database has 4 billion entries and a particularly simple
way of accessing entries without actually having to store
them." is a valid answer even if it isn't the one you intend.

> Regarding,
> 
>    If the server continues to hold locks beyond the expiration of a
>    client's lease, the server MUST employ a method of recording this
>    fact in its stable storage. 
> 
> I don't see what (though I vaguely recall understanding
> this 3 years ago) holding the locks has to with the stable
> storage requirement. Clarification is needed.

I don't understand this either.

> Regarding,
> 
>      Even though CLOSE returns a stateid, this stateid is not useful to
>      the client and should be treated as deprecated.  CLOSE "shuts down"
>      the state associated with all OPENs for the file by a single
>      open_owner.  As noted above, CLOSE will either release all file
>      locking state or return an error.  Therefore, the stateid returned
>      by CLOSE is not useful for operations that follow.
> 
> Given that there is a seqid field in the stateid, is the
> above paragraph still true?

I think it is.  Is there a particualr case in which you were thinking it
might be useful?

> At least two places in the specification say a write
> delegation can modify its cached copy of the "change"
> attribute:
> 
>    The server will use a CB_GETATTR callback, if the GETATTR attribute
>    bits include any of the attributes that a write open delegate may
>    modify (size, time_modify, change).
> 
> AND:
> 
> 	The client returns attrbits and the associated attribute values
> 	only for attributes that it may change (change, time_modify, size).

> How is this possible? The client has no idea how the server is
> constructing the change attribute.

I wrote some text to deal with this issue.  The idea was that the
client could use the constaint that the server, if he were in control,
would have to update (i.e. increase) the change attribute and so even
though server may have a different form of change, the client is free
to increment it by one to indicate a change, even though the server
might choose to increment by some other amount.  This minimal update
would allow the serevr to resume his own control of the attribute.

Not sure where that text went.  I'm a liile unsure what draft we're
at (or even what day this is).

Spencer had some issues with my approach and was going to write up
an approach that refelected Sun's implementation experiences with 
delegation.  Not sure where that is.

One fact about the chaneg attribute is that clients are allowed to
look at the value and compare values assuming they are monotonically
increasing when the file or attributes change.  So the value is only
sort of opaque.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 9 Aug 2002 15:32:26 -0500

> increasing when the file or attributes change.  So the value is only

I have written a new section "Handling of CB_GETATTR" that describes
the methodology.  Will be in the upcoming draft.

-- 
Spencer

---

From: Mike Eisler <[email-masked]>
Date: Fri, 09 Aug 2002 14:10:14 -0700

> I think it is.  Is there a particualr case in which you were thinking it

My thought was the perhaps the seqid field in the CLOSE would be
one higher than before and so this would affect the sequence number used
in other operations that use stateids. But I claim ignorance.

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 16 Aug 2002 19:02:09 -0500

> increasing when the file or attributes change.  So the value is only

I did update the draft to include my description of how the client and
server should interact.  I have left this item on the issues list to
ensure that contradictions are not present in the latest draft.

-- 
Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 16 Aug 2002 19:03:50 -0500

> in other operations that use stateids. But I claim ignorance.

The stateid returned on CLOSE will have no effect on other stateids
used since CLOSE does end the sequence of state operations for the
openowner-file relationship.

-- 
Spencer