[nfsv4] NFS Version 4 Working Group, IETF 67th, San Diego November 6 and 8, 2006 Co-chairs: Spncer Shepler, Brian Pawlowski [Minutes from Lisa Week, minor adds by beepy] Monday, November 6, 2006 --- NFSv4.1 I-D todo review - "stage 0 requirements" (Shepler/Talpey/Eisler) Stage 0 Items - "Functional items that are in the document as well as major issues that have significant impact on the doc." * Need to close on these by the end of the day on Wednesday in order to get them into the next rev of the draft. Review/Plan for the NFS/RPC/RDDP last call I-D: Last call was called on these three drafts at last IETF. All three documents were changed and published a couple weeks ago. Some of these changes were large enough that they warrant a mini-"re-review". Recommended way to review, use the IETF diff tool. There was no normative text in the docs. This has been changed and needs review. Content change for the protocol: What to do with a round-up segment in a chunk list. Tom has discovered that the need for pad bytes is not once what he thought. Check this out... One section re-arranged. Text not changed, just moved. Also have a new IANA section. Tom's recommendations for who to review the doc: Mike Eisler, David Black (he has reviewed, and recommends finding people familiar with the protocol to review the normative text), Someone from DK Panda's team IANA Issues: 1.) netids - current rpcbind (RFC1832) defines "udp" and "tcp". Problem is that there is not an actual registry. Want to add "rdma" to that registry, but IANA needs help building it. Tom Talpey to report back on what IANA says. 2.) RPC program registry - IANA publishes it / it is maintained by Sun. IANA would need help initiating this registry. Want to register 2050 for RPC/RDMA port Review of SPKM BoF Mike Eisler Various proposals discussed and there were no clear winners. Vast majority of people are interested in having a public key mechanism for GSS-API. Design team to be formed and will decide on which of the four proposals will be the one that we go forward with it. Proposals put forth: SPKM - Andy Adamson and Olga K. (CITI) SSiLKey - Mike Eisler (NetApp) PKU2U - Larry Zhu (Microsoft) [D]TLS - Nico Williams (Sun) Issues: * We have a normative reference in NFSv4.0 and NFSv4.1 to SPKM. * Is there going to be another solution? Actions: AI: Spencer to start up the discussion on defining what the requirements actually are for NFSv4. Spencer suggests that we move forward with the references that we have today. AI: Andy to continue moving forward on what it means to interoperate with NFSv4 and SPKM. Recent NFSv4.1 Changes Spencer Shepler See slides for the review of issues incorporated and changes in drafts 06, 07 and 08. I-D 09 * Push to get all stage-0 issues included in this. * Rework of pNFS section for tighter integration into the overall I-D Summary of Trunking Changes / Multi-Server Namespace Re-cap Mike Eisler Replace CREATE_CLIENTID with EXCHANGE_ID EXCHANGE_ID returns a server owner, consisting of major and minor parts. (The draft talks about how to generate conflicting major numbers) Related Issues: 6, All of these changes have been incorporated. Issue tracking: 30, 135 46 - Requires an IANA registry for domain name. (i.e. ${ietf.org:xxx}) 96 97 - "Clear requirements on replicas' data equivalence": Protocol guarantees that upon receipt from the RPC response from WRITE, the client will be able to access the data that it just wrote from any one of the replicas 101 128 Issues - Stage-0 requirements Issues x & x: stream /rdmachannelattrs4 Idea was that when a session is created. A channel is bound to a session. The channel still exists, but it is not as core as it once was. Still an application for the channel attrs such as: "exchange transport characteristics from end-to-end" rdmachannelattrs4 was for publishing incoming RDMA queue depth (IRD) *This is the only one that is mandatory. An empty set right now...streamchannelattrs4 (?Do the following only pertain to this attribute or to the rdmachannelattrs4 as well?): What would be possible/interesting to exchange: * read and write size * block size - Server can tell the client its preferred block size, but the client can't tell the server what it wants. * tcp window size streamchannelattrs would be a void descriminated union. rdmachannelattrs would only have IRD. Issue 52: Is client migration capable? Proposal: Add eai_flags (EXCHANGE_ID_FLAG_SUPPORT_[REFER | MIGR] field to EXCHANGE_ID Do we need implementationid attributes if we now have EXCHANGE_ID? Right now, implementationid is a per server attribute, if we need per file system attribute, make a proposal... Sam and Lisa: We have one use for this (ACLs). It would be nice to know what the server file system is. Issue 116: Parallel opens There was dissention on the assertion that "removing upgrade on OPEN and make explicit the need for the manage client to manage state" was better than "keeping upgrade/downgrade logic in NFSv4.1 and expose the server's stateid.seqid". More thought is needed. We don't want to fix one performance problem and introduce a scalability problem. Consensus in the room was yes, we agree that we want a mechanism for parallel opens in NFSv4.1. But... Need a more definite list of pros and cons for proposed solutions. ACLs Mike Eisler Issues 121: SETATTR of mode to provide setting of non-permission bits Motivation: Allow setting of sticky,setuid,setgid without incurring any changes to the ACL. Proposal: Add a SETATTR-only attribute that includes a mask and a mode. 112: ACL inheritance changes 136: Additions to the Agenda for Wednesday: Spencer to finish the details for the parallel open piece for addition to the agenda on Wednesday. Alan to build a report on the ACL issues for Wednesday. Wednesday, November 8, 2006 --- NFSv4 WG Charter/Milestones review and update (Beepy/Shepler) This is the replacement charter for items past/after RDMA. 1.) NFSv4.0 maintenance As a charter item it is a little confusing to put NFSv4.1 under the NFS version 4 maintenance charter item. The NFSv4.0 bis would fit under there. So, create a milestone for the NFSv4.0 errata document (which doesn't exist yet, but that is okay) 2.) NFSv4 minor version 3.) RPC and XDR protocol maintenance Rob Thurlow still owns the RPC closure (Spencer will work with him on the IANA closures.) Don't change the specification from proposed to draft standard... 1831 will end up being proposed again and then moved to draft standard. Email on the charter will be sent to the nfsv4 wg alias. Prior work items have been put on hold: server to server replication /migration protocol and standard MIBs for management. Add milestones for: 1.) NFSv4.0 bis 2.) Last-call the errata version of the RPC doc. 3.) Advance RPC doc to draft. In the proto write-up for 4.1 include the summary of the interoperability event (Connectathon). Important to point this out for this for the IESG because first, they will have plenty of difficutly reviewing this document because it is so big. "There are N implementations and interoperability has been proven at event." Beepy to look into it: Why does it say that NFSv4 obsoletes NFSv2 and NFSv3? Can you remove the obsolescence clause? --- IPR disclosures update (beepy) On review of some, it is not clear that the patent applies to the work that "we" are doing. This IPR does not seem to be a show stopper for this protocol. Beepy to talk to Scott Bradner to see if the terms of this IPR are different from the ones that he has seen before. --- NFSv4.1 I-D review/inspection planning (Shepler) Review planning for how to complete NFSv4.1: I-D Stages Stage-0: Major restructuring complete inclusion of all functionality (we are past the point of new functions) Complete dot-x Consensus wrt required implementation experience. * Not sure that this applies anymore but... Spencer is not sure there is not enough resource and interest in this in order to make sure that this happens before the last call of the doc. Two reasons for having implementation experience: 1.) Find bugs in the specification 2.) Even if it gets implemented does the protocol solve the problem that it is supposed to (this is harder and takes longer) What should be targeted for testing at Connectathon in February? AI: Take the Connectathon testing discussion to the mail list. Stage-1: See presentation Stage-2: Implementation reports major copyediting work complete Second review for: normative language, document consistency, minor editorial issues Input from other working groups. Stage 3: Final prep for working group last call. I-D Review Planning: Who is willing or should review I-D? At what point? Review assignments? Restructure of stages? Other suggestions? June 2007 to have everything complete and off to IESG... We are closing in on Stage-0. This means that Stage-0 is functionally complete. Can we use the stages as milestones in order to track this through to the June 2007? Draft submission plans: Draft-09 submitted in December, submit Draft-10 after connectation, Draft-11 in April Mark Eshel to send mail to the WG to open an issue on pNFS readability of the documents. Changes rippling into the .x file should be done in the next couple weeks. (vs. changes for how referrals happen). IANA Issues (Tom Talpey) RPC/RDMA draft issues * New port number for RDMA; Will put in an application for port 2050 * New netid for RDMA port listening: RFC1833. Transport type, proto family name, netid (ip, tcp, icmp) Editing a text version of these things for a registry for these things. Send proposal to WG chairs, Lars and Tom. Then it would be sent to * New RPC program number registry: Output of 1831 will be the format of the registry. David Black suggests group look at IANA considerations for iSCSI extensions for ideas. Parallel Opens: How often would you see multiple opens for the same file at the server? Majority of people have one open owner per cred... Is the problem solved by having a new xid and more open owners? Eisler asks if problem is solved by taking Eric Kustarz's ideas and make more open owners... Worried about possible POSIX semantic of single open owner with Eric's suggestion. Spencer to hold on to the issue to see what the problems are and see if we can solve the issue a little more efficiently with 4.1. Need cleaner language on OPEN UPGRADE and how it is done. Spencer to summarize and drive for closure. Have the discussion on the wg alias in order to discuss the things being tested at cthon. Post-meeting at the IETF: Spencer and beepy stopped at the RFC Editor desk to see how we could best shepherd the new LARGE spec through the process. The helpful people there suggested we send the first twenty or so pages for mark up and review real soon and see if there are any trivial structural changes to make to entire document to ease that part of the review. They made a recommendation to move some material from intro into body (Spencer to follow up).