Subject: [nfsv4] Minutes from November 6 and 8 IETF NFSv4 WG Meeting

From: Brian Pawlowski <[email-masked]>
Date: Thu, 7 Dec 2006 03:57:08 -0800 (PST)

[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 <blah> 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 SCSI
extensions for iSCSI 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).

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 7 Dec 2006 11:10:10 -0600

If corrections are needed to these minutes, please post them
by mid-day Friday as tomorrow is the deadline for inclusion in
the IETF proceedings.

Spencer

---

From: [email-masked]
Date: Thu, 7 Dec 2006 19:00:42 -0500

> extensions for iSCSI for ideas.

Remove "SCSI" and rephrase, so it reads:

David Black suggests group look at IANA considerations for iSCSI
extensions for ideas.

Thanks,
--David

> -----Original Message-----
> From: Brian Pawlowski [mailto:[email-masked]] 
> Sent: Thursday, December 07, 2006 6:57 AM
> To: [email-masked]
> Subject: [nfsv4] Minutes from November 6 and 8 IETF NFSv4 WG Meeting
> 
> [nfsv4]
>