[nfsv4] [FedFS] Meeting Minutes, 10/14/2010

James Lentini <jlentini@netapp.com> Thu, 14 October 2010 19:42 UTC

Return-Path: <jlentini@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 DF6533A6956 for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 12:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=-2.470, BAYES_00=-2.599, FB_REPLIC_CAP=6.557, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Z8ORobhzgfo7 for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 12:42:18 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com []) by core3.amsl.com (Postfix) with ESMTP id D37E03A63D2 for <nfsv4@ietf.org>; Thu, 14 Oct 2010 12:42:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.57,332,1283756400"; d="scan'208";a="467581305"
Received: from smtp1.corp.netapp.com ([]) by mx2-out.netapp.com with ESMTP; 14 Oct 2010 12:43:38 -0700
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com []) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9EJhbWE010326 for <nfsv4@ietf.org>; Thu, 14 Oct 2010 12:43:38 -0700 (PDT)
Date: Thu, 14 Oct 2010 15:43:37 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: nfsv4@ietf.org
Message-ID: <alpine.LFD.2.00.1010141542270.4707@jlentini-linux.nane.netapp.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [nfsv4] [FedFS] Meeting Minutes, 10/14/2010
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, 14 Oct 2010 19:42:20 -0000

FedFS Meeting Minutes, 10/14/2010


Andy Adamson (NetApp)
Steve Dickson (Red Hat)
Sorin Faibish (EMC)
James Lentini (NetApp)
Chuck Lever (Oracle)
Trond Myklebust (NetApp)
Spencer Shepler (Microsoft)
Renu Tewari (IBM)


+ 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.

+ Admin Draft Update

  Draft -07 was posted on 10/10. There were not questions or 
  comments about the changes in the draft.

+ XDR encoding of "/"

  We discussed the issue raised in this thread:


  Sorin reported that the ESX implementation uses the 0 
  component encoding.

  We agreed that the FedFS text should describe the two 
  different encoding for "/".

  We agreed that implementations MUST accept both encodings.

  There was debate about RECOMMENDING an encoding.

  Trond didn't see a reason to prefer one encoding over another.
  He noted that one saved a few bytes, but the differences were 

  Renu pointed out that if implementations MUST accept both, 
  recommending an encoding wouldn't eliminate the need to 
  support both formats.

  We decided not to recommend an encoding.

  With that resolved, Trond asked a related question: What 
  if an arbitrary path component has 0 length?

  Chuck reported that his tools eliminate double '/' 
  characters (e.g. "/a/path//list/this/").

  James reported that the SNSDB tools prohibit double '/' 
  characters. The user receives an error if he/she attempts 
  to enter a path containing them.

  We discussed possible conventions for handling path arrays 
  with 0-length components: ignore the null components, attempt
  to lookup them up, etc.

  Trond pointed out that a (naive?) client might walk through 
  the components doing lookups. Such a client could call lookup 
  with a 0-length string when processing a 0-length component4 

  Chuck noted that some implementations will process the components 
  in this manner to detect junctions, etc.

  Trond agreed to post a message about this to the WG email alias.
  We expect discussion on this topic in the context of RFC3530bis.

  James said that the FedFS documents will include notes on these 
  issues that is either in sync or references the 3530bis text.

+ Procedure for generating UUID values in Section of NSDB draft

  Rob may have some suggestions for implementers on choosing UUID values.
  James will follow up with him.

  We reviewed the sentence on "test" UUIDs:

     It MAY also be useful, for purposes of debugging or annotation, to
     permit a fedfsUuid to include members of a more general class of

  Chuck noted that the ONC RPC Admin protocol's FedFsUuid type is 
  defined to take binary UUID values (16 bytes). This means that 
  "test" UUIDs cannot be passed over the Admin protocol.

  James suggested removing this sentence.

  No objections from Chuck. We'll discuss on the WG reflector.

+ Definition of a fedfsAnnotation

  The fedfsAnnotation LDAP attribute is defined in Section of 

  Chuck identified a typo in the text (extra 'may') on page 24:

  "KEY and VAL MAY may... "

  Upon reviewing the description in, James felt that the 
  sentence about white space (begins on page 23) needs to be 
  clarified. It pertains to white space between the tokens, not 
  within the KEY and VAL fields.

  Finally, Chuck asked if the NUL character could occur within 
  a fedfsAnnotation value. 

  James had researched this and had not found anything in the 
  LDAP attribute syntax inherited by fedfsAnnotation to 
  prohibit it. James noted that the intention was not to allow 
  NUL characters.

  Chuck said that the question about NUL characters only 
  pertains to the fedfsAnnotation and fedfsDescr attributes.
  There is no ambiguity with the other FedFS LDAP attributes.

  James was unaware of any LDAP tools that would allow a user to 
  input a NUL character via their UI (either text or graphical).

  Chuck noted that a C client could encode such a 
  value using the C LDAP API. He had not tested to see if an 
  LDAP directory would accept such a value for a fedfsAnnotation.

  Chuck suggested that if this is an issue, there could there 
  be another more appropriate attribute that fedfsAnnotation (fedfsDescr)
  could inherit from.

+ Any other WG last call issues?

  No issues were raised.

+ Meeting schedule

  Our next meeting will be on October 28. Along with other items, we'll 
  review the updated draft-adamson-nfsv4-multi-domain-access-03 I-D.
  Andy will send an updated email with questions to the WG list. 
  He is also aware of a related draft (draft-sorce-krbwg-general-pac-00) 
  that may be related to his work.

  What should future meeting schedule be? Dependent on WG last call?

  Chuck can think of two ongoing architectural questions that 
  we might want to discuss: NFSv4.2 features for FedFS and/or 
  anything beyond the current FedFS drafts.

  Trond suggested that it would be interesting to have the admin
  protocol integrated into NFSv4.2 rather than a sideband protocol.

  Chuck suggested discussing ways to implement the replication 
  protocol that could be triggered by FEDFS_*_REPLICATION.

  We'll keep the topic of meeting schedules and topics on the agenda 
  for next time.