Skip to main content

Namespace Database (NSDB) Protocol for Federated File Systems
draft-ietf-nfsv4-federated-fs-protocol-15

Revision differences

Document history

Date Rev. By Action
2015-03-18
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-03-06
15 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-02-17
15 (System) RFC Editor state changed to RFC-EDITOR from REF
2015-02-11
15 (System) RFC Editor state changed to REF from EDIT
2014-12-22
15 (System) RFC Editor state changed to EDIT from MISSREF
2013-01-03
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2013-01-02
15 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2012-12-24
15 (System) IANA Action state changed to In Progress from Waiting on Authors
2012-12-24
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-12-21
15 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2012-12-21
15 (System) IANA Action state changed to In Progress
2012-12-21
15 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2012-12-21
15 Amy Vezza IESG has approved the document
2012-12-21
15 Amy Vezza Closed "Approve" ballot
2012-12-21
15 Amy Vezza Ballot approval text was generated
2012-12-21
15 Martin Stiemerling State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2012-12-21
15 Martin Stiemerling Ballot writeup was changed
2012-12-18
15 Martin Stiemerling State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup
2012-12-18
15 Barry Leiba
[Ballot comment]
The -14 version resolves all my earlier comments, and clears my earlier DISCUSS.  Thanks for addressing all this.

The -15 version resolves the …
[Ballot comment]
The -14 version resolves all my earlier comments, and clears my earlier DISCUSS.  Thanks for addressing all this.

The -15 version resolves the late issue that came up with the registry in Section 7.2.  Thanks for that, and, again, my apology that that came up so late.
2012-12-18
15 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-12-12
15 Chuck Lever New version available: draft-ietf-nfsv4-federated-fs-protocol-15.txt
2012-11-29
14 Peter Yee Request for Telechat review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2012-11-29
14 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation
2012-11-29
14 Benoît Claise
[Ballot comment]
My DISCUSS-DISCUSS is now cleared: "While it's not ideal, since you have the LDAP OID experts green light and also running code, I'll …
[Ballot comment]
My DISCUSS-DISCUSS is now cleared: "While it's not ideal, since you have the LDAP OID experts green light and also running code, I'll clear my DISCUSS."

For the record, here was my DISCUSS-DISCUSS
This is a DISCUSS-DISCUSS.

Hopefully a little bit of LDAP education will quickly resolve this one.
I'm looking at section 7.2 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-14#section-7.2, which speaks about OID.
So my OPS AD level of attention suddenly increased.

  ... one of the authors was
  assigned the Internet Private Enterprise Numbers range
  1.3.6.1.4.1.31103.x.  Within this range, the subrange
  1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
  federated file system protocols.

From http://www.iana.org/assignments/enterprise-numbers, I see
31103
  Daniel Ellard
    Daniel Ellard
      ellard&gmail.com

Then I thought: Ok, maybe, even if I read "permanently", this enterprise specific number requested by a specific person was a temporary solution.
However, reading further, yes, there is a new "FedFS Object Identifiers" registry, but it will still use the 1.3.6.1.4.1.31103.1.x range.

Then I looked at existing practice: http://tools.ietf.org/html/rfc4517
And I see, for example:
  The LDAP definition for the Other Mailbox syntax is:
      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

From http://www.iana.org/assignments/enterprise-numbers:
1466
  Mark Wahl
    Mark Wahl
      M.Wahl&isode.com


Is it normal that Standards Track documents register OIDs under enterprise specific numbers (on top of that, representing individuals)?
Is it normal that OIDs are registered this way in LDAP?

Note: I know of one PEN used within a standards track document, but this one was distinctly labeled.
29305
  IPFIX Reverse Information Element Private Enterprise
    RFC5103 Authors
      ipfix-biflow&cert.org


Disclaimer 1: My lack of LDAP is probably the cause of this DISCUSS-DISCUSS. So please shed some light.
Disclaimer 2: I spoke with Martin Stiemerling before posting this.
So I'm really after a reply (from the APPS ADs, I guess) such as: "don't worry, there are no problems with this."
2012-11-29
14 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2012-11-29
14 Sean Turner
[Ballot comment]
1) Had a bunch of questions about the 2119-language, but I see that you got some other comments along the same lines and …
[Ballot comment]
1) Had a bunch of questions about the 2119-language, but I see that you got some other comments along the same lines and caught some others on your own.  Here are the ones I noted, if you already got them great:

s2.7: The FsnUuid is a required attribute - REQUIRED?

s2.7/s2.8 Annotations/Descriptions: r/optional/OPTIONAL? X2

s2.12: r/an FSN UUID must be/an FSN UUID MUST be ?

s2.12: r/FSL UUIDs must be unique/ FSL UUIDs MUST be unique ?

s4.2: r/Code components extracted from this document must include the following license:/Code components extracted from this document MUST include the following license: ?

s4.2.1: r/describes the required/describes the REQUIRED ?

s5.1.5: r/must not/MUST NOT

2) s2.7: Is an NSDB client the same as a file-access client?  Ah now I see NSDB client is defined later in s5 - shouldn't it be listed in s2?  Is an NSDB client just an administrator or a fileserver based on the users of the two sub-protocols in s5 t seems like it is?

3) s4.1: r/NSBD/NSDB

4) s5: There's three sub-sections in s5.  Is the following just a typo?

  The NSDB sub-protocols are defined in the next two sub-sections.

5) s5.1.1: When you say validity and consistency are talking about validating the schema?:

The NSDB node that receives the request SHOULD check all of the
attributes for validity and consistency

6) s5.1.*.1: Nice examples!

7) So do I have it right that the protocols described in this document are only used by fileservers and admins and that a file-access client never needs to implement LDAP?
2012-11-29
14 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-11-29
14 Barry Leiba
[Ballot discuss]
I'm terribly sorry for the late DISCUSS.  I missed this earlier, and only got to it through Benoit's comments.

-- Section 7.2 -- …
[Ballot discuss]
I'm terribly sorry for the late DISCUSS.  I missed this earlier, and only got to it through Benoit's comments.

-- Section 7.2 --
  Future allocations from the 1.3.6.1.4.1.31103.1.x range are to be
  assigned by IANA using the "RFC Required" policy defined in
  [RFC5226].

First, I'd like to know what the justification is for RFC Required.
There's no shortage of code points.  What harm would there be in
allowing more registrations?

But second (or maybe this should be first), why is this registry even
created at all, when the OIDs are registered *again* in Section 7.3,
in the Object Identifier Descriptors registry under LDAP Parameters?
Why do we need two different registries for the same things?
2012-11-29
14 Barry Leiba [Ballot comment]
The -14 version resolves all my earlier comments, and clears my earlier DISCUSS.  Thanks for addressing all this.
2012-11-29
14 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to Discuss from No Objection
2012-11-29
14 Benoît Claise
[Ballot discuss]
This is a DISCUSS-DISCUSS.

Hopefully a little bit of LDAP education will quickly resolve this one.
I'm looking at section 7.2 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-14#section-7.2, …
[Ballot discuss]
This is a DISCUSS-DISCUSS.

Hopefully a little bit of LDAP education will quickly resolve this one.
I'm looking at section 7.2 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-14#section-7.2, which speaks about OID.
So my OPS AD level of attention suddenly increased.

  ... one of the authors was
  assigned the Internet Private Enterprise Numbers range
  1.3.6.1.4.1.31103.x.  Within this range, the subrange
  1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
  federated file system protocols.

From http://www.iana.org/assignments/enterprise-numbers, I see
31103
  Daniel Ellard
    Daniel Ellard
      ellard&gmail.com

Then I thought: Ok, maybe, even if I read "permanently", this enterprise specific number requested by a specific person was a temporary solution.
However, reading further, yes, there is a new "FedFS Object Identifiers" registry, but it will still use the 1.3.6.1.4.1.31103.1.x range.

Then I looked at existing practice: http://tools.ietf.org/html/rfc4517
And I see, for example:
  The LDAP definition for the Other Mailbox syntax is:
      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

From http://www.iana.org/assignments/enterprise-numbers:
1466
  Mark Wahl
    Mark Wahl
      M.Wahl&isode.com


Is it normal that Standards Track documents register OIDs under enterprise specific numbers (on top of that, representing individuals)?
Is it normal that OIDs are registered this way in LDAP?

Note: I know of one PEN used within a standards track document, but this one was distinctly labeled.
29305
  IPFIX Reverse Information Element Private Enterprise
    RFC5103 Authors
      ipfix-biflow&cert.org


Disclaimer 1: My lack of LDAP is probably the cause of this DISCUSS-DISCUSS. So please shed some light.
Disclaimer 2: I spoke with Martin Stiemerling before posting this.
So I'm really after a reply (from the APPS ADs, I guess) such as: "don't worry, there are no problems with this."
2012-11-29
14 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2012-11-28
14 Pete Resnick
[Ballot comment]
2.8:

  A fileset MAY be accessible by protocols other than NFS.  For each
  such protocol, a corresponding FSL subtype SHOULD be …
[Ballot comment]
2.8:

  A fileset MAY be accessible by protocols other than NFS.  For each
  such protocol, a corresponding FSL subtype SHOULD be defined.  The
  contents and format of such FSL subtypes are not defined in this
  document.

That doesn't look like protocol to me. I think you can strike the whole paragraph, but at least get rid of the 2119 terms.

2.8.1.2:

  ...any non-ASCII UTF-8 code points and any URI-
  reserved characters, such as the slash ("/") character, contained in
  a component4 element MUST be represented by URI percent encoding.

The phrase "non-ASCII UTF-8 code points" isn't correct. Change it to "non-ASCII characters". It's closer to right.

2.8.1.3:

  In its "server" field, the NFSv4 fs_location4 data type contains a
  list of universal addresses or UTF-8 hostnames.

This is in all likelihood a problem with 5661 as well. What exactly do you mean by "UTF-8 hostname"? Do you mean a U-Label as described in IDNA (RFC 5890, et. al.), or do you simply mean a US-ASCII hostname in a UTF-8 string data type? If the former, you're going to have to say more. If the later, you should say "US-ASCII hostnames" instead.

4.2.1.6:

I've never been clear on why 4512 did as much in the way of customized ABNF as it did. You could replace all of the ABNF you have in this section with:

      ANNOTATION = KEY "=" VALUE
      KEY = ITEM
      VALUE = ITEM
      ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP

DQUOTE and WSP are defined in 5234, and UTF8-octets is defined in 3629. But it's up to you.


8:

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

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

See the admin document. Not very good definitions.
2012-11-28
14 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-11-28
14 Stephen Farrell
[Ballot comment]


Other than the comments on 4.2.1.3 and section 6, these
are pretty much nits. 

- 2.8: I'm not quite clear on the term …
[Ballot comment]


Other than the comments on 4.2.1.3 and section 6, these
are pretty much nits. 

- 2.8: I'm not quite clear on the term "subtype" - does that
mean that the NFS-specific information is contained in an FSL
"annotation"? I guess it does, but this is the first time the
term "subtype" is used.

- 2.8.1.2: what is "component4" ? I guess its an NFSv4 thing
but maybe good to say. (Same for other foo4 things, but just
saying once would be fine.)

- 2.12: Do you mean that FSN UUIDs only need to be unique per
NSDB node. (You might also want to use upper case MUST/SHOULD
for some of the uniqueness statements.)

- 4.2.1.3: LDAP integers can be of unlimited size.  Do you
need some kind of max for the fedfsFsnTTL to avoid any
potential DoS? What about negative integers? I assume you do
not want those? You could say that LDAP clients here
MUST implement some kind of max and MUST NOT accept negative
integer values. Or, as with other integers you could just
say it MUST be between [0,MAX].

- 5.3: I wondered if it would make sense to say that LDAP
referrals MUST have the same or better security properties
than the original LDAP request that caused the referral?  That
is, if I start with LDAP/TLS, then I'd barf on a cleartext
LDAP referral.

- section 6: *use* of TLS is RECOMMENDED which is fine, but
you don't say that implementation of TLS is a MUST.  I think
it'd be good to be explicit about that. (LDAP is a bit oddly
structured, maybe in a way to leave wiggle room to say you
conform here even though you don't support LDAP/TLS.)
2012-11-28
14 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-11-27
14 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-11-27
14 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2012-11-26
14 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-11-26
14 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-11-26
14 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-11-26
14 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2012-11-26
14 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-11-24
14 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2012-11-21
14 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2012-11-21
14 Jean Mahoney Request for Telechat review by GENART is assigned to Peter Yee
2012-11-10
14 Barry Leiba [Ballot comment]
The -14 version resolves all my comments, and clears my DISCUSS.  Thanks for addressing all this.
2012-11-10
14 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2012-11-10
14 Chuck Lever New version available: draft-ietf-nfsv4-federated-fs-protocol-14.txt
2012-11-08
13 Martin Stiemerling Removed telechat returning item indication
2012-11-08
13 Martin Stiemerling Telechat date has been changed to 2012-11-29 from 2012-11-15
2012-10-31
13 Barry Leiba
[Ballot discuss]
Done reviewing, so this is the last pass on the comments.  Thanks, Chuck, for the initial responses.  I'll watch for a revised I-D …
[Ballot discuss]
Done reviewing, so this is the last pass on the comments.  Thanks, Chuck, for the initial responses.  I'll watch for a revised I-D and re-check.

============================================

This is a long DISCUSS item because it contains a suggested resolution, but it should be quite simple to resolve.  So to be clear up front: the suggested resolution below is just a suggestion -- the actual DISCUSS point is that there is conflicting normative language in different places, and that has to get resolved.

-- Sections 2.7 and 2.8.3 --

In Section 2.7:
  An FSN record also contains a cache time-to-live attribute.  The
  FsnUuid and NsdbName values never change during an FSN's lifetime.
  However, an FSN's FSL information can change over time, and is
  typically cached on fileservers for performance.  More detail is
  provided in Section 2.8.3.

And in Section 2.8.3:
  An FSL's parent FSN contains a TTL field which contains a count in
  seconds of the time interval the FSL MAY be cached.  This is an upper
  bound for the lifetime of the cached information, and thus can act as
  a lower bound for the lifetime of redirecting junctions.

  For example, suppose this field contains the value 3600 seconds (one
  hour).  In such a case, administrators SHOULD keep the redirection in
  place for at least one hour after a fileset migration has taken
  place, and FSL data MUST NOT be cached by a referring fileserver for
  more than one hour without a refresh.

First, is the text in 2.7 meant to refer to the "FsnTTL" item that was just defined?  Why aren't the normative requirements for its use defined there?

In Section 2.8.3, the MAY in the first paragraph looked inappropriate, but I wasn't positive until I read the MUST NOT in the second.  There's also a SHOULD NOT in the second paragraph of the section that conflicts with that MUST NOT.  You're saying the same stuff too often, in too many places, inconsistently.  This information needs to be clearly specified normatively in one place, and cited from elsewhere without extra 2119 language that will confuse things.  I suggest putting the 2119 language Section 2.7.  How about this?:

Section 2.7:
<<
  An FSN consists of:

... (skip a bit) ...

      FsnTTL:  the time-to-live of the FSN's FSL information,
        in seconds.  FSL information MAY be cached, but MUST
        NOT be cached for longer than the FsnTTL value.  This
        means that if this value is zero, no caching is allowed.

... (skip a bit) ...

  The FsnUuid and NsdbName values never change during an FSN's
  lifetime.  However, an FSN's FSL information can change over
  time, and is typically cached on fileservers for performance.
  More detail on caching is provided in Section 2.8.3.
>>

Then clean up 2.8.3 to avoid repeating the 2119 words, and just go through the narrative and examples.

Second paragraph:
<<
  The parent FSN's FsnTTL attribute (see Section 2.7) specifies the
  maximum period of time during which these FSL records may be cached.
  In addition to that, a fileserver SHOULD check back with the NSDB
  node after the FSN TTL has expired to discover if any new FSL records
  have been added for this FSN.
>>

Later, tweaking the two paragraphs I quoted above:
<<
  The FsnTTL field in the FSL's parent FSN (see Section 2.7) specifies
  an upper bound for the lifetime of cached FSL information, and thus
  can act as a lower bound for the lifetime of redirecting junctions.

  For example, suppose the FsnTTL field contains the value 3600 seconds
  (one hour).  In such a case, administrators SHOULD keep the redirection
  in place for at least one hour after a fileset migration has taken
  place, because a referring fileserver might cache the FSL data during
  that time before refreshing it.
>>

Does that make sense?  Now you'll have the definition of FsnTTL in one place in Section 2.7, and won't be in danger of confusing things with conflicting MUSTs and SHOULDs.

-- Section 4.2.1.3 --
  A fedfsFsnTTL is the amount of time in seconds an FSN's TTL and its
  children FSL records SHOULD be cached by a fileserver.  A fedfsFsnTTL
  MUST be encoded as an Integer syntax value [RFC4517].

This is related to the stuff above: You've previously said that caching MAY be done, and now you're saying SHOULD.  You've previously specified FsnTTL as the *maximum* cache time, and now you're describing it as the *only* cache time.  I suggest that you take the 2119 language out of this and use a citation to Section 2.7 here, making sure that 2.7 says what you want.  Something like this:
NEW
  A fedfsFsnTTL is the time-to-live in seconds of an FSN and its
  child FSL records.  It corresponds to FsnTTL as defined in
  Section 2.7.  See that section and Section 2.8.3 for information
  about caching FSLs.  A fedfsFsnTTL MUST be encoded as an Integer
  syntax value [RFC4517].

-- Section 4.2.1.24 --
  A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB
  bit [RFC5661].

This should be "FSLI4IF_VAR_SUB" (it's missing an "I").
2012-10-31
13 Barry Leiba
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All …
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All the "MAY"s in the second paragraph are inappropriate, and should be "may" (or "might", of you prefer).  That's all non-normative explanation of how this is all meant to fit together, not normative text about interoperability choices.

-- Section 2.8.1.1 --
  An NFS URI MAY contain a port subcomponent as described in section
  3.2.3 of [RFC3986].  If this subcomponent is missing, a port value of
  2049 is assumed.

It's probably not a good idea to repeat normative information from elsewhere without citation.  Consider adding:
NEW
  a port value of
  2049 is assumed, as specified in [3530bis], Section 3.1.

-- Section 2.8.1.2 --
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  Because a URI is a US-ASCII string, any non-ASCII UTF-8 code point in
  a component4 element MUST be represented by URI percent encoding.
  URI-reserved characters such as the slash ("/") character contained
  in a component4 element MUST be represented by URI percent encoding.

Again, none of the encoding stuff is new.  I'd really like it if you made it clear that this is all just in conformance with normal RFC 3986 rules.  Something like this:
NEW
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  As specified in [RFC3986], any non-ASCII UTF-8 code points and any
  URI-reserved characters, such as the slash ("/") character, contained
  in a component4 element MUST be represented by URI percent encoding.

-- Section 2.8.3 --
There are two places where you use "FSN TTL", which was defined in Section 2.7 as "FsnTTL".  It's probably better to use "FsnTTL" consistently.

I also suggest adding a forward reference to Section 2.10 the first time "junction" is mentioned.

-- Section 2.11 --
  The root fileset could be implemented either as an exported NFS file
  system or as data in the NSDB itself.  The properties and schema
  definition of an NSDB-based root fileset and the protocol details
  that describe how to configure and replicate the root fileset are not
  defined in this document.

Is there a document where they are or will be defined, which you can cite?  If so, please do; if not, it might be better to say why they're not defined here ("...are implementation dependent and are not in scope for this document," or whatever is appropriate).

-- Section 2.12 --
  Of course, there is no way to guard against UUID re-use, but that is
  highly unlikely provided that UUIDs are constructed carefully.

Is "carefully" the right word?  Or maybe, "properly, according to [RFC4122]." ?

-- Section 3.3 --
  Fileset annotations MAY be used to convey additional attributes of a
  fileset

Apart from a missing full stop at the end, here's another inappropriate "MAY", which should be "may" or "can".  This isn't describing a protocol choice that affects interoperability.  It's telling us what fileset annotations are used for.

-- Section 4.1 --
  All implementations SHOULD use the same schema, or, at minimum, a
  schema that includes all of the objects, with each of the attributes,
  named in the following sections.

The "SHOULD" and "at minimum" have an unclear relationship.  Does this mean the following?:
NEW
  All implementations SHOULD use the same schema.  At minimum, each
  MUST use a schema that includes all of the objects named in the
  following sections, with all of the associated attributes.

--
  Given the above configuration guidelines, an NSDB SHOULD be
  constructed using a dedicated LDAP directory.  Separate LDAP
  directories are RECOMMENDED for other purposes, such as storing user
  account information.

Again, the relationship of the second sentence to the SHOULD in the first is unclear.  Perhaps this?:
NEW
  Given the above configuration guidelines, an NSDB SHOULD be
  constructed using a dedicated LDAP directory.  If directories
  are needed for other purposes, such as to store user account
  information, use of separate directories for those is
  RECOMMENDED.

-- Section 4.2 --
  As stated above, code components extracted from this document must
  include the following license:

As stated "above" where?  Maybe say "in the Copyright Notice at the beginning of this document," or just leave that off and start with "Code components...."

-- Section 4.2.1.6 --
  A fedfsAnnotation value SHOULD be processed as follows:

Why?  Is this talking about interoperability, or imposing an implementation?  What happens if I reverse those two steps in my implementation?  Is there a difference?

  A fedfsAnnotation attribute that does not adhere to this format
  SHOULD be ignored.

What other options are there?  What else could I possibly do with it?

You might also include an example that doesn't have the optional SPACE characters around the EQUALS:
  "key1"="foo"

-- Section 4.2.1.10 --
  A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
  FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
  is true.  A value of "FALSE" indicates the bit is false.

RFC 5661 never uses "true" or "false" to refer to that bit.  It uses "set" and "on".  I suggest this:
NEW
  A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
  FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
  is set.  A value of "FALSE" indicates the bit is not set.

I suggest the same change for Sections 4.2.1.11, 12, and 13.

-- Section 4.2.2.2 --
  A fedfsFsn MAY also have additional attributes, but these attributes
  MUST NOT be referenced by any part of this document.

Any part of what document?  What does "this" refer to?

-- Section 7.1 --
Thanks very much for making this new registry FCFS; as I see it, we don't do this often enough.

Should the new registry be grouped with the other "Network File System version 4 (NFSv4)" registries?  Or should there be a new top-level group called "Federated FileSystem (FedFS) parameters"?  It'd be good to specify, so IANA knows what you want.  Same goes for the new registry in 7.2.
2012-10-31
13 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2012-10-31
13 Barry Leiba
[Ballot discuss]
I've reviewed through the end of Section 4 and am starting Section 5 now.  I'll update these comments as I go, but I …
[Ballot discuss]
I've reviewed through the end of Section 4 and am starting Section 5 now.  I'll update these comments as I go, but I wanted to get the DISCUSS position recorded sooner, rather than later.

============================================


This is a long DISCUSS item because it contains a suggested resolution, but it should be quite simple to resolve.  So to be clear up front: the suggested resolution below is just a suggestion -- the actual DISCUSS point is that there is conflicting normative language in different places, and that has to get resolved.

-- Sections 2.7 and 2.8.3 --

In Section 2.7:
  An FSN record also contains a cache time-to-live attribute.  The
  FsnUuid and NsdbName values never change during an FSN's lifetime.
  However, an FSN's FSL information can change over time, and is
  typically cached on fileservers for performance.  More detail is
  provided in Section 2.8.3.

And in Section 2.8.3:
  An FSL's parent FSN contains a TTL field which contains a count in
  seconds of the time interval the FSL MAY be cached.  This is an upper
  bound for the lifetime of the cached information, and thus can act as
  a lower bound for the lifetime of redirecting junctions.

  For example, suppose this field contains the value 3600 seconds (one
  hour).  In such a case, administrators SHOULD keep the redirection in
  place for at least one hour after a fileset migration has taken
  place, and FSL data MUST NOT be cached by a referring fileserver for
  more than one hour without a refresh.

First, is the text in 2.7 meant to refer to the "FsnTTL" item that was just defined?  Why aren't the normative requirements for its use defined there?

In Section 2.8.3, the MAY in the first paragraph looked inappropriate, but I wasn't positive until I read the MUST NOT in the second.  There's also a SHOULD NOT in the second paragraph of the section that conflicts with that MUST NOT.  You're saying the same stuff too often, in too many places, inconsistently.  This information needs to be clearly specified normatively in one place, and cited from elsewhere without extra 2119 language that will confuse things.  I suggest putting the 2119 language Section 2.7.  How about this?:

Section 2.7:
<<
  An FSN consists of:

... (skip a bit) ...

      FsnTTL:  the time-to-live of the FSN's FSL information,
        in seconds.  FSL information MAY be cached, but MUST
        NOT be cached for longer than the FsnTTL value.  This
        means that if this value is zero, no caching is allowed.

... (skip a bit) ...

  The FsnUuid and NsdbName values never change during an FSN's
  lifetime.  However, an FSN's FSL information can change over
  time, and is typically cached on fileservers for performance.
  More detail on caching is provided in Section 2.8.3.
>>

Then clean up 2.8.3 to avoid repeating the 2119 words, and just go through the narrative and examples.

Second paragraph:
<<
  The parent FSN's FsnTTL attribute (see Section 2.7) specifies the
  maximum period of time during which these FSL records may be cached.
  In addition to that, a fileserver SHOULD check back with the NSDB
  node after the FSN TTL has expired to discover if any new FSL records
  have been added for this FSN.
>>

Later, tweaking the two paragraphs I quoted above:
<<
  The FsnTTL field in the FSL's parent FSN (see Section 2.7) specifies
  an upper bound for the lifetime of cached FSL information, and thus
  can act as a lower bound for the lifetime of redirecting junctions.

  For example, suppose the FsnTTL field contains the value 3600 seconds
  (one hour).  In such a case, administrators SHOULD keep the redirection
  in place for at least one hour after a fileset migration has taken
  place, because a referring fileserver might cache the FSL data during
  that time before refreshing it.
>>

Does that make sense?  Now you'll have the definition of FsnTTL in one place in Section 2.7, and won't be in danger of confusing things with conflicting MUSTs and SHOULDs.

-- Section 4.2.1.3 --
  A fedfsFsnTTL is the amount of time in seconds an FSN's TTL and its
  children FSL records SHOULD be cached by a fileserver.  A fedfsFsnTTL
  MUST be encoded as an Integer syntax value [RFC4517].

This is related to the stuff above: You've previously said that caching MAY be done, and now you're saying SHOULD.  You've previously specified FsnTTL as the *maximum* cache time, and now you're describing it as the *only* cache time.  I suggest that you take the 2119 language out of this and use a citation to Section 2.7 here, making sure that 2.7 says what you want.  Something like this:
NEW
  A fedfsFsnTTL is the time-to-live in seconds of an FSN and its
  child FSL records.  It corresponds to FsnTTL as defined in
  Section 2.7.  See that section and Section 2.8.3 for information
  about caching FSLs.  A fedfsFsnTTL MUST be encoded as an Integer
  syntax value [RFC4517].

-- Section 4.2.1.24 --
  A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB
  bit [RFC5661].

This should be "FSLI4IF_VAR_SUB" (it's missing an "I").
2012-10-31
13 Barry Leiba
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All …
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All the "MAY"s in the second paragraph are inappropriate, and should be "may" (or "might", of you prefer).  That's all non-normative explanation of how this is all meant to fit together, not normative text about interoperability choices.

-- Section 2.8.1.1 --
  An NFS URI MAY contain a port subcomponent as described in section
  3.2.3 of [RFC3986].  If this subcomponent is missing, a port value of
  2049 is assumed.

It's probably not a good idea to repeat normative information from elsewhere without citation.  Consider adding:
NEW
  a port value of
  2049 is assumed, as specified in [3530bis], Section 3.1.

-- Section 2.8.1.2 --
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  Because a URI is a US-ASCII string, any non-ASCII UTF-8 code point in
  a component4 element MUST be represented by URI percent encoding.
  URI-reserved characters such as the slash ("/") character contained
  in a component4 element MUST be represented by URI percent encoding.

Again, none of the encoding stuff is new.  I'd really like it if you made it clear that this is all just in conformance with normal RFC 3986 rules.  Something like this:
NEW
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  As specified in [RFC3986], any non-ASCII UTF-8 code points and any
  URI-reserved characters, such as the slash ("/") character, contained
  in a component4 element MUST be represented by URI percent encoding.

-- Section 2.8.3 --
There are two places where you use "FSN TTL", which was defined in Section 2.7 as "FsnTTL".  It's probably better to use "FsnTTL" consistently.

I also suggest adding a forward reference to Section 2.10 the first time "junction" is mentioned.

-- Section 2.11 --
  The root fileset could be implemented either as an exported NFS file
  system or as data in the NSDB itself.  The properties and schema
  definition of an NSDB-based root fileset and the protocol details
  that describe how to configure and replicate the root fileset are not
  defined in this document.

Is there a document where they are or will be defined, which you can cite?  If so, please do; if not, it might be better to say why they're not defined here ("...are implementation dependent and are not in scope for this document," or whatever is appropriate).

-- Section 2.12 --
  Of course, there is no way to guard against UUID re-use, but that is
  highly unlikely provided that UUIDs are constructed carefully.

Is "carefully" the right word?  Or maybe, "properly, according to [RFC4122]." ?

-- Section 3.3 --
  Fileset annotations MAY be used to convey additional attributes of a
  fileset

Apart from a missing full stop at the end, here's another inappropriate "MAY", which should be "may" or "can".  This isn't describing a protocol choice that affects interoperability.  It's telling us what fileset annotations are used for.

-- Section 4.1 --
  All implementations SHOULD use the same schema, or, at minimum, a
  schema that includes all of the objects, with each of the attributes,
  named in the following sections.

The "SHOULD" and "at minimum" have an unclear relationship.  Does this mean the following?:
NEW
  All implementations SHOULD use the same schema.  At minimum, each
  MUST use a schema that includes all of the objects named in the
  following sections, with all of the associated attributes.

--
  Given the above configuration guidelines, an NSDB SHOULD be
  constructed using a dedicated LDAP directory.  Separate LDAP
  directories are RECOMMENDED for other purposes, such as storing user
  account information.

Again, the relationship of the second sentence to the SHOULD in the first is unclear.  Perhaps this?:
NEW
  Given the above configuration guidelines, an NSDB SHOULD be
  constructed using a dedicated LDAP directory.  If directories
  are needed for other purposes, such as to store user account
  information, use of separate directories for those is
  RECOMMENDED.

-- Section 4.2 --
  As stated above, code components extracted from this document must
  include the following license:

As stated "above" where?  Maybe say "in the Copyright Notice at the beginning of this document," or just leave that off and start with "Code components...."

-- Section 4.2.1.6 --
  A fedfsAnnotation value SHOULD be processed as follows:

Why?  Is this talking about interoperability, or imposing an implementation?  What happens if I reverse those two steps in my implementation?  Is there a difference?

  A fedfsAnnotation attribute that does not adhere to this format
  SHOULD be ignored.

What other options are there?  What else could I possibly do with it?

You might also include an example that doesn't have the optional SPACE characters around the EQUALS:
  "key1"="foo"

-- Section 4.2.1.10 --
  A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
  FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
  is true.  A value of "FALSE" indicates the bit is false.

RFC 5661 never uses "true" or "false" to refer to that bit.  It uses "set" and "on".  I suggest this:
NEW
  A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
  FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
  is set.  A value of "FALSE" indicates the bit is not set.

I suggest the same change for Sections 4.2.1.11, 12, and 13.

-- Section 4.2.2.2 --
  A fedfsFsn MAY also have additional attributes, but these attributes
  MUST NOT be referenced by any part of this document.

Any part of what document?  What does "this" refer to?
2012-10-31
13 Barry Leiba Ballot comment and discuss text updated for Barry Leiba
2012-10-31
13 Barry Leiba
[Ballot discuss]
I've reviewed through the end of Section 3 and am starting Section 4 now.  I'll update these comments as I go, but I …
[Ballot discuss]
I've reviewed through the end of Section 3 and am starting Section 4 now.  I'll update these comments as I go, but I wanted to get the DISCUSS position recorded sooner, rather than later.

============================================


This is a long DISCUSS item because it contains a suggested resolution, but it should be quite simple to resolve.  So to be clear up front: the suggested resolution below is just a suggestion -- the actual DISCUSS point is that there is conflicting normative language in different places, and that has to get resolved.

-- Sections 2.7 and 2.8.3 --

In Section 2.7:
  An FSN record also contains a cache time-to-live attribute.  The
  FsnUuid and NsdbName values never change during an FSN's lifetime.
  However, an FSN's FSL information can change over time, and is
  typically cached on fileservers for performance.  More detail is
  provided in Section 2.8.3.

And in Section 2.8.3:
  An FSL's parent FSN contains a TTL field which contains a count in
  seconds of the time interval the FSL MAY be cached.  This is an upper
  bound for the lifetime of the cached information, and thus can act as
  a lower bound for the lifetime of redirecting junctions.

  For example, suppose this field contains the value 3600 seconds (one
  hour).  In such a case, administrators SHOULD keep the redirection in
  place for at least one hour after a fileset migration has taken
  place, and FSL data MUST NOT be cached by a referring fileserver for
  more than one hour without a refresh.

First, is the text in 2.7 meant to refer to the "FsnTTL" item that was just defined?  Why aren't the normative requirements for its use defined there?

In Section 2.8.3, the MAY in the first paragraph looked inappropriate, but I wasn't positive until I read the MUST NOT in the second.  There's also a SHOULD NOT in the second paragraph of the section that conflicts with that MUST NOT.  You're saying the same stuff too often, in too many places, inconsistently.  This information needs to be clearly specified normatively in one place, and cited from elsewhere without extra 2119 language that will confuse things.  I suggest putting the 2119 language Section 2.7.  How about this?:

Section 2.7:
<<
  An FSN consists of:

... (skip a bit) ...

      FsnTTL:  the time-to-live of the FSN's FSL information,
        in seconds.  FSL information MAY be cached, but MUST
        NOT be cached for longer than the FsnTTL value.  This
        means that if this value is zero, no caching is allowed.

... (skip a bit) ...

  The FsnUuid and NsdbName values never change during an FSN's
  lifetime.  However, an FSN's FSL information can change over
  time, and is typically cached on fileservers for performance.
  More detail on caching is provided in Section 2.8.3.
>>

Then clean up 2.8.3 to avoid repeating the 2119 words, and just go through the narrative and examples.

Second paragraph:
<<
  The parent FSN's FsnTTL attribute (see Section 2.7) specifies the
  maximum period of time during which these FSL records may be cached.
  In addition to that, a fileserver SHOULD check back with the NSDB
  node after the FSN TTL has expired to discover if any new FSL records
  have been added for this FSN.
>>

Later, tweaking the two paragraphs I quoted above:
<<
  The FsnTTL field in the FSL's parent FSN (see Section 2.7) specifies
  an upper bound for the lifetime of cached FSL information, and thus
  can act as a lower bound for the lifetime of redirecting junctions.

  For example, suppose the FsnTTL field contains the value 3600 seconds
  (one hour).  In such a case, administrators SHOULD keep the redirection
  in place for at least one hour after a fileset migration has taken
  place, because a referring fileserver might cache the FSL data during
  that time before refreshing it.
>>

Does that make sense?  Now you'll have the definition of FsnTTL in one place in Section 2.7, and won't be in danger of confusing things with conflicting MUSTs and SHOULDs.
2012-10-31
13 Barry Leiba
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All …
[Ballot comment]
These are non-blocking comments, but please consider them seriously, and feel free to chat with me about them:

-- Section 1 --
All the "MAY"s in the second paragraph are inappropriate, and should be "may" (or "might", of you prefer).  That's all non-normative explanation of how this is all meant to fit together, not normative text about interoperability choices.

-- Section 2.8.1.1 --
  An NFS URI MAY contain a port subcomponent as described in section
  3.2.3 of [RFC3986].  If this subcomponent is missing, a port value of
  2049 is assumed.

It's probably not a good idea to repeat normative information from elsewhere without citation.  Consider adding:
NEW
  a port value of
  2049 is assumed, as specified in [3530bis], Section 3.1.

-- Section 2.8.1.2 --
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  Because a URI is a US-ASCII string, any non-ASCII UTF-8 code point in
  a component4 element MUST be represented by URI percent encoding.
  URI-reserved characters such as the slash ("/") character contained
  in a component4 element MUST be represented by URI percent encoding.

Again, none of the encoding stuff is new.  I'd really like it if you made it clear that this is all just in conformance with normal RFC 3986 rules.  Something like this:
NEW
  The component4 elements of an NFS pathname SHOULD be prepared using
  the component4 rules defined in Chapter 12 "Internationalization" of
  [3530bis] prior to encoding the path component of an NFS URI.
  As specified in [RFC3986], any non-ASCII UTF-8 code points and any
  URI-reserved characters, such as the slash ("/") character, contained
  in a component4 element MUST be represented by URI percent encoding.

-- Section 2.8.3 --
There are two places where you use "FSN TTL", which was defined in Section 2.7 as "FsnTTL".  It's probably better to use "FsnTTL" consistently.

I also suggest adding a forward reference to Section 2.10 the first time "junction" is mentioned.

-- Section 2.11 --
  The root fileset could be implemented either as an exported NFS file
  system or as data in the NSDB itself.  The properties and schema
  definition of an NSDB-based root fileset and the protocol details
  that describe how to configure and replicate the root fileset are not
  defined in this document.

Is there a document where they are or will be defined, which you can cite?  If so, please do; if not, it might be better to say why they're not defined here ("...are implementation dependent and are not in scope for this document," or whatever is appropriate).

-- Section 2.12 --
  Of course, there is no way to guard against UUID re-use, but that is
  highly unlikely provided that UUIDs are constructed carefully.

Is "carefully" the right word?  Or maybe, "properly, according to [RFC4122]." ?

-- Section 3.3 --
  Fileset annotations MAY be used to convey additional attributes of a
  fileset

Apart from a missing full stop at the end, here's another inappropriate "MAY", which should be "may" or "can".  This isn't describing a protocol choice that affects interoperability.  It's telling us what fileset annotations are used for.
2012-10-31
13 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2012-10-23
13 Martin Stiemerling Ballot has been issued
2012-10-23
13 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2012-10-23
13 Martin Stiemerling Created "Approve" ballot
2012-10-23
13 Martin Stiemerling Ballot writeup was changed
2012-10-23
13 Martin Stiemerling Placed on agenda for telechat - 2012-11-15
2012-10-23
13 Martin Stiemerling State changed to IESG Evaluation from Waiting for AD Go-Ahead
2012-10-22
13 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-10-21
13 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee.
2012-10-19
13 Pearl Liang
IANA has reviewed draft-ietf-nfsv4-federated-fs-protocol-13 and has the following comments:

IANA has a question about one of the actions requested to be completed
by IANA in …
IANA has reviewed draft-ietf-nfsv4-federated-fs-protocol-13 and has the following comments:

IANA has a question about one of the actions requested to be completed
by IANA in this document.

IANA understands that, upon approval of this document, there are three IANA
actions which must be completed.

First, IANA will create a new registry.  The registry will be named the
"FedFS Annotation Keys" registry.  Future registrations are to be
administered by IANA using the "First Come First Served" policy as defined in
RFC 5226

Registration requests for the new registry must include the key (a valid UTF-8
string of any length), a brief description of the key's purpose, and an email
contact for the registration.  The registry will contain these data items.

The new registry will be sorted lexicographically by key. 

There are no initial assignments for this registry.

Second, IANA will create another new registry.  The registry will be named the
"FedFS Object Identifiers" registry.  This registry will consist of a set of OID
values in the FedFS Object Identifier (OID) range.  That range is:
1.3.6.1.4.1.31103.1.x

Future allocations from the 1.3.6.1.4.1.31103.1.x range are to be assigned by
IANA using the "RFC Required" policy as defined in RFC 5226.  Registration
requests MUST include an OID value from the 1.3.6.1.4.1.31103.1.x range, a short
description of the OID, and a reference to the specification that defines the
OID's usage.  The registry will contain these data items.

The new registry will be sorted numerically by OID value.

The initial registrations in this new registry are as follows:


+--------------------------+-------------------------+------------+
| OID                      | Description            | Reference  |
+--------------------------+-------------------------+------------+
| 1.3.6.1.4.1.31103.1.1    | fedfsUuid              | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.2    | fedfsNetAddr            | deprecated |
| 1.3.6.1.4.1.31103.1.3    | fedfsNetPort            | deprecated |
| 1.3.6.1.4.1.31103.1.4    | fedfsFsnUuid            | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.5    | fedfsNsdbName          | deprecated |
| 1.3.6.1.4.1.31103.1.6    | fedfsNsdbPort          | deprecated |
| 1.3.6.1.4.1.31103.1.7    | fedfsNcePrefix          | deprecated |
| 1.3.6.1.4.1.31103.1.8    | fedfsFslUuid            | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.9    | fedfsFslHost            | deprecated |
| 1.3.6.1.4.1.31103.1.10  | fedfsFslPort            | deprecated |
| 1.3.6.1.4.1.31103.1.11  | fedfsFslTTL            | deprecated |
| 1.3.6.1.4.1.31103.1.12  | fedfsAnnotation        | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.13  | fedfsDescr              | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.14  | fedfsNceDN              | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.15  | fedfsFsnTTL            | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.100  | fedfsNfsPath            | deprecated |
| 1.3.6.1.4.1.31103.1.101  | fedfsNfsMajorVer        | deprecated |
| 1.3.6.1.4.1.31103.1.102  | fedfsNfsMinorVer        | deprecated |
| 1.3.6.1.4.1.31103.1.103  | fedfsNfsCurrency        | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.104  | fedfsNfsGenFlagWritable | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.105  | fedfsNfsGenFlagGoing    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.106  | fedfsNfsGenFlagSplit    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.107  | fedfsNfsTransFlagRdma  | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.108  | fedfsNfsClassSimul      | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.109  | fedfsNfsClassHandle    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.110  | fedfsNfsClassFileid    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.111  | fedfsNfsClassWritever  | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.112  | fedfsNfsClassChange    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.113  | fedfsNfsClassReaddir    | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.114  | fedfsNfsReadRank        | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.115  | fedfsNfsReadOrder      | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.116  | fedfsNfsWriteRank      | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.117  | fedfsNfsWriteOrder      | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.118  | fedfsNfsVarSub          | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.119  | fedfsNfsValidFor        | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.120  | fedfsNfsURI            | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.1001 | fedfsNsdbContainerInfo  | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.1002 | fedfsFsn                | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.1003 | fedfsFsl                | RFC-to-be  |
| 1.3.6.1.4.1.31103.1.1004 | fedfsNfsFsl            | RFC-to-be  |
+--------------------------+-------------------------+------------+


Third, in the Object Identifier Descriptors subregistry of the Lightweight
Directory Access Protocol (LDAP) Parameters registry located at:

www.iana.org/assignments/ldap-parameters/ldap-parameters.xml

Forty (40) new Object Identifiers are to be registered.  The details of the
forth registrations are located in section 7.3 of the approved document.

Currently the LDAP Object Identifier registry is maintained through expert
review as defined in RFC 5226.

IANA Question -> has the document been reviewed by the LDAP Object Identifier
registry expert? 

IANA understands that these three actions are the only ones required to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
2012-10-18
13 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Charlie Kaufman.
2012-10-11
13 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2012-10-11
13 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2012-10-11
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2012-10-11
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Charlie Kaufman
2012-10-08
13 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (NSDB Protocol for Federated Filesystems) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (NSDB 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:
- 'NSDB 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-10-22. 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 a filesystem federation protocol 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-protocol/

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


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1362/
  http://datatracker.ietf.org/ipr/1634/



2012-10-08
13 Amy Vezza State changed to In Last Call from Last Call Requested
2012-10-08
13 Martin Stiemerling Last call was requested
2012-10-08
13 Martin Stiemerling Ballot approval text was generated
2012-10-08
13 Martin Stiemerling Ballot writeup was generated
2012-10-08
13 Martin Stiemerling State changed to Last Call Requested from AD Evaluation::AD Followup
2012-10-08
13 Martin Stiemerling Last call announcement was generated
2012-09-25
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-09-25
13 James Lentini New version available: draft-ietf-nfsv4-federated-fs-protocol-13.txt
2012-06-13
12 Martin Stiemerling
The write-up was trunctated at "For Patent 5,842,214".

Here is the missing text:
For Patent 5,842,214 no substantive commentary was made in either working group …
The write-up was trunctated at "For Patent 5,842,214".

Here is the missing text:
For Patent 5,842,214 no substantive commentary was made in either working group sessions or on the WG alias with regards to this disclosure. Given the licensing terms submitted by Microsoft, it is the expectation of the shepherd that the working group will NOT take action in response to the disclosure.
2012-06-13
12 Martin Stiemerling The authors have a list of open issues to be fixed (https://github.com/loghyr/FedFS-Drafts/blob/master/todo.txt) and they are working on it.
2012-06-13
12 Martin Stiemerling State changed to AD Evaluation::Revised ID Needed from AD Evaluation::External Party
2012-06-13
12 Martin Stiemerling waiting for response from the authors with respect to the tsv-dir review by David Black.
2012-06-13
12 Martin Stiemerling State changed to AD Evaluation::External Party from AD Evaluation::AD Followup
2012-05-25
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-05-25
12 James Lentini New version available: draft-ietf-nfsv4-federated-fs-protocol-12.txt
2012-03-29
11 Martin Stiemerling Responsible AD changed to Martin Stiemerling from David Harrington
2011-12-12
11 David Harrington
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
TSVDIR Review:

From: tsv-dir-bounces@ietf.org [mailto:tsv-dir-bounces@ietf.org] On
Behalf Of david.black@emc.com
Sent: Saturday, November 26, …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
TSVDIR Review:

From: tsv-dir-bounces@ietf.org [mailto:tsv-dir-bounces@ietf.org] On
Behalf Of david.black@emc.com
Sent: Saturday, November 26, 2011 5:07 PM
To: nfsv4@ietf.org; tsv-dir@ietf.org; tsv-area@ietf.org
Subject: Transport Directorate review
ofdraft-ietf-nfsv4-federated-fs-protocol-11

I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to
allow them to address any issues raised. The authors should consider
this review together with any other last-call comments they receive.
Please always CC tsv-dir@ietf.org if you reply to or forward this
review.

First, I should apologize for the delay in this review - my day job
has this recurrent habit of distracting me from IETF work ;-), and
Taipei was a rather long journey to/from Boston.

Summary: This draft is on the right track but has open issues,
described in the review.

NFSv4.0 and NFSv4.1 provide support for replicas of an exported
filesystem, but don't contain any details on how to manage the
replicas or access multiple filesystems in a single coherent
namespace.  This draft is one of NFSv4 several federated filesystem
drafts that serve to fill that gap.  This draft primarily specifies an
LDAP schema and use of LDAP operations to manage a federated namespace
- at a junction point in the namespace (between two exported
filesystems), an LDAP lookup is done to find the destination
filesystem, thus enabling LDAP to provide a level of indirection by
comparison to hard-wiring the location of the destination filesystem
into the junction point metadata in the source filesystem.

This is a relatively straightforward use of LDAP - I did not see any
significant transport protocol usage issues, but I do have one open
issue that should be relatively straightforward to address.

The NFSv4 replica mechanism is not simple, especially in its full
NFSv4.1 (RFC 5661) form - section 4.2.2.4 of this draft lists nearly
20 attributes that have to be specified in an LDAP entry in order to
characterize a replica (a File Set Location in NFSv4 parlance). The
details of how replica selection works are in RFC 5661, and require
some careful reading to understand.  For replica selection and usage,
Section 2.8.1 of this draft bothers me - despite being about
consistency, it clearly states that replicas do not need to be
read-write consistent, and that clients may switch among replicas
transparently ... and this should all be ok because "it is the
responsibility of administrators to guarantee the functional
equivalence of the data" among replicas.

That current text reminds me of the Forrest Gump quote: "Life was like
a box of chocolates. You never know what you're gonna get."  Needless
to say, "You never know what you're gonna get" is not a good network
filesystem behavior, and the expectation is that administrators will
configure the use of replicas to do considerably better than that.
Towards this end, I'd like to see some guidance to administrators in
this draft for how to stay out of trouble; some of that guidance could
be provided by reference to the longer explanation of the replica
mechanism that's already in RFC 5661.

idnits 2.12.12 didn't find any nits.

Thanks,
--David
2011-11-26
11 David Black Request for Early review by TSVDIR Completed. Reviewer: David Black.
2011-10-27
11 David Harrington Request for Early review by TSVDIR is assigned to David Black
2011-10-27
11 David Harrington Request for Early review by TSVDIR is assigned to David Black
2011-10-18
(System) Posted related IPR disclosure: NetApp's Statement about IPR related to draft-ietf-nfsv4-federated-fs-protocol
2011-08-31
11 David Harrington State changed to AD Evaluation from Publication Requested.
2011-08-22
11 Cindy Morgan [Note]: 'Spencer Shepler (sshepler@microsoft.com) is the document shepherd.
' added
2011-08-22
11 Cindy Morgan
Working Group:  NFSv4
Area Director:  David Harrington
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:


draft-ietf-nfsv4-federated-fs-protocol-11.txt

Note: as background for this review, please review …
Working Group:  NFSv4
Area Director:  David Harrington
Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com)

Internet Draft:


draft-ietf-nfsv4-federated-fs-protocol-11.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) Outside of the IANA registration reviews noted below, no other
  external review is being requested as part of this
shepherding review.

  (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.

Two IPR disclosures 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.

Second is a disclosure from Microsoft Corporation that
can be found here:
http://datatracker.ietf.org/ipr/1362/

For Patent 5,842,214

  (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 documents: draft-ietf-nfsv4-federated-fs-admin-09
and draft-ietf-nfsv4-federated-fs-dns-srv-namespace-07.
Thus these three documents need to move together through
the publication process. 

This document and draft-ietf-nfsv4-federated-fs-admin-09
should be reviewed together to assist in review quality.

  (1.i) An IANA section does exist.

  Note the following IANA actions defined by this I-D:

1) A new registry is being created "FedFS Annotation Keys"
  with no initial entries.  The first-come-first-served
  process from RFC5526 has been chosen for management
  of the registry.

2) A new registry is being created "FedFS Object Identifiers"
  with an initial set of entries.  The RFC required process
  has been chosen for this registry as per RFC5526.
  Note that this registry is for an Object Identifier (OID) range.
  The range is a subset of a "personal" registration in
  the Internet Private Enterprise Numbers registry as
  defined in RFC2578.

3) Finally, a set of LDAP descriptors are being registered
  via the process defined in RFC4520 by expert review.

 
  (1.j) An LDAP schema is defined by this document and thus uses
  the LDAP schema syntax defined in [RFC4512].  The I-D is
constructed in a way as the schema may be directly extracted
and used by the reader.

  (1.k)

  Technical Summary

    This document describes a filesystem federation protocol 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 protocol as to be used with NFSv4 file servers is an
    important component to providing enterprise usable federated
    NFSv4 file systems.  Combined with the Administration Protocol
    for Federated Filesystems, and NFSv4 protocols a complete
    solution is possible and provides substantial utility.

  Document Quality

    Not only is the NSDB Protocol for Federated Filesystems document
    complete, readable and useful as a guide to implementation and
    interoperability, this has been proven by 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.
2011-08-17
11 David Harrington Changed protocol writeup
2011-08-17
11 David Harrington Draft added in state Publication Requested
2011-03-11
11 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-11.txt
2010-11-19
10 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-10.txt
2010-09-02
09 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-09.txt
2010-08-18
08 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-08.txt
2010-08-13
07 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-07.txt
2010-07-21
(System) Posted related IPR disclosure: Microsoft Corporation's Statement about IPR related to draft-ietf-nfsv4-federated-fs-protocol-06
2010-07-10
06 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-06.txt
2010-01-21
05 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-05.txt
2009-10-26
04 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-04.txt
2009-08-20
03 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-03.txt
2009-07-10
02 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-02.txt
2009-02-20
01 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-01.txt
2008-09-26
00 (System) New version available: draft-ietf-nfsv4-federated-fs-protocol-00.txt