Network File System (NFS) version 4 Protocol
draft-ietf-nfsv4-rfc3010bis-05

2002-10-31 - note to chairs & editor

(ID was on iesg agenda)

only one other issue came up - if a new version can be submitted
qith the changes alread discussed and addressing the IANA
issues included below we are set to go

------
from the IANA
The IANA has reviewed the following Internet-Draft which is
in Last Call: , and
has the following comments with regards to the publication
of this document:

I have compared RFC 3010 with this document and see that
section 17.2 was added.  I can't find a current IANA registry
for NFS named attributes.  It is possible that one was
never set-up.  Are there any defined values for this registry?
I understand the registrations procedures to be that values
can only be added with publication of an Information RFC.

For the ONC RPC Network Identifiers (netids), are there any
currently defined.  Are these also going to have the same
registration procedures, ie. by Informational RFC only?

The IANA considerations section needs some work to address
the above.  If I have misunderstood anything, please let me
know.

Please respond to the IANA about our concerns with regards to this
document.  Failing to do so may cause delay of the approval and
publication of your document.

2002-10-28 - iesg review comment from smb

Most of these are nits, and can probably be resolved with an RFC
Editor's note.  My concerns about 3.1, 3.2.1.1, and 16 are more
serious, and may require the WG to think about things.

-----

There are seven authors and citations and an acronym in the abstract.

3.1: I'm uneasy about the statement that TCP support is a "SHOULD".
Without it, there's no decent congestion control.  In fact, the
"SHOULD" requirement is in conflict with the previous sentence in
the same paragraph, which mandates congestion control.  (I assume
that the intent is not to mandate SCTP...)

3.2.1.1: DES is the strongest cipher?  At the very least, it should
mention AES or (if necessary) 3DES.  If this is a Kerberos or GSS
issue, this document should say so and make appropriate provisions for
a fix to GSS or Kerberos.

3.4: Where does the Kerberos realm get specified when the Kerberos
principal name nfs/hostname is generated?

5.11: Passing ACLs to the client seems to imply that the client is
going to do at least some of its own access control.  This contrasts
with a model where the server does all access control.  Is the
intent to support both models?

8.1.5: Specify how to do comparisons mod 2^32 -- if nothing else, cite
the algorithm in RFC 793.

8: The complexity caused by locks is sufficient to make me question the
whole concept.  But that's the WG's call, not mine.  I think that I
lost that battle many years ago.  (But I recall the discussion in the
original Ritchie/Thompson paper on Unix about file locks, and why they
didn't exist in Unix...)

11: Is this compatible with other IETF trends in internationalization?
I'm especially concerend about 11.5.

16: I'd like to see some discussion about about the security model of
the client.  In NFS Classic, the client was a machine, not a user, and
it enforced access controls as passed to it by the server.  That caused
problems for PC clients, which weren't trusted.  Which model does NFS 4
support?  Both?  I'd like to see a brief discussion of this topic.

2002-09-20 - note to WG chairs
some mechanical things that need to be fixed in the ID

please take a look at
ftp://ftp.isi.edu/in-notes/rfc-editor/instructions2authors.txt
the following nist are in there

        "Bibliography" should be "References"
        references need to be split into Normative & Non-Normative
        too many authors
        there needs to be a "Changes since RFC 3010" section

can you get the ID revised to address these issues at which time
I can get a last call going