From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 12/11/02-12:34:40 PM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A0729A7@SILVER.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: Draft minutes from Atlanta Nov 18, 2002 IETF 55 mtg
Date: Wed, 11 Dec 2002 10:34:40 -0800
> During the open discussion, there were comments about minor revision
> suggestions. Dave Noveck mentioned that since file delegation support
> was present in the NFSv4 protocol that it seemed appropriate to
> consider adding support for the delegation of directories. There seems
> to be interest and use for such a mechanism. Dave also suggested that
> it may be useful to enable the client to reestablish a delegation after
> recall and that this may also be a reasonable minor version item. It
> was also suggested that providing this type of functionality may enable
> the ability to support NFSv4 proxy caching.
"enable the ability to support NFSv4 proxy caching." doesn't seems right to
me. I'm going to argue that I must have said "enhance", unless you have
this on tape :-)
In any case, I am trying to put together a document to explore the
issues (sort of a combination of problem statement and design
considerations but no actual protocol messages), and the needs of
NFS proxy caching in this regard are very much in scope.
I'd appreciate hearing from anybody who has potential requirements
in the delegation area, whether related to NFS proxy caching or not.
-----Original Message-----
From: Brian Pawlowski [mailto:beepy@netapp.com]
Sent: Wednesday, December 11, 2002 3:01 AM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Draft minutes from Atlanta Nov 18, 2002 IETF 55 mtg
18 November 2002
NFSv4 WG meeting
Atlanta
The agenda was:
Monday November 18: 19:30pm - 22:00 (2.5 hours)
Welcome and Introduction (Pawlowski) 5 min
Agenda bash etc.
- BLUE SHEETS
- NOTE WELL
- Status of drafts
Bakeathon results and issues (Shepler) 10 min
Final RFC 3010 resubmission status (Shepler) 10 min
Migration/replication (Thurlow) 25 min
NFS and ROI work (Pawlowski) 10 min
Review of work items (Shepler/Pawlowski) 15 min
- API GSSAPI advancement
- MIB draft resurrection
- RPC/XDR/RPCSEC_GSS RFC plans
Open discussion (Pawlowski) 10 m
Wrapup (Pawlowski) 5 m
Brian Pawlowski started with a welcome to the NFSv4 WG intro and went
over the posted agenda and asked for any additional items; none were
suggested.
Spencer Shepler presented results of interoperability testing at the
Bakeathon held in October. No protocol problems found. Six
implementations. Five implementations had Kerberos implemented.
UofM group got base NFS Version 4 kernel including security integrated
into the Linux 2.5 development kernel.
Testing of recovery proceeded - Connectathon tests done during reboots
of the server.
See some interesting presentations on NFS Version 4:
http://www.nfsconf.com/pres02/index.html
Tom Talpey asks why is it not a Bakeoff (go to bakeoff.com to find out).
Spencer Shepler then covered the RFC 3010 (NFS Version 4 Protocol
Specification) resubmission status. Completed WG Last call, IETF last
call, IESG approved gave to RFC Editor. IANA will review in process -
they did a pre-review. Next month or so we will here any IANA last
requests for clarifications.
Spencer Shepler then covered replication/migration - standing in for
for Rob Thurlow. As V4 core protocol wrapped up people seem to be
focusing more on the new work. Interested: Sun, IBM, NetApp, UofM.
Replication/migration requirements doc required by December - Pawlowski
has slipped.
Thurlow would like to play with prototype implementations in
Connectathon in March. See slides and Thurlow's draft for proposed
protocol to test. Bring issues to the WG mail list
(nfsv4-wg@sunroof.eng.sun.com).
Shepler thinks the back-end migration/replication protocol will be much
simpler than the core V4 protocol.
Open issues: security, compression/data reduction. There is interest
in low bandwidth links. And - minor version requirements of core
protocol in support of migration/replication - Dvae Noveck wondered
aloud if we would have to tweak something in the core protocol.
Two other big pieces are management and location of replicas.
The location of replicas triggered another possible work item from Dave
Noveck - that of global name space construction and management. The
same facility in V4 as it stands to allow finding file systems that
have migrated (or are replicated) oculd be part of the solution for
construction of a "global name space" (AFS-lite).
Need a problem statement - this needs to be an internet-draft.
Describing the global name space stuff and what are the issues it is
trying to address. (Would need extension to the charter per the Minor
Versions item now there).
Brian discussed the idea of adding a work item for the NFSv4 WG of
NFS/RDDP related issues or protocol changes. This has been touched on
at a prior IETF meeting and on the alias. This type of work fits well
within the NFSv4 WG because of its ownership of the RPC and NFSv4
protocols and relates well to the RDDP (remote direct data placement)
WG efforts. Brian suggests that a subgroup be formed to focus on this
area at first understanding the requirements. Need to also understand
the SNIA NFS/RDMA work and will look to Sun for help in understanding
that work and how it would transfer or relate to this suggested
effort. Brian suggests that this work would fall under minor
versioning work and therefore is included in the current charter.
However, the AD (Scott Bradner) asked that a proposed WG charter change
be made as a first result of this effort. Brian owns an action item to
formalize the overall proposal and discuss via the WG, etc.
With the goal of eventually moving the NFSv4 protocol to Draft
standard, the normative references must also be at Draft standard.
This isn't an issue except for the GSSAPI reference because it is an
API and not a protocol. Therefore, Brian has a submitted a personal
draft that describes how an RFC that describes an API would be moved
forward the IETF standards process. At this point, Mike Eisler pointed
out that GSSAPI really does represent a network protocol and not an API
(even though there are separate RFCs that deal with C and Java language
bindings for GSSAPI). Scott Bradner stated that there has been an
issue in the past within the IESG about moving the GSSAPI RFC forward.
Mike volunteered to assist in clarifying the issues so that the GSSAPI
specification can be moved to Draft status. It was noted that the
NFSv4 protocol does not rely on the language bindings for GSSAPI.
The next topic briefly covered the SNMP MIB resurrection. Again, a
sub-group should be formed to resubmit the expired personal draft that
existed in the past. Again, Brian owns an action to send email to the
WG to start this work.
The RPC/XDR/Security RFCs that are normative references must be updates
for appropriate IANA sections. It was noted that RFC2203 (RPCSEC_GSS
protocol specification) is dependent on the GSSAPI issue notes above.
This will be an additional work item.
During the open discussion, there were comments about minor revision
suggestions. Dave Noveck mentioned that since file delegation support
was present in the NFSv4 protocol that it seemed appropriate to
consider adding support for the delegation of directories. There seems
to be interest and use for such a mechanism. Dave also suggested that
it may be useful to enable the client to reestablish a delegation after
recall and that this may also be a reasonable minor version item. It
was also suggested that providing this type of functionality may enable
the ability to support NFSv4 proxy caching.
Brian clarified with Scott Bradner if this type of work fell within the
current NFSv4 WG charter (since it covers minor version work) and Scott
responded in the affirmative.
Dave stated that since the necessary changes for this type of
delegation should be straightforward that once the requirements are in
place that it should be simple to test this type of functionality in a
bakeathon environment
As mentioned before, Brian would like to pursue moving the NFSv4
protocol from Proposed to Draft. Since this work can be significant,
Brian wanted to clarify that this was a reasonable thing for the WG to
pursue. (implementation reports, etc.)
Tom Talpey asked if Connectathon 2003 will be used as a benchmark for
the move of NFSv4 to Draft and the answer was "no". 6 month minimum is
required to move from Proposed to Draft and since there are still
interesting features that have yet to be implemented that it will be
longer than that.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:38 AM Z CST