Re: [nfsv4] IETF 89 - NFSV4 WG meeting (Meeting Notes)
Spencer Shepler <sshepler@microsoft.com> Wed, 05 March 2014 21:24 UTC
Return-Path: <sshepler@microsoft.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 123091A0724 for <nfsv4@ietfa.amsl.com>; Wed, 5 Mar 2014 13:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmztkuQyHNZg for <nfsv4@ietfa.amsl.com>; Wed, 5 Mar 2014 13:24:18 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id B51C51A02EE for <nfsv4@ietf.org>; Wed, 5 Mar 2014 13:24:16 -0800 (PST)
Received: from BL2PR03MB369.namprd03.prod.outlook.com (10.141.89.12) by BL2PR03MB594.namprd03.prod.outlook.com (10.255.109.37) with Microsoft SMTP Server (TLS) id 15.0.888.9; Wed, 5 Mar 2014 21:24:12 +0000
Received: from BL2PR03MB369.namprd03.prod.outlook.com ([10.141.89.12]) by BL2PR03MB369.namprd03.prod.outlook.com ([10.141.89.12]) with mapi id 15.00.0883.010; Wed, 5 Mar 2014 21:24:11 +0000
From: Spencer Shepler <sshepler@microsoft.com>
To: "faibish, sorin" <faibish_sorin@emc.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Thread-Topic: IETF 89 - NFSV4 WG meeting (Meeting Notes)
Thread-Index: AQHPOHvxKpJZcMdE2kWqT9yJ2XBhmZrTAWlA
Date: Wed, 05 Mar 2014 21:24:10 +0000
Message-ID: <25eb8c9c4fcc4fa488771eb51376b4fb@BL2PR03MB369.namprd03.prod.outlook.com>
References: <42d776e935744f1cba9f2b100809d4a7@BL2PR03MB369.namprd03.prod.outlook.com> <2512424DBC01FD48843E938C780FA97C0BBBEC24EE@MX23A.corp.emc.com>
In-Reply-To: <2512424DBC01FD48843E938C780FA97C0BBBEC24EE@MX23A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.107.160.181]
x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
x-forefront-prvs: 01415BB535
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(57704003)(377454003)(199002)(189002)(53806001)(16236675002)(19580405001)(56816005)(54356001)(94946001)(95416001)(49866001)(47446002)(47976001)(33646001)(74502001)(80022001)(15975445006)(69226001)(83322001)(19580395003)(63696002)(94316002)(80976001)(81342001)(92566001)(66066001)(90146001)(83072002)(85852003)(86362001)(46102001)(76796001)(76576001)(65816001)(31966008)(15202345003)(47736001)(81542001)(77982001)(79102001)(51856001)(59766001)(19300405004)(93516002)(81686001)(2656002)(87936001)(95666003)(85306002)(93136001)(81816001)(87266001)(86612001)(74706001)(74876001)(50986001)(4396001)(76482001)(74366001)(76786001)(74316001)(54316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR03MB594; H:BL2PR03MB369.namprd03.prod.outlook.com; CLIP:131.107.160.181; FPR:CE3FF0E5.A8F2E145.F3CE71B2.5DE8C983.20952; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_25eb8c9c4fcc4fa488771eb51376b4fbBL2PR03MB369namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/nfsv4/RRCHHrC-XnDieU5MZW323VfZQMk
Subject: Re: [nfsv4] IETF 89 - NFSV4 WG meeting (Meeting Notes)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 05 Mar 2014 21:24:26 -0000
Thanks a lot, Sorin! Very helpful. I have posted these as minutes. If there are needed updates, please let me know. Spencer From: faibish, sorin [mailto:faibish_sorin@emc.com] Sent: Wednesday, March 5, 2014 6:05 AM To: Spencer Shepler; nfsv4@ietf.org Subject: RE: IETF 89 - NFSV4 WG meeting (Meeting Notes) These are the notes that I took during the nfsv4 WG meeting at IETF 89 in London. NFSv4 Working Group London Time: 9:00 - 11:30 GMT Room: Richmond/Chelsea/Tower Date: Wednesday March 5, 2014 [version 0.4] Tom: Note well read Martin Stiemerling: Tom was allegedly selected as the WG secretary announced by Martin Martin: There are several errata that need to be submitted and need attention. Tom Haynes: You refer to an errata that fix another errata so no real errata needs attention 1. "Bis" work - (Haynes / Noveck / Black) (30 minutes) David Black presents the latest draft on i18n Internationalization on 3530bis-25 IESG issues with i18n Cannot use "must not" as there is at least one server implementation that can be mis-configured. Scott Bradner (Harvard): cannot use "should not" Summary: ready for last call Pete Resnick offered to look at the specific text on i18n Tom discussion on 3530bis What other comments except i18n need attention History of 3530 draft 25 went to IESG for review in 2013 Migration, Kerberos (address in 5661 but need to be updated with current Kerberos implementation) and i18n Where are we? Draft 32 has the i18n changes Tom put draft -33 out for review still some nits to be fixed from Gen-ART addressed in -33 Will always have nits as being 10 years old, some customers unhappy with lack of attention Any comments for last call; was called and moved to the list 2. Tom and Noveck: Minor versioning status 4.0 and MV 4.1 took a long time 4.2 was small and no problem as it is limited in scope draft-dnoveck-nfs-extension rev -01 ready xdr extension and xdr replacement 4.1 was really 5 as a new protocol and wasa not able to fix 4.0 issues in 4.2 4.2 added a set of optional 4.2 implementations just mentioned not supported for additional features 01 of Noveck will be submitted soon; added last 6 month new text Tom and Dave work on the doc -00; what MV are needed; should people write their own Draft provides framework for discussing of a new standard-track documents Suggest a path fwd Core items: xdr extension New MV rules Integrate pNFS mapping types in MV model New features outside MV framework Items in -00: XDR extent model; new MV rules; MV should make sense for all versions Distinguish features from feature elements and re-specify minor versions in terms of features Alex McDonald: observation need to describe to the users the features in sense of names how you deal Externally to labeling the features to be attractive for users Matt Benjamin: maybe can have labels in the MV before new additions Mark Eshel: need a way to describe and which will go to be developed in 4.3 Tom Haynes: you can handle or not handle in 4.x Feature discovery document is needed Do we need experimental versions: 4.3 to 4.4 Figure which is "recommended" versus "experimental" How do we define the trains for MV How to tackle features inside the MV A lot of energy was put into this discussion. Matt: need more agility in MV; should features drop out and be re-specified? Should have running code before closing a MV to ensure they are correctly specified instead of deprecation or re-featured 3. Labeled NFS Updates and Issues (Haynes) (10 minutes) No discussion 4. NFSv4.2 Updates and Issues (Haynes) (10 minutes) Just 3 years; take long because running code not done. All just finishing 4.1 this is why it took so long. They planned to work In 4.2 but 4.1 was not yet ready for customers Sorin: complication due to pNFS confusion; people wanted 4.1 but were told need to use pNFS. We discovered on copy server there are questions related to the exclusive lock=major hole Server-side copy implemented by OnTap Linux client has proto LNFS is shipping in Linux but lack rpcsec_gssv3 Minor issues: asynchronous copy can be requested by user and chunk it in small pieces instead of a single operation That will allow out of order to be executed. Allow restart of consecutive copies in order Hole punching are MD intensive and no need to be async some servers have to 0 How 4.2 interacts with layouts and with pNFS; how SSC interacts to pNFS. RPCSEC_GSSv3 is needed for end-to-end security requirement; we have to provide as optional Alex: make deployment non-optional of GSS gssv3 doesn't have a dependency on NFSv4.2 Was (ietf 88) decided to and go with gssv3 SSC changes to make it more attractive to users Document the interaction with layouts/pNFS Mark: we need implementations on what goes in the spec and set deadline to when to decide or find alternatives. 5. RPCSEC_GSSv3 I-D Update (Adamson) (15 minutes) New version of the draft -06 Repurpose to 4.2 use only v3 is a proper superset of v2 gssv2 introduce channel binding and it was dropped of v3 Removed all the mixed version changes Same format as v2 just added a new version 2 rpcsec_gss_create is a new call creates a "child" for old handle Reply verifier change: child and parents share same context Stop man in the middle attack Compound authentication: server grants perm only if both client and server are authenticated together Alex: is compound name correct? Compound a machine and a user not v4.0 compound in nfs rpc; David Black: this notion is different than normal compound; pass both handles and get both authentications. Need to explain what compound means in the draft David Black: May help the confused find the def. of compound. Matt: context of this document is used similar of the combined in AFS, there is a large community of AFS that can be asked for opinion and help Martin Stiemerling: find someone from security directory and Martin will send to the security directory Additional tools: structured privileged assertion used by SSC; security label assertions; clients need to find out what server security has Alex: require a pre-authorization? Andy: No just a gssv3 handle. Need help to review by the list GCCv3 context: clients and servers have to cache the context and handles Questions for list: child destroyed imply server handle destroyed? gssv3 is informative for 4.2; gss set the rules and 4.2 just uses Matt: what are implications for the server to the destroy from client handle 6. RPCSEC_GSSv3 use in NFSv4.2 (Adamson) (30 minutes) gssv3 used for SSC Source server must authenticate the destination server There is a issue with the read Limit the ability to only make one copy Generated shared secret and distributed by gssv3 independent of the user; pass info from the Client to the destination server Matt: this technology has utility in NFS community Need to change te "compound" to some other name Alex: at this point will revoke but there is guarantee that the client allow for the connection and the read to go through This is how you identify the read from other reads Alex: we look up for every read operation? Andy: Not; only once Copy can only continue if the 3 handles client; source and destination has to match the 3 gssv3 handle match. If not if one is missing then this will stop the copy Chris Ignatio CMU: If break one leg and have a valid poor behaving server can the client still allow the copy; Andy: answer is no. the client will revoke It is really hard to do when one server doesn't check the handle. Alex: if i have a pNFS layer and want to move part of the data from one server to another; is this possible? Is there a control protocol That can control this copy of partial layout. Can use the stateid to identify the chunk to be copied. DS to DS copy needs more thinking; or source pNFS server to nfs server. Sorin: v4 nfs copy to nfsv3 is another exception where stateid will not work 7. Xattr Protocol Extensions (Eshel) (20 minutes) Can use named attributes? Doesn't work for most OSs There is a semantic mismatch with xattr Propose a new protocol that is opaque to the client/server can extend existing xattr add new attributes Tom: max attribute size is max a single xattr and all means size of all attributes? Mark: will clarify in the draft Current getattr/setattr allows to add more flags to the array but it is not extendable in this way Extended will managed same as ACLs Delete by use length of 0 Extend xattr option is not useable Option 2: define new rpc for getattr/setattr is flexible and extensible Option 3: use current rpc and extend it with getattr_plus/setattr_plus Which option Sorin & Matt: Option 2 seems the closest to the POSIX and could be accepted by Linux OS for implementation. Alex: this is still not completely acceptable for underlying FS Need to take the question to the list Will define implementation and write a new draft 8. pNFS Metadata Striping (Benjamin) (15 minutes) draft-mbenjamin-nfsv4-pnfs-metastripe Continue work of Mike Eisler to support parallel MD operations Use a new pNFS layout to allow MD stripe Changes from previous: Avoid req to take multiple layouts merged into one Dir striping for create and enumeration Simplify MD layout slightly: remove layout file handles; simplify device model Layout sub-type names Improved language New directory striping algorithm will be in next draft New items: layout sub-types and address dir fragmentation algorithms; Lustre is also doing same Ganesha implementation and PyNFS implementation New version -03 will be posted Mark: Explain what striping is used. Matt: CEPH fragmentation algorithm will be used, simple striping model and a hash of an object modulo the device number Use CEPH model of striping; recursive striping strategy that descends on the tree. Mark: will get the attributes from different servers and hash; what hash algorithm will be on the namespace split. Adjourned. From: nfsv4 [mailto:nfsv4-bounces@ietf.org] On Behalf Of Spencer Shepler Sent: Friday, February 07, 2014 11:21 PM To: nfsv4@ietf.org<mailto:nfsv4@ietf.org> Subject: [nfsv4] IETF 89 - NFSV4 WG meeting (time and agenda) The NFSv4 WG meeting is scheduled for March 5, Wednesday at 9am GMT. You will find the full agenda here: https://datatracker.ietf.org/meeting/89/agenda.html The NFSv4 working group agenda can be found here. https://datatracker.ietf.org/meeting/89/agenda/nfsv4/ Please let me know if you have updates for this agenda. Spencer
- [nfsv4] IETF 89 - NFSV4 WG meeting (time and agen… Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (Meeting N… faibish, sorin
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (Meeting N… Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (Meeting N… Black, David
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Marc Eshel
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Adamson, Andy
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Tom Talpey
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Adamson, Andy
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Andy Adamson
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Benny Halevy
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … Spencer Shepler
- Re: [nfsv4] IETF 89 - NFSV4 WG meeting (time and … faibish, sorin