Re: [secdir] SecDir review of draft-ietf-nfsv4-rfc3530bis-25

[Yoav Nir <[e-mail]>]

On Apr 8, 2013, at 7:55 PM, "Haynes, Tom" <[e-mail]<mailto:[e-mail]>> wrote:

Yoav,

Thanks for the comments. Rather than address them all, I want to
talk about the main ones driving the document.

On Apr 8, 2013, at 3:35 AM, Yoav Nir <[e-mail]<mailto:[e-mail]>>
 wrote:

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: In my opinion, this I-D needs more work.

This is a huge draft. It's on track to become the 3rd biggest RFC behind the security glossary and the NFS 4.1 RFC (5661).


Yes, and the WG has taken pains to make sure we do not do that again.
See for example draft-ietf-nfsv4-minorversion2-19<http://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/> which weighs in at
under 100 pages.

That's good to know.

I've spent more time on this than my previous SECDIR reviews combined, and I still don't think I've done a thorough enough job. This revision splits RFC 3530 in two: this document, and the XDR document. This is the third revision of the NFSv4 spec (after 3530 and 3010). RFC 3010 was published on December 2000, over 12 years ago. It may have been a good idea back then to write the spec as a comparison to previous specifications, but I don't think this makes sense 12 years later. As an example, we need look no further than the Abstract:

  The Network File System (NFS) version 4 is a distributed filesystem
  protocol which owes heritage to NFS protocol version 2, RFC 1094, and
  version 3, RFC 1813.  Unlike earlier versions, the NFS version 4
  protocol supports traditional file access while integrating support
  for file locking and the mount protocol.

And it goes on throughout the document - always a diff from NFS 3. That kind of voice makes sense when addressing a community with significant NFS 3 experience, and little or no NFS 4 experience. Is this still the case?


While some implementors may go straight to NFSv4.1, the path is still NFSv3
to NFSv4.0.

Yes. My question is whether that path has already been traversed. Looking at some vendor sites and Internet forums, it looks like all the major operating systems (Windows, Linux, Mac OS, even IBM's exotic systems) already have NFSv4. I believe the same can be said for storage products such as NetApp. So who are those developers who have existing NFSv3 implementations, and have not yet implemented NFSv4?


The Introduction section does not talk at all about what NFS is and what it could possibly be used for. It's just a series of sections detailing differences from version 3, from 3530, and from 3010. Nowhere does it say why we need a revision of version 4, when version 4.1 is already published.

Valid point and the main one I want to address here.

We have a lot of implementation experience in NFSv4.0 that made its way into NFSv4.1. We still
have many NFSv4 implementations that do not have corresponding NFSv4.1 implementations.

We want to drive back those lessons that do not require protocol changes into the base
document to improve interoperability.

I'll look at how to add that back to the document.

OK. Thanks

Yoav