Subject: RE: Proposed charter addition for NFS Version 4 Working Group

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 11 Dec 2002 09:10:28 -0800

This argument, that we should avoid any additions to NFS-v4
because the protocol is too complex, would also apply to
almost any minor versioning work, and the charter already 
includes that.

I do think we should be careful as we add things to avoid
unnecessary complexity and make sure that any additions are
truly needed and designed to be as simple as possible.  If
we can generalize things already in the protocol, and simplify
in the process of adding functionality, that would be great,
but I don't think we can count on that happening in many cases.
The bar for minor versioning additions should be set high in 
terms of need, clarity, and simplicity.  Spencer has also 
mentioned the idea that implementation experience for the
proposed extensions is a good idea (maybe he said a requirement), 
and I think that will help filtering out stuff that is just 
in the wouldn't-it-be-nice category.

As far as the complexity of the existing protocol, let me try
to defend it, without getting defensive.  I believe that the
complexity of the protocol (in terms of pages of spec let's
say) flows from the requirements and that to get something 
significantly simpler, you would need to have signficantly 
reduced requirements.  

NFS-v4 is more complex than NFS-v3 for a number of reasons.  
First, the work of NFS-v4 is accomplished by a suite of 
protocols in the NFS-v3 world: NFS itself, mount, NLM, NSM.  
Even aside from the firewall issues that led us to combine 
those into a single protocol, I think the V4 structure is 
much more desirable.  Having separate protocols for separate
functions only really works when the functions are truly 
separate.  When they relate in complicated ways, you wind up
having to understand all the individual protocols and how they
interact, instead of combining things in a single integrated
protocol.  For example, there are a number of proprietary 
ACL protocols to supplement NFS-v3.  We could have standardized
an ACL protocol and it would be relatively simple, but the
result, having a file access protocol, and a separate ACL
protocol would be anything but simple.  There are a lot of
related areas in a file access protocol and when they are
all combined the result is big.  There isn't really any way to
get around that.

NFS-v4 added a great deal of complexity by amalgamating two
fairly different paradigms of file access: UNIX/NFS and NT/CIFS.
I think the complexity that that choice brings with it is
basically unavoidable.  The question is whether it would be 
better to have two separate file access protocols, one for 
each of these (warring) paradigms.  Each protocol would itself
be simpler than NFS-v4 but that would push the complexity onto
the users and administrators that would have to deal with 
multiple protocols.  Looking back, I think we made the right
decision.  It added complexity to the protocol but there was 
no exponential explosion.  Opinions will differ on whether the
result is too complex. 

The other area (and I believe this has a closer relationship to
the RDDP issue) where the single-protocol approach adds complexity
to NFS-v4 is that v4, while maintaining its function as a file
access protocol in high-bandwidth low-latency (essentially in-
machine-room) environments, was also intended to provide good
performance in high-latency (or even very-high-latency) environments
and that is challenging.  If you had two protocols, each one would
be simpler but the result would be more complex for everybody.
Also, it turns out, that at least in some cases a feature 
motivated by high-latency environments has more general applicability.
While COMPOUND is nothing but a pain in low-latency environment
(my personal opinion, anyway), delegation looks like it has
promise for all environments.  Delegation will be used somewhat
differently in a low-latency environment (and not having it is less
of an issue), but it still is a benefit.  In any case, while trying
to address both sorts of environments in a single protocol (intra-
machine-room high-speed access competitive with local fs's vs.
high-latency internet access where RPC reduction is the overriding
goal) adds some complexity to V4, I believe the decision to do both
in a single protocol is a sound one.  If there were two protocols,
they would have to be very tightly co-ordinated (e.g. possiblity of
them drifting semantically apart eventually into outright incompati-
bility with consequent user distress), and that would bring its own 
problems.

So while NFS-v4 is more complex than I'd like, my view is that the 
complexity derives from the mission it was set, which is to be the 
single IETF file access protocol covering Windows and Unix use, in 
machine-room and high-latency environments.  It may be that we made 
some sort of major mistake and could meet all the goals with a 
significantly simpler protocol, but  I don't see how.  I'm sure 
we made mistakes and things could have been done better in some 
areas, but overall the result is not one I'm all that dissatisfied 
with.

The above is relevant to the RDDP issue in the following way.  We 
have a situation is which we have another similar choice of having 
a single protocol or having two protocols that are similar but not 
the same.  We have a situation in which, because of a number of a 
related developments, we again have the issue of whether NFS-v4 
can span such a wide range of use, with the range getting wider.  
There will be some additional  complexity in V4 if it adapts to the 
wider range of use, but the alternative, a separate protocol, is 
less desirable.

Basically 10 Gig-e is coming, whether around the corner or down the road.
There has been some debate about what the implications of that are.  It
basicaly pitted those who felt that this requires some conceptual change
in underlying protocols (i.e. RDMA), vs. those who thought that that could 
and should be avoided.  I don't want to rehash all that.  However, the result
was the formation of the RDDP group to produce an IP network protocol that 
provides those very facilitities to allow data copies to be avoided when 
receiving data from the network.  At 10 Gb/s, copying data is a big big 
waste in CPU time and memory bus banddith.  You wind up not doing much else.

So as to the question of the need for this (the NFS-v4 RDDP work), it turns 
on the question of the need for very high-speed file access over IP, equivalent 
to fs's on traditional direct-connected disk.  While you can argue that 
nobody truly *needs* to access files at 1 Gbyte/s over IP, people are going 
to want to do that and they will.  The question is how.

Here are some possibilities:

     a) The IETF charters a separate working group to provide a protocol (a ULP
        over RDDP) to address this need.

     b) The IETF says that while RDDP is a good thing to avoid data copies for 
        other uses, people using NFS-v4 (and thus IP file access in general) 
        should just shut up and copy the bytes.  Leading to either,

          b1) People develop (outside the IETF) a new protocol that allows 
              zero-copy file access.

          b2) People develop (outside the IETF) various modifications to V4
              so that RDDP can be used.  Those modifications could be to V4
              itself to protocols under V4 (RPC or XDR).

     c) The IETF includes this work in the v4 charter. Leading to either,

          c1) Some reasonable adaptation of NFS-v4 to the issues of such high-speed
              access using RDDP, leading to some modest manageable increment to 
              the scope of V4 and thus its complexity (in terms of pages of spec).
 
          c2) Failure to deal with the expanded requirements without an unavoidable
              massive increase in protocol complexity.

It seems to me that a) is not going to happen, and that while the various flavors
of b) are possible (and the various sub-flavors of b) are activities that started 
before RDDP was chartered and are continuing), c) is the most desirable.  The IETF
is defining an RDMA protocol and has a file access protocol and doesn't want more
than one, so it makes sense for that file access protocol to be able to use the
RDMA protocol since file access is something that people want to run at high speed.
When high-speed is defined as 1 Gbyte/s, they are going to want that and they are
going to need RDDP support to provide it.

I belive the result will be c1), but if it turns out to be c2), then I think we 
will have a basis to ask the IESG to reconsider a).  I think b) would be a bad
choice.  It's not that the results of b1) or b2) would necessarily be bad, but
it would be difficult for everybody to agree on an approach, and maintain
compatibility.  With decision c), the working group would take on this work
and would, I think, do a good job.  Famous last words, I know. :-) 

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Tuesday, December 10, 2002 4:03 PM
To: Brian Pawlowski
Cc: [email-masked]
Subject: Re: Proposed charter addition for NFS Version 4 Working Group

On Tuesday, Dec 10, 2002, at 13:14 America/Montreal, Brian Pawlowski 
wrote:

> Per AD request the meeting in Atlanta (working on minutes now), I have
> attached proposed text to add to charter of the NFS Version 4 working
> group to include work related to the RDDP work recently started at the
> IETF:

I would say that we should not add this to our charter.
It would lead to more complexity in NFSv4 that we don't need
to have (on a protocol spec that some of us already consider
too complex).

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 11 Dec 2002 13:50:47 -0500

On Wednesday, Dec 11, 2002, at 12:10 America/Montreal, Noveck, Dave 

> almost any minor versioning work, and the charter already

Yes.  And please lets not make a bad situation worse.

> significantly simpler, you would need to have signficantly

I question whether the intent of the charter was to change NFS
from a UNIX/POSIX-centric file system model to a super-generic
file system model (e.g. one that is designed for a widely used
proprietary file system).  And that's a long standing doubt of mine,
not something new.

> fairly different paradigms of file access: UNIX/NFS and NT/CIFS.

This was a big mistake.  All the major NFS server vendors dealt
with that issue by offering both NFS service and NTFS service
(separately, but using the same backend storage).  That latter
approach is both widely successful and a better strategy than
trying to build a Ginzu knife protocol, IMNVHO.

>  Each protocol would itself
> multiple protocols.

As a user and administrator, NFSv4 has not bought me *anything*
in the way of simplicity.  I've already got to deal with both
NTFS and NFSv3.  NFSv4 increases my complexity with no substantive
benefits to me as a user or administrator.  This isn't the first
time I've said this, and I think I might be the only user or 
administrator
in this WG, but the WG is pretty consistent in picking complexity
over simplicity.  Simplicity and ships-in-the-night filesystems
would make my life a lot better.

> and that is challenging.

NFSv3 is doing a fine job of both for me.  Any my machine room is loaded
with high-capacity/low-latency GigE links since we make IP/GigE
switch/routers.  I don't see how folks can substantively argue against
an existence proof, which is what I have.

> to fs's on traditional direct-connected disk.

A neat trick is how you re-defined the problem so that operator/user
considerations were taken out of the equation.  I'd say that the 
operator/user
needs to be able to deploy/operate this thing successfully are a lot 
more
important than a hypothetical concern about high-performance situations.
And I don't agree with your analysis of the issue.

I also don't think that IETF needs to standardise zero-copy 
implementation
methods.  It did not need to do so with TCP.  It does not need to do so 
now.
Clever implementers will figure out a way to minimise those costs.  Less
clever implementers might not.  Either way, the protocol doesn't need 
to change.

Ran
[email-masked]

---

From: Robert Thurlow <[email-masked]>
Date: Wed, 11 Dec 2002 13:16:30 -0700 (MST)

> proprietary file system).

One of the intents of the charter is clearly to accomodate
non-Posix filesystems, and especially those originating in
Redmond, WA.  Older versions of NFS specified things that
were not easy (or even completely correct) to do on those
platforms.  Whether you like it or not, that was one of our
key goals.

> benefits to me as a user or administrator.

NFSv4 has reduced complexity in some cases - now all stuff
related to NFS can be firewalled or snooped on port 2049,
rather than having mountd and lockd and statd use some
other, possibly variable, port.  This should matter to you
when you're trying to debug things.  Also, when you want to
implement strong security, you should be able to do so
without getting a bunch of mea culpas from different vendors.

If you ding us for revising the protocol at all, I can't help
you; another version has to introduce some confusion when it
is first being implemented.  The point is that we have a charter
to produce a better NFS, and we hope that eventually it will be
seen as superior to NFSv3.  At that point, your life should be
better.  I hope you're here to help us get to that point.

Another question for you, Ran - do you think that, say, the
mount command will be bristling with options for NFSv4?  In
looking at our implementation, we simply don't have much that
an administrator needs to mess with (and some of what's there
is cover-your-butt stuff that won't be necessary when we work
out some bugs).  Or are your worries mostly that it will be a
pain to deal with buggy implementations?  You talk about the
needs of the operator and user, but not specifically enough
for me to understand the problems you think you see.

> implementation methods.

If you don't find that existing NFS systems fail to be able to
take advantage of 10Gb and higher links, that would be contrary
to what we're seeing.  It seems impossible to do significantly
better without smarter NICs and at least some over-the-wire
information; I'm convinced from reading the RDDP materials.
That will likely not impact the NFS protocol at all, and should
have a relatively small and well-understood effect on NFS
implementations.  So I actually don't understand why this has
triggered your complexity alarm.

Rob T

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 11 Dec 2002 17:23:55 -0500

On Wednesday, Dec 11, 2002, at 15:16 America/Montreal, Robert Thurlow 

> platforms.  Whether you like it or not, that was one of our

There are (and were) a number of NFSv{2,3} clients for that other
operating system.  They do (and have) worked just fine.

This was fixing something that was not an operator or user
problem -- and evidently it wasn't a show-stopper for implementers
because successful implementations existed from several sources.

> other, possibly variable, port.

I don't (and would not) run NFS through a firewall, except
maybe as part of an IPsec tunnel originating on the remote
system and terminating on the interior of a combined (firewall
+ VPN) widget.

No doubt you can find at least one person who either runs NFS
through a firewall or thinks they want to.  I don't think it
is very common (or a very wise operational practice).

> You talk about the

One of those needs is interoperability.  Anything that changes
reduces interoperability.  Even today, I have some interoperability
issues with NFSv3, though there are fewer now than several years back.

Another need is stability.  Anything that changes reduces stability,
at least in the software world of the past and (at least near-term)
future.

> triggered your complexity alarm.

If you've been watching for a while, the "mission creep" here
in the NFS WG triggers my complexity concerns each time I detect
it.  In the Navy, "mission creep" is generally considered a bad
thing by all involved, including those whose mission creeps.

 From where I sit, NFS looks a great deal like many other IETF WGs
these days -- protocol designers and implementers who keep creating work
for themselves and are not sufficiently in touch with real end-users
and operational considerations.  This isn't a comment on you
personally, but rather on the overall tendency of this WG (and
many many others) over the past several years.

Now if you really think that the NFS protocol need not be impacted,
that is modest good news.  And could we then please FIX the proposed
charter revision text to at least explicitly prohibit changing the NFS
protocol as part of the latest round of mission creep ?

Ran
[email-masked]

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 12 Dec 2002 09:21:48 -0500

At 01:50 PM 12/11/2002, RJ Atkinson wrote:
<snip>
>clever implementers might not.  Either way, the protocol doesn't need 

So I take it you disagree with the RDDP WG's Problem Statement
<http://www.ietf.org/internet-drafts/draft-romanow-rdma-over-ip-problem-statement-01.txt>*

In fact, bcopy has become more painful over the years, rather
than less. And in fact, RDMA is the "clever implementer's"
solution of choice. The Problem Statement was key in establishing
this, resulting the chartering of the RDDP Working Group itself.

The NFSv4 protocol most definitely needs to become aware of
RDMA in order to make use of it. I, and others, believe that this
involves relatively straightforward, perhaps even minor, changes.

In any case, I do not believe a perceived complexity should
be the razor by which the NFSv4 WG rejects new work. If we
relegate NFSv4 to the dustbin of complicated machinery,
well, we know where that puts it.

RDMA and 10GbE is the best kind of new goal.

Tom.

*) This is being republished as "draft-ietf-rddp-problem-statement-00"
as it has been accepted as an official RDDP WG document.

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 12 Dec 2002 11:03:27 -0800

Talpey, Thomas wrote:
<snip>
> involves relatively straightforward, perhaps even minor, changes.

Yes indeed.  At Sun we have Solaris NFS running over RDMA (Emulex GN9000/VI)
with full TCP/IP offload and utilizing RDMA direct data placement.
There was a presentation at the recent NFS Industry Conference that
describes this:

	http://www.nfsconf.com/pres02/callaghan.pdf

The changes to support RDMA were needed only at the RPC layer.
There were no changes to the NFS code.  We haven't tried NFSv4
with it yet - but it should "just work".

> RDMA and 10GbE is the best kind of new goal.

and an opportunity!

	Brent

---

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Dec 2002 12:32:08 -0800

> would make my life a lot better.

Removing the NLM and Status Monitor protocols and
including equivalent (actually superior) functionality in the
core protocol should make the lives of users and administrators
simpler, barring the inevitable coding problems. We could
have made the locking protocol simpler, but then it would
have been as faulty and NLM/SM.

If you don't use locking (and real authentication,
ACLs, i18n, file streams, simultaneous UNIX/Windows
access to the same files, pre-epoch file
times, etc.), then I agree, NFSv4 buys  you personally nothing, and due to
implementation bugs, might initially be a step back. I'm a non-fan
of  file locking (an idea that Berkeley, Redmond, and
Summit should have resisted), but that genie is out of the
bottle, and it is time for a file access protocol that
does a proper job of support for locking.

You can ignore NFSv4's enhancements until NFSv3 goes away
(not for a long time I fear). When that day comes, I expect
NFSv4 implementations to be as solid as NFSv3
implementations are today, especially for the limited set of
functions you need.
Summit, NJ should have tried harder to resist ), but I recognize as an
NFS developer that users want and expect it, and
if NFS doesn't provide it, users will invent other
schemes above NFS, and those schemes won't work.

I don't think NFSv3 is going away soon though, so you are
free to ignore NFSv4 for several years, by which time the few
functions in NFSv4 that you do need ought to be available
in products as solid as your NFSv3 implementations.

 > methods.  It did not need to do so with TCP.  It does not need to do
 > so now.

It sounds like you need to make these arguments in the RDDP wg.

 > clever implementers might not.  Either way, the protocol doesn't need

The worst case scenario:

If the RDDP wg and Transport Area directorate are wrong, then
we will surely see NFSv4 (and other ULPs) implementations
that perform well on 10G over pure TCP. Those implementations
will win, and RDDP will be yet another protocol that no one uses.

Perhaps the charter should make it clear that any  extensions to NFSv4 to
use direct data placement should not be required to use other unrelated
extensions. I'm certainly approaching v4.1 with that constraint.

    -mre

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 12 Dec 2002 14:31:56 -0700 (MST)

> > Redmond, WA.

> operating system.  They do (and have) worked just fine.

They worked okay, after a LOT of work and fudging on the
part of the implementors.  I wonder if there are still not
some corner cases that can't work with V2/V3.  What I know
is that NFS-on-Windows vendors participated enthusiastically
in helping define the parts of NFSv4 that have moved us away
from POSIX, and if they had all the answers for NFS on
Windows, I don't see why they would have done this.

Remember that implementors get support calls from plenty
of admins and users, and may see problems you don't.

> is very common (or a very wise operational practice).

I think this could enable some good things, e.g. direct work
on CVS source trees on open-source projects.  Security concerns
have always been a reason to not do this in the past, followed
by performance concerns.  We have more than a stab at solving
both of these with V4, so I think your dismissal out-of-hand
is short-sighted.

> [on the needs of the operator/user:]

If change is the enemy, I can't help you.  We're making these
changes because we have a charter to do so and consensus on
what the changes are, and we hope to arrive at a better place.
Change is about cost/benefit, and the problem I have with your
feedback is that you seem to neglect all benefit, which means
that no change can ever be justified.

> protocol as part of the latest round of mission creep ?

Prototyping of smart-NIC performance work at Sun has not made
*ANY* interesting changes to our NFS implementation, never
mind to the protocol.  However, if changes in a minor revision
are suggested THAT JUSTIFY THEIR COSTS, we need to be able to
consider them.  At this point in NFSv4 deployment, we can get
small changes into implementations without serious impact.  As
for the basic NFSv4 protocol, the ship has sailed - we will not
add things except through the minor revisioning process.

Rob T

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 16:41:58 -0500

On Thursday, Dec 12, 2002, at 14:03 America/Montreal, Brent Callaghan 
> with it yet - but it should "just work".

OK, so there is implementation experience that RPC is the only thing
that needs changed.  Could we please at least write the charter
modification text to limit potential damage (I mean, changes) to
the RPC layer ?

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 16:40:01 -0500

On Thursday, Dec 12, 2002, at 09:21 America/Montreal, Talpey, Thomas 
wrote:
> solution of choice.

I'm not at all convinced of that.  I'm not an NFS implementer,
but I've done a fair bit of kernel programming in my time.
And I know that folks at (various places) have managed to do
things like Zero-copy TCP without having to change the protocol

If the assumption is that one is going to have "special" NIC
cards, I'd suggest (based on experience) that it would be
entirely feasible to build an NFS-accelerated NIC card without
changing anything.  FPGAs can have a lot of gates these days
and are reasonably fast -- and one could go to an ASIC if one
needed to.

Certainly I don't buy very much technical hype on any front,
whether RDMA or XML-as-panacea.

> involves relatively straightforward, perhaps even minor, changes.

If they are so straight-forward and minor, then the proposed
charter language (at least) should be narrowed down to the minimal
set that are believed needed.  Part of how we got where we are
with complexity is that the NFSv4 charter was broadly and vaguely
worded in a way that failed to scope the WG activity appropriately.

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 16:47:15 -0500

On Thursday, Dec 12, 2002, at 15:32 America/Montreal, Mike Eisler wrote:
> implementation bugs, might initially be a step back.

"simultaneous UNIX/windows access to the same files" has been
available without NFSv4 for a good while now -- via Samba on
some platforms, via integrated NTFS service on others.

So that's just marketing hype.

And I don't see any NFSv4 clients being integrated by Redmond,
so NFSv4 isn't adding any value on that front.

Because of the different ways that i18n filenames are implemented
on different systems, they are problematic regardless of NFSv4
(sad, but true).

ACLs are pretty optional in my world, since I know how to use
UNIX groups and since my experience is that the existence of AFS ACLs
confuses most UNIX users.

> I'm a non-fan of  file locking (an idea that Berkeley, Redmond, and

Locking is nice, but we've gotten by without real locking for years now.

> will win, and RDDP will be yet another protocol that no one uses.

Maybe.  I am loath to under-estimate the power of marketing hype,
having been burned in the past.  And RDDP definitely has lots of
marketing hype right now.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Dec 2002 16:53:39 -0500

On Thursday, Dec 12, 2002, at 16:31 America/Montreal, Robert Thurlow 
wrote:
>  We're making these

It really scares me that anyone uses the charter permitting the
work as the justification for the doing the work.  By this reasoning,
if I'm permitted to walk off a cliff, therefore I must do so
and hope to arrive at a better place.

> that no change can ever be justified.

No.  I'm suggesting that my end-user perspective on "benefit"
of NFSv4 (and this RDMA gorp) is substantially at variance
from your perspective.

> add things except through the minor revisioning process.

The problem is that what happens in this WG is that the implementers
are the bulk of the voice, so the implementer's views on which costs
are justified are virtually the only views that get considered.
End-user/administrator views are largely not considered, which is
partly due to limited end-user/administrator participation -- which
is a broader issue with IETF than just NFSv4, btw.

I certainly do not believe that MY views on which costs are justifiable
are seriously considered.  And under IETF rules, they CAN safely be
ignored because the metric is "rough consensus of WG participants"
and the bulk of the participants are implementers.

I'm not super-happy about this.  I'm trying to be realistic with
my expectations.

Ran

---

From: Robert Thurlow <[email-masked]>
Date: Thu, 12 Dec 2002 15:13:12 -0700 (MST)

> > RDMA is the "clever implementer's" solution of choice.

> things like Zero-copy TCP without having to change the protocol

I submit that your experience is dated.  With fast enough NICs,
you can't afford to have regular CPUs touch the data at all,
or even to try to do tricks like virtual memory page-flipping.
You want "direct data placement", as the RDDP folks call it.
Otherwise, you have to send too many interrupts to the CPU,
and have to sacrifice too much bus bandwidth to data movement
that could be done much more simply.

Ran, this is increasingly off-topic for this alias; you may
want to tune into the RDDP alias instead to debunk it there.
The IETF has decided that RDDP should be a working group;
assuming that is reasonable, the question before us is, is
it proper for this working group to experiment with RDDP
and discuss changes to our various protocols to make use of
RDDP?  (This working group "owns" RPC, which is where we
expect changes to be made.)

> changing anything.

Yes, we could do that.  But the IETF is interested in solving
RDDP for *ALL* protocols, not just NFS.  So are vendors.

> set that are believed needed.

So why don't you propose concrete changes to the wording in
Brian's original post?

Rob T

---

From: Mike Eisler <[email-masked]>
Date: Thu, 12 Dec 2002 14:27:36 -0800

> some platforms, via integrated NTFS service on others.
Great, where's the open standard for CIFS/SMB, and/or the
change control RFC ceding control of the protocols to ISOC? Without
the actual specification, there's no way Samba and others will
ever be able to get the same degree of protocol conformance
and interoperability that the open standard can achieve.

 > So that's just marketing hype.

The fact is that UNIX NFSv[23] clients and WIndows CIFS clients don't
play as nicely as they can when NFSv4 is introduced to
either the UNIX or Windows side.

> And I don't see any NFSv4 clients being integrated by Redmond,

There are things onMS platforms that NFS does better
than CIFS (e.g. data preservation across recovery
events), and with NFSv4, a huge chunk of the semantic
gap that NFSv3 had with respect to Windows goes away.
There are users today who put up with a non-integrated
client from a third party, and with NFSv4, more users will
have more reasons to do so. That the vast majority of
CIFS users doesn't care or doesn't know about these
reasons is not an excuse for not producing a protocol
for those that do care.

 > so NFSv4 isn't adding any value on that front.

Even if the file access protocol of choice in the Windows
world remains CIFS, that the UNIX file access protocol
will be NFSv4 means when UNIX and Windows will play
more nicely with other. E.g. with a good
multiprotocol server, when a CIFS client opens a file
with a deny share mode, subsequent access by a process on
an NFSv[23] client that opened the file first is summarily
denied. This is good, but what would be better is if the
CIFS client were denied the open. NFSv4 achieves this.

> Locking is nice, but we've gotten by without real locking for years now. 

Locking isn't nice but we'll have to agree to disagree on that.
You and I have been doing without it, but lots of users have not.
If they were doing without, then I, and I'm sure, every other NFS vendor
represented on this alias, wouldn't be dealing with user bug
reports and/or feature requests in the locking area.

    -mre

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 12 Dec 2002 19:09:14 -0500

>modification text to limit potential damage (I mean, changes) to

Huh? _Charter_ an implementation choice??

Tom.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 13 Dec 2002 09:36:06 -0500

On Thursday, Dec 12, 2002, at 19:09 America/Montreal, Talpey, Thomas 

> Huh? _Charter_ an implementation choice??

Many IETF WGs have been chartered with narrow charters permitting
a narrow scope of work (change foo but not bar in order to make
frobnitz work over some new technology).

Folks other than me have agreed that it is feasible to do this
with changes being restricted to the RPC layer, which provides
greater stability to the NFS spec, promotes good modularity,
and should reduce the interoperability impact of changes.

It is pretty commonly done in the IETF.

Ran