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