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

Thomas Haynes <thomas@netapp.com> Thu, 21 October 2010 18:11 UTC

Return-Path: <Thomas.Haynes@netapp.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 171663A6452 for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 11:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.552
X-Spam-Status: No, score=-9.552 tagged_above=-999 required=5 tests=[AWL=3.046, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5uEQO5d-QDOH for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 11:11:27 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com []) by core3.amsl.com (Postfix) with ESMTP id 081903A6A91 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 11:11:24 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.58,218,1286175600"; d="scan'208,217"; a="471073702"
Received: from smtp1.corp.netapp.com ([]) by mx2-out.netapp.com with ESMTP; 21 Oct 2010 11:12:58 -0700
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com []) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9LICwB3015801 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 11:12:58 -0700 (PDT)
Received: from rtprsexc2-prd.hq.netapp.com ([]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Oct 2010 11:12:58 -0700
Received: from RTPMVEXC1-PRD.hq.netapp.com ([]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Oct 2010 14:12:52 -0400
Received: from smestad-lxp.hq.netapp.com ([]) by RTPMVEXC1-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Oct 2010 14:12:26 -0400
From: Thomas Haynes <thomas@netapp.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-27-139899672"
Date: Thu, 21 Oct 2010 13:12:24 -0500
Message-Id: <5E01B353-5B6B-448D-B614-ECFC8303A5D6@netapp.com>
To: nfsv4@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
X-OriginalArrivalTime: 21 Oct 2010 18:12:26.0323 (UTC) FILETIME=[841DEA30:01CB714B]
Subject: [nfsv4] [3530] Meeting Minutes, 10/21/10
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 18:11:31 -0000

3530bis Meeting Minutes, 9/23/2010


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


+ IETF Note Well Agreement

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


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

+ New questions from James' review of Namespaces


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


+ AI review/Draft deadline

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

+ No meeting on 11/04 due to IETF.