Subject: [nfsv4] comments on draft-ietf-nfsv4-rfc1831bis-08.txt

From: "Mike Eisler" <[email-masked]>
Date: Sat, 24 May 2008 18:35:30 -0700 (PDT)

The RPC protocol does not care how a
 message is passed from one process to another,
 but only with specification and
 interpretation of messages.

Reads awkwardly. Perhaps:

 The scope of the definition of the RPC protocol
 excludes how a
 message is passed from one process to another,
 and includes only the specification and
 interpretation of messages.

  More information on specific
  authentication protocols is in
  section 9: "Authentication Protocols".

Section 9 is:

  9. The RPC Message Protocol

Perhaps:
  8.2. Authentication

was intended.

   the first implementation would most likely have the version
   number 1

Perhaps add:

   but MUST NOT be the number zero.

  8.2. Authentication

I suggest:

  8.2. Authentication, Integrity, and Privacy

Then add to the section:

  As demonstrated by  RPCSEC_GSS, it is
  possible for an "auth_flavor" to also
  support integrity and privacy.

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

  (Section 9 defines the
   various authentication protocols.)

No it doesn't.

                      0                Reserved
                      1 - 0x1fffffff   To be assigned by IANA

Mixing decimal and hexadecimal is bad form.
So s/0/0x00000000/ s/1/0x00000001/

             * kerberos errors

Sugggest instead:

             * AUTH_KERB errors; deprecated. See [RFC2695]

   GSS related errors

  rpcvers must be equal

suggest s/must/MUST/

   it must be available in all implementations

s/must/MUST/

   recommended that implementors include AUTH_SYS

   It is strongly
   recommended that implementors include AUTH_SYS in their
   implementations to promote interoperability, since many applications
   make use of this flavor.

Disagree, since RPCSEC_GSS is now on all major
platforms. I suggest:

   Implementors MAY include AUTH_SYS in their
   implementations.

   The RPC
   Language is an extension to the XDR language, with the addition of
   "program", "procedure", and "version" declarations.

Add:

   The keywords  "program" and "version"
   are reserved in the RPC Language, and
   implementations of XDR compilers MAY
   reserve these keywords even when provided pure XDR, non-RPC,
   descriptions.

   The RPC language is identical to the XDR language defined in RFC
   1014

s/1014/4506/

  performed by Sun Microsystems, Inc.

 s/Inc./Inc. (Sun)./

  inappropriate for an IETF standard protocol

 s/standard/standards track/

The table in 13.3 looks just like the table
in 8.3. So suggested deleting the table in 13.3,
and changing:

  Future IANA practice should deal with the
  following partitioning of
  the 32-bit number space:

to:

  Future IANA practice should deal with the
  partitioning of the 32-bit number space as
  listed in Section 8.3.

change:

  Detailed information for the administration
  of these blocks is given
  below.

to:

  Detailed information for the administration
  of the partitioned blocks in Section 8.3. is
  given below.

---------

  Existing pseudo-flavors
   have been granted in the decimal range 390000-390255 as described in
   2.2.

There is no section 2.2.

   'standards-track'

at least one other place used

   Standards Track

Be consistent.

     For authentication flavors to be used on
     the Internet, it is strongly advised that
     an informational or standards-track RFC
     be published describing the authentication
     mechanism behaviour and parameters.

We should discourage standards-track RFCs for
new auth_flavors. Perhaps this sentence
should be added:

     Note: at this time new standards-track
     RFCs for new auth_flavors are discouraged.

---

change:

   Use
   of AUTH_SYS is not recommended for services
   which permit clients to
   modify data.

to:

  AUTH_SYS SHOULD NOT be used for services
   which permit clients to
   modify data. AUTH_SYS MUST NOT be specified
   as RECOMMENDED or REQUIRED for any standards-track
  RPC service.

Suggest instead:

   RPCSEC_GSS GSS related errors

Add RFC2695 to the Informative References.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4