Administration Protocol for Federated File Systems
draft-ietf-nfsv4-federated-fs-admin-15

[Ballot discuss]

I hope this is an easy one.

You say that the root cert in a FEDFS_SEC_TLS MUST be used to
validate the NSDB's server certificate, and that's fine.  The
problem is that some implementation might well have an OS-wide
root cert store and install this value in that, with potential
bad effects. Would it be ok to add a statement that the cert
from a FEDFS_SEC_TLS MUST NOT be used for other purposes
if its not already known? That is, we do not want
implementations to take this cert and put it into that kind of
OS-wide store where it could be used for other things, in
particular if its actually just an SSC.

Discussion with the authors ended up with this text:

"
To ensure that this security configuration information does not cause
vulnerabilities for other services, trust anchors provided through
secData MUST only be used for the NSDB service (as opposed to being
installed as system-wide trust anchors for other services).
Most popular TLS libraries provide ways in which this can be
done, for example, see [1].
"

Though [2] might be a better reference for the RFC editor.

[1] http://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html
[2] http://www.rtfm.com/openssl-examples/part1.pdf

If some equivalent wording is added that'll clear this discuss.

[Ballot comment]
I'm sorry to sound like the "RFC 2119 language police" with these
comments.  In my opinion, my comments refer to text whose meaning
(and, therefore interoperability of implementations) depends on the
interpretation of the RFC 2219 language.

In section 4:

  FedFsUuid:  A universally unique identifier (UUID) as described in
      [RFC4122] as a version 4 UUID.  The UUID should be formatted in
      network byte order.

s/should/MUST/ ?

  FedFsNsdbName:  A (hostname, port) pair.
      [...]
      A value of 0 indicates that the standard LDAP port number, 389,
      SHOULD be assumed.

s/SHOULD/MUST/, or explain when 389 is not assumed and what is used
instead of 389.  Why would one set the port to 0 instead of just using
the more direct 389, anyway?  The answer to this question should be
applied in section 4.1.

      [...]Therefore, a FedFsNsdbName SHOULD NOT contain a network address,
      such as an IPv4 or IPv6 address, as this would indefinitely assign
      the network address.

s/SHOULD NOT/MUST NOT/, or explain the syntax for encoding a network
address in a FedFsNsdbName.

  FedFsPathComponent:  A case sensitive UTF-8 string containing a
      filesystem path component.  It SHOULD be prepared using the
      component4 rules defined in Chapter 12 "Internationalization" of
      [3530bis].

When would it not "be prepared using the component4 rules[...]" and
how would that case be identified?

In section 5, some error conditions are specified as "MUST be
returned", some as "SHOULD be returned", some as "MUST fail with
status [...]" and some are not specified with any RFC 2119 language.
At the risk of suggesting foolish consistency, I suggest a editing
pass for consistency, with explanations of what to do if a SHOULD is
not followed, would likely ease the mind of an implementor.  (OK, I
admit this comment is mostly stylistic, except for the clarification
of SHOULDs.)

[Ballot discuss]
Just trying to follow the bread crumbs … The following is in RFC 5531:

Standards Track RPC services MUST mandate support for
RPCSEC_GSS, and
MUST mandate support for an authentication pseudo-flavor with
appropriate levels of security, depending on the need for simple
authentication, integrity (a.k.a. non-repudiation), or data privacy.

In this draft: Use of RPCSEC_GSS is a MUST - so check mark in that box.  Where's the MUST for the authentication psuedo-flavor?

Under what circumstance would you be okay with no integrity protection?

[Ballot discuss]


I hope this is an easy one.

You say that the root cert in a FEDFS_SEC_TLS MUST be used to
validate the NSDB's server certificate, and that's fine.  The
problem is that some implementation might well have an OS-wide
root cert store and install this value in that, with potential
bad effects. Would it be ok to add a statement that the cert
from a FEDFS_SEC_TLS MUST NOT be used for other purposes
if its not already known? That is, we do not want
implementations to take this cert and put it into that kind of
OS-wide store where it could be used for other things, in
particular if its actually just an SSC.

[Ballot comment]
1.1

  Client:  Any client that accesses fileserver data using a supported
      file-access protocol.

I love circular definitions as much as the next guy, but how about at least indicating whether the client is the software, the machine, the user, or some other theoretical entity? The above is not useful.

  Fileserver:  A server exporting one or more filesystems via a file-
      access protocol.

Hmmmm....That's not a terribly helpful definition.

4.  Data Types

  The basic data types defined above MUST be formatted as follows:

The MUST is strange. I always say that you should use MUST if an implementation might accidentally choose to do otherwise and cause an interoperability problem. In this case, choosing to do otherwise is not an accident; it's just insanity. It's probably just as good to say "The basic data types defined above are formatted as follows:". That said:

  FedFsUuid:  A universally unique identifier (UUID) as described in
      [RFC4122] as a version 4 UUID.  The UUID should be formatted in
      network byte order.

There's something weird about the first sentence. The contradiction of the "MUST" above and the "should" here is glaring. Don't you want to say here that the UUID MUST be in network byte order? *That* would cause an interoperability issue, wouldn't it?

      A system (i.e.,
      fileserver or administrative host) SHOULD resolve the fully
      qualified domain name to a network address using the system's
      standard resolution mechanisms.

SHOULD do something that is implementation dependent? That doesn't look right.

      The secType field indicates the security mechanism that MUST be
      used to protect all connections to the NSDB with the connection
      parameters.

      A value of FEDFS_SEC_NONE indicates that no security mechanism is
      necessary.  In this case, the secData array will have 0 length.

There appears to be a conflict in the above. I read the first sentence as saying that whatever is in secType MUST be used; you can not use an alternative. However, the second sentence indicates that no security mechanism is "necessary", implying that you *could* use a security mechanism if you wanted to. Which is it? Do I have to respect what's in secType, or are there instances where I can choose what I like?

[Ballot comment]

  I think that it would be useful to encourage implementers to install
  the trust anchors so that they are scoped to a specific NSDB.  This
  would be much better than using global trust anchors.

[Ballot comment]
I have a few non-blocking comments, most of which have to do with combinations of 2119 key words.  In all of those cases, I'm not *sure* what you want to say.  If you really do want to say what's there, then my comments are wrong.  But if, as I suspect, this is *not* really what you're trying to say, then we should sort out the right text.  Please chat with me about them if that will help.

-- Section 5.2.2 --
  If the path contains an invalid UTF-8 character, then status
  FEDFS_ERR_BADCHAR MUST be returned.

What characters are valid?  When I look at the definition of FEDFS_ERR_BADCHAR, I think you mean "unsupported", rather than "invalid"... yes?  [I'm picking on this because the IDNA specs actually *do* define valid and invalid characters, and you probably don't want to try to mess with that. :-) ]

This also appears in Sections 5.3.2, 5.4.2, 5.5.2, 5.6.2, and 5.7.2.

-- Section 5.5.2 --
  The server SHOULD permit this operation even on read-only filesets,
  but MAY return FEDFS_ERR_ROFS if this is not possible.

You might mean exactly this, in which case it's fine, but this is a SHOULD/MAY construct that's often wrong, so I'm checking.  "SHOULD do X but MAY do Y" is correct if Y is *always* optional.  But more often, this is what's really intended:

  The server SHOULD permit this operation even on read-only filesets,
  but MUST return FEDFS_ERR_ROFS if this is not possible.

Is that the case here?
This also appears in Section 5.6.2.

This one is related:
  The server MAY enforce the local permissions on the path, including
  the final component.  If the path cannot be traversed because of
  insufficient permissions, or the final component is an unexecutable
  or unwritable directory, then the operation MAY fail with status
  FEDFS_ERR_ACCESS.

If you mean this, then the phrasing above is correct:
1. The server MAY enforce local permissions.
2. If it does, then it MAY use FEDFS_ERR_ACCESS to convey failures (but that's entirely optional, and it could use some other code instead).

But if you mean this, then you should re-phrase:
1. The server MAY enforce local permissions.
2. If it does, then it MUST use FEDFS_ERR_ACCESS to convey failures.

This also appears in Sections 5.2.2, 5.3.2, 5.4.2, 5.6.2, and 5.7.2.

-- Section 5.9.2 --
  On failure, an error value indicating the type of error is returned.
  This operation MAY return FEDFS_ERR_NSDB_PARAMS to indicate that
  there are no connection parameters on record for the given NSDB.  The
  operation MAY return FEDFS_ERR_ACCESS if the operation's associated
  user does not have sufficient permissions to view NSDB connection
  parameters.

This is similar to some of the others.  If you mean to say that using those error codes is entirely optional, even under the conditions specified, then this is fine.  But if you mean to say that certain error codes are definitely the ones to use in these situations, then the MAYs are wrong, and you should re-word this.

There are similar situations at the ends of Sections 5.8.2 and 5.10.2.

IANA has reviewed draft-ietf-nfsv4-federated-fs-admin-11 and has the following comments:

IANA has questions about the IANA actions requested in this document.

In the Remote Procedure Call (RPC) Program Numbers registry located at:

http://www.iana.org/assignments/rpc-program-numbers/rpc-program-numbers.xml

the RPC Program Numbers 100418 - 100421 are marked as having
a description/owner of IETF NFSv4 Working Group - FedFS.

Do the authors request that this be changed to 100419 - 100421 and that a new
entry for 100418 be created that has fedfs_admin as the short name? If this is
the case, do the authors request any entry in the Description/Owner field for
the new RPC Program Number 100418?

Should the reference for 100418 be { RFC-to-be ] and the 100419-100421
entry left as RFC5531?

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Administration Protocol for Federated Filesystems) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Administration Protocol for Federated Filesystems'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-06-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the administration protocol for a federated
  file system that enables file access and namespace traversal across
  collections of independently administered fileservers.  The protocol
  specifies a set of interfaces by which fileservers with different
  administrators can form a fileserver federation that provides a
  namespace composed of the filesystems physically hosted on and
  exported by the constituent fileservers.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-admin/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-admin/ballot/


No IPR declarations have been submitted directly on this I-D.

The write-up was not uploaded at the time of publication requested.

Here is the write-up:
Working Group:  NFSv4
Area Director:  David Harrington
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:


draft-ietf-nfsv4-federated-fs-admin-09.txt

Note: as background for this review, please review
"Requirements for Federated File Systems" published as RFC 5716
http://www.rfc-editor.org/rfc/rfc5716.txt

  (1.a) Spencer Shepler (sshepler@microsoft.com) is the document shepherd.
  I have reviewed the document and believe it is ready as an RFC.

  (1.b) This document and the mechanisms it represents have been
  reviewed within and outside of the NFSv4 working group.
The protocol defined in this I-D has been prototyped and
a level of interoperability has already been achieved.

  (1.c) The document shepherd has not identified any further
  review or input as required. 

  (1.d) The document shepherd is comfortable with the contents
  of the I-D and the mechanisms it represents.  What comments
or feedback provided to the document authors have been
in addressed in this or earlier versions.

An IPR disclosure on the FedFS documents has been made.
From the minutes of the last NFSv4 WG meeting:

"US 7,933,921 April 26, 2011, Referent-controlled location
resolution of resources in a federated distributed
system. Royalty-Free, Reasonable and Non-Discriminatory
License to All Implementers. License to be submitted to IETF
per usual process."

No substantive commentary has occurred on the WG alias.
Given the licensing terms presented by Netapp, it is the
expectation of the shepherd that the working group will
NOT take action in response to the disclosure.

  (1.e) There is full NFSv4 working group consensus behind this document.
  There have been no major disagreements for the lifetime of this
document and certainly no outstanding issues.

  (1.f) There have been no discussion of appeal or discontent
  with this I-D.

  (1.g) The document shepherd has reviewd the document with
  the ID nits in mind.

  (1.h) The document has correctly divided references into
  normative and informative groupings.

A normative reference dependency does exist that is
still "in process".  While the normative reference is
correct, it does not block the review and approval of
this document.  The reference is for the RFC3530bis work
currently active within the working group (NFSv4.0).
RFC3530bis is complete and waiting inclusion of 3 edits
and should be ready for shepherding to AD by Sept 2011.

An informative reference dependency exists for the
other FedFS document "draft-ietf-nfsv4-federated-fs-protocol-11"
Thus these two documents need to move together through
the publication process.  These two documents should be
reviewed together to provide appropriate context.

  (1.i) An IANA section does exist and it is appropriate for the I-D.
  No new registries have been defined by this I-D.
 
  (1.j) This document defines an RPC program (RFC5531) using the
  XDR language (RFC4506).  The I-D has been written in a style
that the defined XDR can be automatically extracted from
the I-D and then postprocessed by common "rpcgen" IDL
compilers.  This process has been validated to work
correctly.

  (1.k)

  Technical Summary

    This document describes the administration protocol for a
    federated file system that enables file access and namespace
    traversal across collections of independently administered
    fileservers.  The protocol specifies a set of interfaces by which
    fileservers with different administrators can form a fileserver
    federation that provides a namespace composed of the filesystems
    physically hosted on and exported by the constituent fileservers.

  Working Group Summary

    The FedFS administration protocol as to be used with NFSv4 file servers
    is an important component to providing enterprise usable federated
    NFSv4 file systems.  Combined with the NSDB Protocol for Federated
    Filesystems, and NFSv4 protocols a complete solution is possible
    and provides substantial utility.

  Document Quality

    Not only is the Federated FS Admin document complete, readable and
    useful as a guide to implementation and interoperability, this has
    been proven by at least two prototype implementations that have
    been built by those authoring the document.  This is an important
    culture of the NFSv4 working group and has become the norm of
    behavior for the work product generated by the working group.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Review: draft-ietf-nfsv4-federated-fs-admin-09

Hi

Overall, this document was well-written, although rather terse due to the cut-and-paste nature of the material. Please publish a revised ID to address these issues. Let me know if you disagree with any of the comments.

1) in 3, what does this following sentence mean? Please include a better explanation of the literal codes in the document.
"Many of the error status names and meanings (and the prose for their descriptions) are taken from the specification for NFSv4 [3530bis]. Note, however, that the literal values for the status codes are different. "

FedFsNsdbName: "The port is the NSDB transport port." Different transport protocols might have different ports, so it might be important to identify the transport protocol, not just the port.
There is also no discussion of the fact that LDAP is assumed.

FedFsPath: there is an incomplete sentence in this description.

FEDFS_CREATE_JUNCTION: "If the fileset is read-only, then this operation SHOULD indicate this with a status of FEDFS_ERR_ROFS." why is this only a SHOULD?

lower case "may" and "must" - if these are RFC2119 keywords, please use capitals. If not, then please use different words top avoid any ambiguity. I suggest "might" for "may".

"Note that" is usually superfluous.

Security Considerations is too limiuted. At a minimum, the discussion about FEDFS_GET_LIMITED_NSDB_PARAMS should be referenced in the security considerations.

IESG often pushes for expanding acronyms on first use. Having the glossary at the end might cause problems. It would be wiser to move it forward (maybe put "requirements language" as section 1.1, and the glossary as section 1.2).