Re: [nfsv4] AD review: draft-ietf-nfsv4-minorversion1-24

["Mike Eisler" <mre-ietf at eisler.com>]

-25 of the i-d has been pushed in response to the AD Review. Comments
inline.

On Wed, August 13, 2008 6:39 pm, ext Lars Eggert wrote:

> Section 2.2.1.1.1.1., paragraph 3:
>  > NFSv4.1 client and servers MUST support RPCSEC_GSS's integrity and
authentication service.  NFSv4.1 servers MUST support RPCSEC_GSS's privacy
service.
>
>    So there is no requirement or at least a recommendation for clients
> to
>    implement the privacy service? We should discuss this with the
security folks - my impression was that privacy needs to be a
MUST-implement-need-not-use feature. (But I may be wrong.)

If privacy is now REQUIRED in Standards Track RFCs, it is a new
requirement since NFSv4.0 (RFC3530). I agree it should
at least be RECOMMENDED, and so I added the corresponding sentence.

>
>
> Section 2.7., paragraph 2:
>  > The base assumption with respect to minor versioning is that any
future accepted minor version must follow the IETF process and be
documented in a standards track RFC.  Therefore, each minor version number
will correspond to an RFC.
>
>    This procedure means that the NFSv4 WG will continue to produce
"monolithic" RFCs that specify an entire minor version in one
document. I'd like to at least allow (maybe even recommend) that an NFS
minor version may be described in a set of interrelated RFCs.

I now say:
  Therefore, each minor version
  number will correspond to one or more new RFCs.

which I think succinctly captures the concerns each of you and Dave Noveck
raised without getting speculative about a 2000 page specification striped
 (pun not intended) across 20 RFCs. :-)

> Section 2.10.4., paragraph 1:
>  > Trunking is the use of multiple connections between a client and
server in order to increase the speed of data transfer.  NFSv4.1
supports two types of trunking: session trunking and client ID
trunking.  NFSv4.1 servers MUST support trunking.
>
>    Must support both types of trunking?

Good point. I suggest:

     NFSv4.1
     repliers and requesters MUST support session trunking.
     NFSv4.1 servers MAY support client ID trunking.
     NFSv4.1 clients MUST support client ID trunking.

The reasoning for client ID trunking being OPTIONAL on the server
is that some server architectures won't need it. The reasoning for client
ID trunking being REQUIRED by the client is that if it encounters client
ID trunking, there's not much the client can do about it, other than
support it. The reasoning for replies and requesters supporting session
trunking is that it is unavoidable to support exactly once semantics and
not have multiple connections. E.g. the requester thinks a connection is
dropped, and uses a second to retry a request, but the replier thinks both
connections exist.

> Section 3.3.9., paragraph 0:
>  > 3.3.9.  netaddr4
>
>    Does anything in this section change now that we have
>    draft-ietf-nfsv4-rpc-netid? Should this new document be cited
somewhere?

Most of this section can now be deleted and will now cite to -netid.

> Section 5.8.2.15., paragraph 1:
>  > True, if the file is considered hidden with respect to the Windows
API.
>
>    Is this really a Windows-only attribute? No other OS has this? If so,
does it make sense to REQUIRE it? (Same comment aplies to "system".)

In -24, "hidden" and "system" are listed under the RECOMMENDED attributes.
I did not find any thing that said they were REQUIRED.


>
> Section 9., paragraph 1:
>  > To support Win32 share reservations it is necessary to provide
operations which atomically open or create files.  Having a separate
share/unshare operation would not allow correct implementation of the
Win32 OpenFile API.  In order to correctly implement share semantics, the
previous NFS protocol mechanisms used when a file is opened or created
(LOOKUP, CREATE, ACCESS) need to be replaced.  The NFSv4.1 protocol
defines an OPEN operation which is capable of atomically
looking up, creating, and locking a file on the server.
>
>    Is this really only Windows? I thought Unix (at least BSD) had
> similar
>    flags for open(), i.e., O_CREAT|O_EXCL|O_EXLOCK.

I've never heard of O_EXLOCK until now, but from what I can tell from
search engines, O_EXLOCK is similar but not the same as share
reservations. For example, I believe if process 1 does:
open(, O_RDWR|O_EXLOCK) and process 2 does open(, O_RDWR)
both processes are allowed to proceed. Whereas with share reservations,
the deny modes (if specified) would prevent both from proceeding.

In any case, no one asked for O_EXLOCK/O_SHLOCK semantics in NFSv4.0 or
v4.1, so it was work the WG never took on.

> Section 12.9., paragraph 4:
>  > Where communication with storage devices is subject to the same
threats as client to metadata server communication, the protocols
used for that communication need to provide security mechanisms as strong
as or no weaker than those available via RPSEC_GSS for
NFSv4.1.
>
>    Where would these security mechanisms for the various storage
protocols be specified? Is the intent here to require that there'd be a
new RFC that describes how a new storage protocol integrates into pNFS?
(Also, nit: s/RPSEC_GSS/RPCSEC_GSS/)

Added:

  Except for the storage protocol used for the LAYOUT4_NFSV4_1_FILES
layout (see <xref target="file_layout_type"/>), i.e. except for NFSv4.1,
it is beyond the scope of this document to specify the security
mechanisms
  for storage access protocols.

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

You bring up an interesting point, and when you and/or the sec AD review the
blocks and objects layout specifications (which are separate documents),
the question to decide is if the storage protocols are sufficiently
secure.




>
>
> Section 22., paragraph 0:
>  > 22.  IANA Considerations
>
>    This section requires some work. Keep in mind that IANA will (mostly)
only look at the subsections here to create new registries, i.e., all
information needed by IANA to do so needs to be included here.
Currently, that's not the case at least for some registries.

I reworked it.



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







_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4