Subject: RE: [nfsv4] Stuff for issue 18, RECLAIM_COMPLETE

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 27 Jun 2006 17:21:35 -0400

The purpose of sending this out was to document the changes I
made, to solve the issue I addressed.  Problems in the current
draft can be documented in the issue tracker and should be
documented in the issue tracker rather than in email to the
last person that touched any particular file.

I believe STALE_CLIENTID can be returned, certainly when creating
a session.  I do have an issue to revise the filelocking chapter 
to reflect sessions.  Spencer and I need to figure out the 
boundaries of that issue (whether it includes updating the
specific ops and the errors as well).

I agree that ADMIN_REVOKED needs work but since I'm tihnking of 
proposing a substantive change in that area, I think it more 
likely that I'll deal with such errors in connection with that.

Putting this stuff in the issue tracker is the best way to make
sure it doesn't get forgotten, in case it somehow falls through the
cracks given the editing that people plan to do.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 2:39 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] Stuff for issue 18, RECLAIM_COMPLETE

On Tue, 2006-06-27 at 13:23 -0400, Noveck, Dave wrote:
> Storing files for the text of this issue to the issue tracker since 
> the IETF is not very friendly to non-trivial attachments.  The three 
> xml files are derived from the draft-03 files. Draft{Old,New}.txt 
> are in I-D text format and are subsets of the v4.1 draft limited to 
> relevant xml files.  rfc diff can be used on these two to see my 
> changes.  I've also included DraftNew.html for the ASCII-averse.
> Here are the links:

>         mvers_middle_errors.xml 

In the section on NFS4ERR_ADMIN_REVOKED, could we clarify that carried
over text from RFC3530 a little bit? A lockowner certainly cannot own a
delegation.

Could we document that an NFSv4.1 server should never return
NFS4ERR_BAD_SEQID (given that sessions are now mandatory to implement)?
Ditto for NFS4ERR_CLID_INUSE, and NFS4ERR_STALE_CLIENTID.

Cheers,
  Trond

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 27 Jun 2006 20:00:25 -0500

> cracks given the editing that people plan to do.

We have a different view of the use of the issue tracker 
so, I have to comment on its intended use.

When I conceived of using the issue tracker, it was to track the
existence of action items related to the development and completion
of the NFSv4.1 I-D.  

I wanted to ensure that action items were not lost or forgotten 
and that we had an "audit" trail to make sure we knew what happened.
I also wanted to enable anyone in the working group to create an issue
and drive it to concensus and closure.  This is meant to reduce
the bottleneck on any individual and make this an effort of the
overall working group.

The intent was not to supplant the correct process of working group
discussion via this alias or the working group meetings.

Therefore, any discussion of issues, resultant text or other
related activites must happen on the WG alias.  The issue tracker
should only be used for referring back to the thread of discussion
in the official IETF email archives.  It can also be used for
attaching a final version of the updated text but that is mainly
for the document editor's ease of tracking and incorporating changes.

The main reason for this is that the email archives will be around.
The issue tracker site and its data may eventually be removed
when the document becomes a full RFC.

So, resolve the issues here.  If other issues arise, please create
an issue in the tracker, refer to the email archive where the
issue arose and update the issue as it is resolved.  The one
exception I see to this is where there are grammatical or other
nits in document editing -- in those cases, it is unnecessary
to burden the WG alias with the announcement of an issue.

Spencer