Subject: Final comments on recharter of work group

From: Brian Pawlowski <[email-masked]>
Date: Mon, 6 Aug 2001 06:26:53 -0700 (PDT)

Last comments requested before recharter.  Several people have been
involved with implementation and evaluation of RFC 3010 and
certainly have not wanted to detract from that focus.

Say yes or no for the new charter - I'll be asking same question in our
working group meeting in London shortly.

-----------------------------------------------------------------------

There has been some discussion within the workgroup and with
our area directors about future directions for the workgroup.
Some obvious work was left undone (back-end protocol for
migrtion/replication), others have been discussed recently
on the WG alias.

The feedback we got from "the IETF" was to pursue a recharter
of the existing working group to pursue additional activities
in the future.

Below is a stab at a new charter for the working group - comments
are requested.

The last item on minor versioning is weak.  Mark Wittle put forth
some suggestions for possible areas where minor versioning can
be used to enhance the the current specification.  I suspect as
people review RFC 3010, that certain limitations in the protocol
may lend themselves to fixing via a minor rev.  I just can't
convince myself how to put this down.  It may be that specific
proposals for content of a minor revision will be dealt with
as another recharter effort.

Roughly, the working group needs to reach consensus on
a new charter and submit it to the IESG (I believe) for review
and comment.  I have not thought hard on the exact timing.

What I want now are comments from you:-)

beepy

----------- proposed new charter for NFS V4 WG ----------

   Description of Working Group:

   The objective of this working group is to advance the state of NFS
   technology by producing specifications to extend the original NFS
   Version 4 work (RFC 3010) to provide additional capabilities.

   o NFS version 4

   Advance the protocol along the standards track, coordinating the
   development of test suites to provide a high level of implementation
   quality. The ONCRPC standards that NFSv4 references must also be
   advanced. This includes work to make NFSv4 and the underlying ONCRPC
   protocol compatible with IPv6.

   o Replication and Migration

   The original working group defined a mechanism for NFS clients and
   servers to support replication and migration of data transparently
   to an application.  Left undefined in the initial work was the
   server back end migration and replication mechanism.  A
   heterogeneous common solution is desirable for maximum
   interoperability in a variety of configurations. This work will
   focus on the protocols needed to create and maintain replicated
   filesystems as well as migrating filesystems from one location to
   another.

   o Management

   Work is needed to provide better management and administration
   capabilities for NFS via a management MIB.

   o Minor Versions

   NFS Version 4 contains within it the capability for minor
   versioning. Some discussions within the working group suggest
   addressing additional requirements over the original charter.  The
   WG will work to identify additional requirements for NFSv4 and
   determine if they are appropriate and worthwhile for a minor
   version.  This work may lead to additional work items and if they do
   the charter of the WG will be revisited.

----- End of forwarded message from beepy -----

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 06 Aug 2001 10:25:16 -0400

>   capabilities for NFS via a management MIB.

The WG shall consider undertaking development of MIBs for
NFS and for related protocols (e.g. ONC RPC).  Any MIBs
developed will be modular rather than monolithic (e.g. 
any NFS MIB will be separate from any ONC RPC MIB, so that 
someone using ONC RPC but not NFS can still gain value 
from the work).

I'd also like to see any re-charter stress the importance of
not breaking interoperability with the installed base of
pre-NFSv4 implementations and also stress the WG's need to more
seriously consider the operational implications of the protocol
changes and additions.  This WG has had a real tendency of late
for "feature creep" with a result that the current protocol is
extremely difficult to deploy and maintain operationally.  Continuing
the current approach creates real incentives for users to NOT
deploy NFS (or to un-deploy NFS) and instead deploy SMB/CIFS or AFS 
(on grounds of operational simplicity of either of the latter
protocols as compared with current NFSv4).  This is a bit of a
heretical view among the protocol designers, but I'm speaking
as one of the (very) few actual users/operators that participate
in the NFS WG.  Frankly put, I do NOT want any more features.
I want a protocol spec that is stable and I want more focus on 
operational considerations.  I know I'm not alone in this in
the user/operator community.

Yours,

Ran
[email-masked]