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 |