Subject: [nfsv4] [3530] Meeting Minutes, 10/21/10

From: Thomas Haynes <[email-masked]>
Date: Thu, 21 Oct 2010 13:12:24 -0500

3530bis Meeting Minutes, 9/23/2010
------------------------------------------------

Attendees
--------------

Tom Haynes (NetApp)
Trond Myklebust (NetApp)
Andy Adamson (NetApp)
James Lentini (NetApp)
Steve Dickson (RedHat)

Minutes
-----------

+ IETF Note Well Agreement

 This is a reminder that our discussions are governed by the 
 IETF Note Well Agreement. See:

   http://www.ietf.org/NOTEWELL.html

 We will start each week's meeting with this announcement.

+ New questions from James' review of Namespaces

http://www.ietf.org/mail-archive/web/nfsv4/current/msg08571.html

James will clarify his point on:

>> For the write-verifier class in Section 7.7.7, Section 7.9.1 
>> recommends assuming file system instances are of a different class in 
>> the case of a failover. Is there a recommendation for the 
>> NFS4ERR_MOVED case? I realize that the recommendations in 7.9.1 are 
>> taken almost verbatim from RFC 5661, but it seems that there is a case 
>> missing here.

Trond's point was that if a client had uncommitted writes when the
migration occurred, then it should assume that it has to reissue them.
He was going to check if this made sense to also point out in 5661.

On the observation over this point,

>> In Section 7.9's definition of a struct fs_location4, the server<> 
>> field's type was changed from utf8str_cis to utf8val_must. It seems 
>> that the original versions case-insensitive behavior is no longer 
>> being recorded. I suggest noting the case-insensitivity in the text 
>> description of an fs_location4 or creating a new type 
>> (utf8cis_val_must?).

We will be pointing out on the Beijing slide deck that we have indeed violated
the letter of the bis process, but willingly do so because as Trond points out,
"Nobody can follow the protocol as stated in 3530."

+ Trond's new agenda item: zero-length path components in fs_locations

Tom took an AI to add this to the task list. Trond pointed out there was some
good on-list discussion on this issue. Either Trond or James will provide
some new text.

One point that did come up in the discussion today was the fs_locations
has no provision to support the PUBLIC root.

+ Overview of sorted task list

skipped

+ AI review/Draft deadline

Going to submit what we have soon, no new effort planned

+ No meeting on 11/04 due to IETF.