[nfsv4] [FedFS] Meeting Minutes, 10/14/2010
James Lentini <firstname.lastname@example.org> Thu, 14 October 2010 19:42 UTC
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6533A6956 for <email@example.com>; Thu, 14 Oct 2010 12:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([184.108.40.206]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8ORobhzgfo7 for <firstname.lastname@example.org>; Thu, 14 Oct 2010 12:42:18 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [220.127.116.11]) by core3.amsl.com (Postfix) with ESMTP id D37E03A63D2 for <email@example.com>; 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 ([10.57.156.124]) 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 [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9EJhbWE010326 for <firstname.lastname@example.org>; Thu, 14 Oct 2010 12:43:38 -0700 (PDT)
Date: Thu, 14 Oct 2010 15:43:37 -0400
From: James Lentini <email@example.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [nfsv4] [FedFS] Meeting Minutes, 10/14/2010
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 19:42:20 -0000
FedFS Meeting Minutes, 10/14/2010 --------------------------------- Attendees --------- 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) 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. + 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: http://www.ietf.org/mail-archive/web/nfsv4/current/msg08573.html 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 minimal. 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 value. 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 18.104.22.168 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 strings. 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 22.214.171.124 of draft-ietf-nfsv4-federated-fs-protocol-09. Chuck identified a typo in the text (extra 'may') on page 24: "KEY and VAL MAY may... " Upon reviewing the description in 126.96.36.199, 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.
- [nfsv4] [FedFS] Meeting Minutes, 10/14/2010 James Lentini
- Re: [nfsv4] [FedFS] Meeting Minutes, 10/14/2010 Spencer Shepler