IETF Logo Mail Archive

Re: [nfsv4] LNFS functionality

Thomas Haynes <thomas@netapp.com> Thu, 19 May 2011 19:05 UTC

Return-Path: <Tom.Haynes@netapp.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261FEE0742 for <nfsv4@ietfa.amsl.com>; Thu, 19 May 2011 12:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.562
X-Spam-Level:
X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8XBNd80zLdT for <nfsv4@ietfa.amsl.com>; Thu, 19 May 2011 12:05:28 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6F5E06BE for <nfsv4@ietf.org>; Thu, 19 May 2011 12:05:28 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.65,238,1304319600"; d="scan'208,217"; a="549315812"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 19 May 2011 12:05:28 -0700
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p4JJ5Sap014602; Thu, 19 May 2011 12:05:28 -0700 (PDT)
Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 May 2011 12:05:28 -0700
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 May 2011 15:05:27 -0400
Received: from [10.58.49.78] ([10.58.49.78]) by RTPMVEXC1-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 May 2011 15:05:26 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-53--1040272629"
From: Thomas Haynes <thomas@netapp.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0588F4233A@MX14A.corp.emc.com>
Date: Thu, 19 May 2011 14:05:25 -0500
Message-Id: <583CCCE5-48B0-4B98-AA35-3520974A9EB9@netapp.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F693EBD@MX14A.corp.emc.com> <BANLkTikeg7-AKt07kGDLD_YTWStLva2ciA@mail.gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0588F41EA8@MX14A.corp.emc.com> <2FB04C06-FBE3-4CDB-8855-78ADB9CC19E4@netapp.com> <5E6794FC7B8FCA41A704019BE3C70E8B635281AC@MX31A.corp.emc.com> <BANLkTi=uFsCz7S7iMckHEM83DVyn0=9d1A@mail.gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0588F4233A@MX14A.corp.emc.com>
To: david.black@emc.com
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 19 May 2011 19:05:27.0102 (UTC) FILETIME=[B6C1C5E0:01CC1657]
Cc: nico@cryptonector.com, nfsv4@ietf.org
Subject: Re: [nfsv4] LNFS functionality
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 19 May 2011 19:05:30 -0000

On May 19, 2011, at 1:51 PM, <david.black@emc.com> wrote:

>>> 
>> 
>> c) A non-NFS-specific document defining "LFS", "PI", "DOI", IANA
>> registries, minimal semantics.


DOI should be something we reference from another I-D, no?


>> d) A non-NFS-specific document setting out an abstract schema for
>> distributed MAC policy.
>> e) One or more non-NFS-specific document setting out concrete schemas
>> and distribution mechanisms for MAC policy.
>>    - LDAP
>>    - XML + NFS/HTTP/whatever as the access method
>>    - Kerberos, PKIX, SAML authz-data
> 
> Two comments:
> 
> - The combination of (a) + (c) [object label functionality and label contents] needs to work without requiring (b) [RPCSEC_GSSv3], but with some functional restrictions (e.g., if there are subject labels, they are client-scoped).  I believe that we've agreed to this - RPCSEC_GSSv3 is optional, but there is RPCSEC_GSSv3 functionality (e.g., per-RPC subject label transfer) that will not be duplicated elsewhere.
> 
> In order to get 4.2 done, we are going to need at least the initial version of (c), as (IMHO), interoperability based solely on opaque labels won't fly in the IETF, so I would modify Nico's suggestion:


And we have an initial cut of that document already:

http://tools.ietf.org/html/draft-quigley-label-format-registry-00

v2.23.0 | Report a Bug | By Email