[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    RE: Updated revision draft-ietf-nfsv4-rfc3010bis-01-01.txt availa
From:       "Noveck, Dave" <Dave.Noveck () netapp ! com>
Date:       2002-06-06 13:46:26
Message-ID: 8C610D86AF6CD4119C9800B0D0499E336A8E5B () red ! nane ! netapp ! com
[Download RAW message or body]

I think there are issues (or at least an issue) that arose out of the 
"Strange file names" thread which Peter Astrand began in

http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2001/0767.html

and continued in 2002 with

http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0003.html

et seq.

In fact, in http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0016.html

Spencer wrote:

> > > Given that, I think returning INVAL for this is utter folly. How do 
> > > you debug if any operation that has a name in it may return INVAL? When 
> > > you get INVAL, it means that the server objected to one of the names 
> > > in it or there is something else wrong with the operation. Why make 
> > > it difficult for ourselves? Let's define things so that when we get 
> > > INVAL we can look for something invalid and when we get 
> > > NFS4ERR_TheServerChoosesToConsiderYourNameInvalid we can address that. 
> > 
> > Agree. I can confirm that it's very difficult to write test cases when you 
> > must prepare for INVAL on almost every error, and yet you cannot record 
> > this INVAL response as an server fault. 
>
> Agreed. I have placed an item on my todo list to add another error 
> value for the "invalid name" case.

I didn't see this on the issues list although I did see at least one item
(Issue88) that would be affected by this issue.

-----Original Message-----
From: Spencer Shepler [mailto:shepler@eng.sun.com]
Sent: Wednesday, June 05, 2002 6:58 PM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Updated revision draft-ietf-nfsv4-rfc3010bis-01-01.txt
available


You will find an updated RFC3010 specification at:

http://www.nfsv4.org/rfc3010updates/draft-01-01/draft-ietf-nfsv4-rfc3010bis-01-01.txt

and matching issues list at:

http://www.nfsv4.org/rfc3010updates/issues.html


The goal is to have the issues list completed and the documented
updated by the cut off date for the next IETF meeting.  This means to
have the updates completed by June 27th.

I have a few issues to add to the list that have been sent to me
directly but if you have something that is not reflected in the list
above, please let me know so that the item can be added and resolved.

-- 
Spencer


[prev in list] [next in list] [prev in thread] [next in thread]