Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-minorversion1-29
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
29 | (System) | post-migration administrative database adjustment to the No Objection position for Lisa Dusseault |
2012-08-22
|
29 | (System) | post-migration administrative database adjustment to the No Objection position for Chris Newman |
2012-08-22
|
29 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
29 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2009-01-23
|
29 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-23
|
29 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-23
|
29 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-01-16
|
29 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-12-19
|
29 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-12-19
|
29 | (System) | IANA Action state changed to In Progress |
2008-12-19
|
29 | Amy Vezza | IESG state changed to Approved-announcement sent |
2008-12-19
|
29 | Amy Vezza | IESG has approved the document |
2008-12-19
|
29 | Amy Vezza | Closed "Approve" ballot |
2008-12-19
|
29 | Lars Eggert | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert |
2008-12-18
|
29 | Chris Newman | [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman |
2008-12-15
|
29 | (System) | New version available: draft-ietf-nfsv4-minorversion1-29.txt |
2008-12-11
|
29 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk |
2008-12-11
|
29 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk |
2008-12-10
|
29 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2008-12-10
|
29 | Lisa Dusseault | [Ballot Position Update] Position for Lisa Dusseault has been changed to No Objection from Discuss by Lisa Dusseault |
2008-12-05
|
29 | (System) | Removed from agenda for telechat - 2008-12-04 |
2008-12-04
|
29 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-12-04
|
28 | (System) | New version available: draft-ietf-nfsv4-minorversion1-28.txt |
2008-12-04
|
29 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Amy Vezza |
2008-12-04
|
29 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-12-04
|
29 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-12-04
|
29 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] [This is an updated discuss. Issue #2 is new] Issue #1 This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and … [Ballot discuss] [This is an updated discuss. Issue #2 is new] Issue #1 This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic. These problems are exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, they should become optional, and thorough applicability text describing when these mechanisms are appropriate and detailing the limited security achieved must be added. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. This is a very significant improvement, since v4 referenced earlier Kerberos specifications relying on DES and MD5, but is not highlighted anywhere in the specification. Finally, a brief note in the secuirty considerations text on cryptographic algorithms might be helpful. When deploying NFSv4.1, the security achieved is largely dependent on the existing Kerberos infrastructure. The algorithms are not directly exposed to or selectable by the client or server, so there is some due diligence required to ensure that security is acceptable where needed. Issue #2 The security implications of pNFS are significant. They are clearly documented in section 12.9, but I believe they merit an earlier mention. Specifically, sections 1.6.1 and 1.6.2.2 should be updated to note that the traditional security framework is modified by the introduction of pNFS. |
2008-12-04
|
29 | Pasi Eronen | [Ballot comment] NFSv4.1 is probably the most complex protocol IETF has ever attempted to standardize --- and if this is a "minor version" (with >300 … [Ballot comment] NFSv4.1 is probably the most complex protocol IETF has ever attempted to standardize --- and if this is a "minor version" (with >300 pages of new text), I don't want to even think what a "major version" would be like :-) I can't claim that I have read the whole spec. It looks unusually well written, so I'm balloting "no objection". |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) … [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic. These problems are exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, they should become optional, and thorough applicability text describing when these mechanisms are appropriate and detailing the limited security achieved must be added. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. This is a very significant improvement, since v4 referenced earlier Kerberos specifications relying on DES and MD5, but is not highlighted anywhere in the specification. Finally, a brief note in the secuirty considerations text on cryptographic algorithms might be helpful. When deploying NFSv4.1, the security achieved is largely dependent on the existing Kerberos infrastructure. The algorithms are not directly exposed to or selectable by the client or server, so there is some due diligence required to ensure that security is acceptable where needed. |
2008-12-04
|
29 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) … [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic. These problems are exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, applicability text describing when these mechanisms are appropriate and detailing the limited security achieved must be added. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. This is a very significant improvement, since v4 referenced earlier Kerberos specifications relying on DES and MD5, but is not highlighted anywhere in the specification. Finally, a brief note in the secuirty considerations text on cryptographic algorithms might be helpful. When deploying NFSv4.1, the security achieved is largely dependent on the existing Kerberos infrastructure. The algorithms are not directly exposed to or selectable by the client or server, so there is some due diligence required to ensure that security is acceptable where needed. |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) … [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic. These problems are exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, applicability text describing when these mechanisms are appropriate and detailing the limited security achieved must be added. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. This is a very significant improvement, since v4 referenced earlier Kerberos specifications relying on DES and MD5, but is not highlighted anywhere in the specification. Finally, a brief note in the secuirty considerations text on cryptographic algorithms might be helpful. When deploying NFSv4.1, the security achieved is largely dependent on the existing Kerberos infrastructure. The algorithms are not directly exposed to or selectable by the client or server, so there is some due diligence required to ensure that security is acceptable where needed. |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) … [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. To make matters worse, implementers in the security directorate find that LIPKEY and SPKM-3 are underspecified, so interoperability of these options can be problematic. These problems are exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. I believe that LIPKEY and SPKM-3 should be removed from the mandatory to implement security mechanism list. If the wg feels strongly they should be retained, applicability text describing when these mechanisms are appropriate and detailing the limited security achieved must be added. It would also be helpful if the text on Kerberos was expanded to note that the mandatory to implement algorithm set is now AES with HMAC-SHA1, based on the reference to RFC 4121. This is a very significant improvement, since v4 referenced earlier Kerberos specifications relying on DES and MD5, but is not highlighted anywhere in the specification. Finally, a brief note in the secuirty considerations text on cryptographic algorithms might be helpful. When deploying NFSv4.1, the security achieved is largely dependent on the existing Kerberos infrastructure. The algorithms are not directly exposed to or selectable by the client or server, so there is some due diligence required to ensure that security is acceptable where needed. |
2008-12-04
|
29 | Tim Polk | [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) … [Ballot discuss] This specification includes three mandatory to implement security mechanisms: Kerberos; LIPKEY; and SPKM-3. The LIPKEY and SPKM-3 mechanisms (specified in RFC 2847) are only defined with respect to a small number of cryptographic algorithms, and most of them are weak. SPKM-3 (and by extension, LIPKEY) is specified for DES and CAST5 as encryption algorithms and MD5-RSA, DES-MAC, DSA-SHA1, HMAC-MD5, and SHA1-RSA are the only integrity algorithms. Neither encryption algorithm would be considered an acceptable choice today. While some of the integrity algorithms are still marginally acceptable, even the strongest (SHA1-RSA and DSA-SHA1) are at the end of their useful lifespan. There are also no restrictions or guidance with respect to key sizes for DSA or RSA in RFC 2847. The problem is exacerbated by a lack of guidance in the body or security considerations section. There is nothing to indicate that the security provided by these three mandatory to implement mechanisms is inconsistent. |
2008-12-04
|
29 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2008-12-04
|
29 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-12-04
|
29 | Chris Newman | [Ballot comment] The IDNA community which created stringprep has found certain problems with it after deployment. First, stringprep is based on NFKC, but it turns … [Ballot comment] The IDNA community which created stringprep has found certain problems with it after deployment. First, stringprep is based on NFKC, but it turns out that NFKC canonicalizes some things which should not be canonicalized in some locales for strings used significantly or primarily for human display. An example is German sharp-S, which is fine to canonicalize to "ss" in most German-speaking countries, but not in all of them. Second, the prohibited characters can be overly aggressive for some locales. It is probably safer to leave most prohibitions as a policy matter rather than a standards matter. At a minimum, I would recommend allowing the following ranges in the stringprep profile: C.1.2, C.3, C.4, C.7, C.8, C.9. It could be argued that prohibiting C.9 violates the language tagging requirement in RFC 2277 (although the apps ADs have not been enforcing that part of that BCP). Third, locking to a particular Unicode version is problematic because many operating systems have i18n libraries with Unicode tables for a version of Unicode that was current at the time of the OS release. Client code benefits from using OS libraries for these functions by being consistent with the rest of the OS (including any built-in OS filesystem). If NFS stringprep is locked to a particular Unicode version, then client code has to carry around separate parallel Unicode tables and libraries to be fully compliant. I'm not sure this benefits anyone. Now as Stringprep remains on the standards track and has not been moved to historic, it is valid process to use it in IETF specifications and I consider use of it insufficient justification for the IESG to block progression. However, we also have RFC 5198 (based on NFC) on the standards track as a much lighter-weight alternative (some might argue too light-weight). I consider either choice acceptable on the standards track, but recommend the issue be considered carefully in light of the experiences from the IDN community. Be aware this is an area where we don't fully understand what's "correct" and one that may need to be revisited. |
2008-12-04
|
29 | Chris Newman | [Ballot discuss] Section 14.5 > Where the client supplied string is valid UTF-8 but contains > characters that are not supported by the server as … [Ballot discuss] Section 14.5 > Where the client supplied string is valid UTF-8 but contains > characters that are not supported by the server as a value for that > string (e.g. names containing characters that have more than two > bytes on a file system that supports Unicode characters only), the > server should return NFS4ERR_BADCHAR. Both UTF-8 and UTF-16 include Unicode characters that have more than two bytes, so this statement is factually incorrect. I _think_ what you meant to say is: Where the client supplied string is valid UTF-8 but contains characters that are not supported by the server as a value for that string (e.g. names containing characters outside of Unicode plane 0 on filesystems that fail to support such characters despite their presence in the Unicode standard), the server should return NFS4ERR_BADCHAR. Please clarify your intentions here. |
2008-12-04
|
29 | Chris Newman | [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman |
2008-12-03
|
29 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-12-03
|
27 | (System) | New version available: draft-ietf-nfsv4-minorversion1-27.txt |
2008-12-03
|
29 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-03
|
29 | Amanda Baber | IANA comments: Upon approval of this document IANA understands that the following actions must be completed: 1] Creation of a new "NFSv4 Named Attribute Definitions … IANA comments: Upon approval of this document IANA understands that the following actions must be completed: 1] Creation of a new "NFSv4 Named Attribute Definitions Registry" http://www.iana.org/assignments/nfsv41/nfsv41-named-attribute- definitions.xhtml 2] Creation of a new "NFSv4.1 Device ID Notifications Registry" http://www.iana.org/assignments/nfsv41/nfsv41-device-id-notifications.xhtml 3] Creation of a new "NFSv4.1 Recallable Object Types Registry" http://www.iana.org/assignments/nfsv41/nfsv41-recallable-object-types.xhtml 4] Creation of a new "pNFS Layout Types Registry" http://www.iana.org/assignments/nfs/pnfs-layout-types.xhtml 5] Creation of a new "NFSv4 Path Variables Registry" http://www.iana.org/assignments/nfsv41/path-variables.xhtml 6] Inside the new "NFSv4 Path Variables Registry" will be two new registries: the "NFSv4 ${ietf.org:CPU_ARCH} Value Registry" and the "NFSv4 ${ietf.org:OS_TYPE} Value Registry" The details of the registries as IANA understands them is provided below. Upon approval of this document, IANA understands that these are the only actions required of IANA. Detailed IANA actions 1] Creation of a new "NFSv4 Named Attribute Definitions Registry" http://www.iana.org/assignments/nfsv41/nfsv41-named-attribute- definitions.xhtml Registry content description: The NFSv4.1 protocol supports the association of a file with zero or more named attributes. The name space identifiers for these attributes are defined as string names. The protocol does not define the specific assignment of the name space for these file attributes. Such registered named attributes are presumed to apply to all minor versions of NFSv4, including those defined subsequently to the registration. Where the named attribute is intended to be limited with regard to the minor versions for which they are not be used, the assignment in registry will clearly state the applicable limits. New assignments to the registry: All assignments to the registry are made on a First Come First Served basis. The policy for each assignment is Specification Required. Changes to assignments to the registry: The registrant is always permitted to update the point of contact field. To make any other change will require Expert Review or IESG Approval. Registry entry rules: NFSv4 Named Attributes are 128 UTF-8 characters or less. The zero length named attribute is Reserved. Registry entry rules, prefixes: The prefixes "EXPE" and "STDS" are Reserved. The prefix "PRIV" is allocated for Private Use. A site that wants to make use of unregistered named attributes without risk of conflicting with an assignment in IANA's registry should use the prefix "PRIV" in all of its named attributes. Because some NFSv4.1 clients and servers have case insensitive semantics, the fifteen additional lower case and mixed case permutations of each of "EXPE", "PRIV", and "STDS", are Reserved (e.g. "expe", "expE", "exPe", etc. are Reserved). Similarly, IANA will not allow two assignments that would conflict if both named attributes were converted to a common case. Registry entry description: The registry of named attributes is a list of assignments, each containing three fields for each assignment. 1] A US-ASCII string name that is the actual name of the attribute. This name must be unique. This string name can be 1 to 128 UTF-8 characters long. 2] A reference to the specification of the named attribute. The reference can consume up to 256 bytes. 3] The point of contact of the registrant. The point of contact can consume up to 256 bytes. Initial Registry for the "NFSv4 Named Attribute Definitions Registry": There is no initial registry. 2] Creation of a new "NFSv4.1 Device ID Notifications Registry" http://www.iana.org/assignments/nfsv41/nfsv41-device-id-notifications.xhtml Registry content description: The potential exists for new notification types to be added to the CB_NOTIFY_DEVICEID operation. This can be done via changes to the operations that register notifications, or by adding new operations to NFSv4. This requires a new minor version of NFSv4. Another way to add a notification is to specify a new layout type. New assignments to the registry: All assignments to the registry are made on a Standards Action basis, with Expert Review required. Changes to assignments in the registry: The update of a registration will require IESG Approval on the advice of a Designated Expert. Registry entry description: The registry is a list of assignments, each containing five fields per assignment. 1] The name of the notification type. This name must have the prefix: "NOTIFY_DEVICEID4_". This name must be unique. 2] The value of the notification. IANA will assign this number, and the request from the registrant will use TBD1 instead of an actual value. IANA MUST use a whole number which can be no higher than 2^32-1, and should be the next available value. The value assigned must be unique. A Designated Expert must be used to ensure that when the name of the notification type and its value are added to the NFSv4.1 notify_deviceid_type4 enumerated data type in the NFSv4.1 XDR description, the result continues to be a valid XDR description. 3] The Standards Track RFC(s) that describe the notification. If the RFC(s) have not yet been published, the registrant will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. 4] How the RFC introduces the notification. This is indicated by a single US- ASCII value. If the value is N, it means a minor revision to the NFSv4 protocol. If the value is L, it means a new pNFS layout type. Other values can be used with IESG Approval. 5] The minor versions of NFSv4 that are allowed to the use the notification. While these are numeric values, IANA will not allocate and assign them; the author of the relevant RFCs with IESG Approval assigns these numbers. Each time there is new minor version of NFSv4 approved, a Designated Expert should review the registry to make recommended updates as needed. Initial Registry for the "NFSv4.1 Device ID Notifications Registry" Notification Name Value RFC How Minor Versions NOTIFY_DEVICEID4_CHANGE 1 RFCTBD10 N 1 NOTIFY_DEVICEID4_DELETE 2 RFCTBD10 N 1 3] Creation of a new "NFSv4.1 Recallable Object Types Registry" http://www.iana.org/assignments/nfsv41/nfsv41-recallable-object-types.xhtml Registry content description: The potential exists for new object types to be added to the CB_RECALL_ANY operation. This can be done via changes to the operations that add recallable types, or by adding new operations to NFSv4. This requires a new minor version of NFSv4. Another way to add a new recallable object is to specify a new layout type. New assignments to the registry: All assignments to the registry are made on a Standards Action basis, with Expert Review required. Changes to assignments in the registry: The update of a registration will require IESG Approval on the advice of a Designated Expert. Registry entry rules: Recallable object types are 32 bit unsigned numbers. There are no Reserved values. Values in the range 12 through 15, inclusive, are reserved by IANA for Private Use. Registry entry description: The registry is a list of assignments, each containing five fields per assignment. 1] The name of the recallable object type. This name must have the prefix: "RCA4_TYPE_MASK_". The name must be unique. 2] The value of the recallable object type. IANA will assign this number, and the request from the registrant will use TBD1 instead of an actual value. IANA will use a whole number which can be no higher than 2^32-1, and should be the next available value. The value must be unique. A Designated Expert must be used to ensure that when the name of the recallable type and its value are added to the NFSv4 XDR description, the result continues to be a valid XDR description. 3] The Standards Track RFC(s) that describe the recallable object type. If the RFC(s) have not yet been published, the registrant will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. 4] How the RFC introduces the recallable object type. This is indicated by a single US-ASCII value. If the value is N, it means a minor revision to the NFSv4 protocol. If the value is L, it means a new pNFS layout type. Other values can be used with IESG Approval. 5] The minor versions of NFSv4 that are allowed to the use the recallable object type. While these are numeric values, IANA will not allocate and assign them; the author of the relevant RFCs with IESG Approval assigns these numbers. Each time there is new minor version of NFSv4 approved, a Designated Expert should review the registry to make recommended updates as needed. Initial Registry for the "NFSv4.1 Recallable Object Types Registry" Recallable Object Type Name Value RFC How Minor Versions RCA4_TYPE_MASK_RDATA_DLG 0 RFCTBD10 N 1 RCA4_TYPE_MASK_WDATA_DLG 1 RFCTBD10 N 1 RCA4_TYPE_MASK_DIR_DLG 2 RFCTBD10 N 1 RCA4_TYPE_MASK_FILE_LAYOUT 3 RFCTBD10 N 1 RCA4_TYPE_MASK_BLK_LAYOUT 4 RFCTBD20 L 1 RCA4_TYPE_MASK_OBJ_LAYOUT_MIN 8 RFCTBD30 L 1 RCA4_TYPE_MASK_OBJ_LAYOUT_MAX 9 RFCTBD30 L 1 4] Creation of a new "pNFS Layout Types Registry" http://www.iana.org/assignments/nfs/pnfs-layout-types.xhtml Registry content description: A layout describes the mapping of a file's data to the storage devices that hold the data. A layout is said to belong to a specific layout type. The layout type allows for variants to handle different storage protocols, such as those associated with block/volume, object, and file layout types. New assignments to the registry: All assignments to the registry are made on a Standards Action basis, with Expert Review required. Guidelines for drafting Standards documents that propose additions to the registry are located in the document being reviewed for approval. Changes to assignments in the registry: The update of a registration will require IESG Approval on the advice of a Designated Expert. Registry entry rules: Layout types are 32 bit numbers. The value zero is Reserved. Values in the range 0x80000000 to 0xFFFFFFFF inclusive are reserved for Private Use. IANA will only assign numbers from the range 0x00000001 to 0x7FFFFFFF inclusive. Registry entry description: The registry is a list of assignments, each containing five fields per assignment. 1] The name of the layout type. This name must have the prefix: "LAYOUT4_". The name must be unique. 2] The value of the layout type. IANA will assign this number, and the request from the registrant will use TBD1 instead of an actual value. The value assigned must be unique. A Designated Expert must be used to ensure that when the name of the layout type and its value are added to the NFSv4.1 layouttype4 enumerated data type in the NFSv4.1 XDR description, the result continues to be a valid XDR description. 3] The Standards Track RFC(s) that describe the notification. If the RFC(s) have not yet been published, the registrant will use RFCTBD2, RFCTBD3, etc. instead of an actual RFC number. 4] How the RFC introduces the notification. This is indicated by a single US- ASCII value. If the value is N, it means a minor revision to the NFSv4 protocol. If the value is L, it means a new pNFS layout type. Other values can be used with IESG Approval. 5] The minor versions of NFSv4 that are allowed to the use the notification. While these are numeric values, IANA will not allocate and assign them; the author of the relevant RFCs with IESG Approval assigns these numbers. Each time there is new minor version of NFSv4 approved, a Designated Expert should review the registry to make recommended updates as needed. Initial Registry for the "pNFS Layout Types Registry" Layout Type Name Value RFC How Minor Versions LAYOUT4_NFSV4_1_FILES 0x1 RFCTBD10 N 1 LAYOUT4_OSD2_OBJECTS 0x2 RFCTBD30 L 1 LAYOUT4_BLOCK_VOLUME 0x3 RFCTBD20 L 1 5] Creation of a new "NFSv4 Path Variables Registry" http://www.iana.org/assignments/nfsv41/path-variables.xhtml Registry content description: These registrations are associated with the variable substitution feature for location names. Variables subject to substitution consist of a domain name and a specific name within that domain, with two separated by a colon. New assignments to the registry: When the domain name portion of the variable name is "ietf.org" all variables names must be registered with IANA on a Standards Action basis, with Expert Review required. Path variables with registered domain names neither part of nor equal to ietf.org are assigned on a Hierarchical Allocation basis (delegating to the domain owner) and are not registered by IANA, unless the domain owner chooses to register a variable name from his domain. If the domain owner chooses to do so, IANA will do so on a First Come First Serve basis. To accommodate registrants who do not have their own domain, IANA will accept requests to register variables with the prefix "${FCFS.ietf.org:" on a First Come First Served basis. Assignments on a First Come First Basis do not require Expert Review, unless the registrant also wants IANA to establish a registry for the values of the registered variable. Changes to assignments in the registry: The update of an assignment made on a Standards Action basis will require IESG Approval on the advice of a Designated Expert. The registrant can always updated the point of contact of an assignment made on a First Come First Serve basis. Any other update will require Expert Review. Registry entry rules: Variable names are of the form "${", followed by a domain name, followed by a colon (":"), followed by a domain-specific portion of the variable name, followed by "}". Registry entry description: The registry is a list of assignments, each containing three fields. 1] The name of the variable. The name of this variable must start with a "${" followed by a registered domain name, followed by ":", or it must start with "${FCFS.ietf.org". The name must be no more than 64 UTF-8 characters long. The name must be unique. 2] For assignments made on Standards Action basis, the Standards Track RFC(s) that describe the variable. If the RFC(s) have not yet been published, the registrant will use RFCTBD1, RFCTBD2, etc. instead of an actual RFC number. Note that the RFCs do not have to be a part of a NFS minor version. For assignments made on a First Come First Serve basis, an explanation (consuming no more than 1024 bytes) of the purpose of the variable. A reference to the explanation can be substituted. 3] The point of contact, including an email address. The point of contact can consume up to 256 bytes. For assignments made on a Standards Action basis, the point of contact is always IESG. Initial Registry for the "NFSv4 Path Variables Registry" Variable Name RFC Point of Contact ${ietf.org:CPU_ARCH} RFCTBD10 IESG ${ietf.org:OS_TYPE} RFCTBD10 IESG ${ietf.org:OS_VERSION} RFCTBD10 IESG 6] The "NFSv4 ${ietf.org:CPU_ARCH} Value Registry" and the "NFSv4 ${ietf.org:OS_TYPE} Value Registry" Registry content dscription: The "NFSv4 Path Variables Registry" to be located at: http://www.iana.org/assignments/nfsv41/path-variables.xhtml may have additional subregitries associated with the values of entries in the Path Variables registry. Upon approval of this document two such subregistries are created in the "NFSv4 Path Variables Registry" 6.1] The "NFSv4 ${ietf.org:CPU_ARCH} Value Registry". New Assignments to the SubRegistry: Assignments to the registry are made on a First Come First Serve basis. Changes to Assignments in the SubRegistry: The registrant is free to update the assignment, i.e. change the explanation and/or point of contact fields. SubRegistry entry rules: The zero length value of ${ietf.org:CPU_ARCH} is Reserved. Values with a prefix of "PRIV" are Reserved by IANA for Private Use. SubRegistry entry description: The registry is a list of assignments, each containing three fields. 1] A value of the ${ietf.org:CPU_ARCH} variable. The value must be 1 to 32 UTF- 8 characters long. The value must be unique. 2] An explanation (consuming no more than 1024 bytes) of what CPU architecture the value denotes. A reference to the explanation can be substituted. 3] The point of contact, including an email address. The point of contact can consume up to 256 bytes. Initial Registry for the "NFSv4 ${ietf.org:CPU_ARCH} Value Registry". There is no initial registry. 6.2] The "NFSv4 ${ietf.org:OS_TYPE} Value Registry". New Assignments to the SubRegistry Assignments to the registry are made on a First Come First Serve basis. Changes to Assignments in the SubRegistry: The registrant is free to update the assignment, i.e. change the explanation and/or point of contact fields. SubRegistry entry rules: The zero length value of ${ietf.org:OS_TYPE} is Reserved. Values with a prefix of "PRIV" are Reserved for by IANA Private Use. SubRegistry entry description: The registry is a list of assignments, each containing three fields. 1] A value of the ${ietf.org:OS_TYPE} variable. The value must be 1 to 32 UTF- 8 characters long. The value must be unique. 2] An explanation (consuming no more than 1024 bytes) of what CPU architecture the value denotes. A reference to the explanation can be substituted. 3] The point of contact, including an email address. The point of contact can consume up to 256 bytes. Initial Registry for the "NFSv4 ${ietf.org:OS_TYPE} Value Registry". There is no initial registry. |
2008-12-03
|
29 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-03
|
29 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-12-02
|
29 | Lisa Dusseault | [Ballot discuss] A bunch of issues; it may be that none of them are serious and we'll clear this up quickly with some discussion, in … [Ballot discuss] A bunch of issues; it may be that none of them are serious and we'll clear this up quickly with some discussion, in which case I'll move to a COMMENT. 1. Doc says: "The base assumption with respect to minor versioning is that any future accepted minor version must follow the IETF process and be documented in a standards track RFC." Do the authors mean to imply IETF WG process? Or IETF Consensus process over a document? Might save grief if this is clearer. 2. The acronym SSV is not explained or even expanded until page 69: Secret State Verifier (SSV). THe difference between the state protection option and the GSS mechanism (or the relationship between them) is unclear. It's also not clear until several re-readings, that this was invented for NFS and doesn't reference some standard GSS mechanism in another RFC. This could be useful introductory material. 3. For pNFS: It would be good to have some examples of how NFS ACLs can work when clients are accessing data stores directly. What data store access protocols has this successfully worked with? Has it been other standards or proprietary stuff? Does implementation of pNFS depend on proprietary protocols between client and data store? Any more information on the implementation record here would be helpful. Section 12.9 is a little short on security considerations for pNFS. It requires the storage device access to be subject to access control consistent with the NFS ACLs, but it doesn't say how to identity users. What storage device protocols are compatible with NFS' user model? 4. I was looking for some more security considerations of the grace period. Can a bad client take advantage of the grace period to commit changes that weren't the client's in the first place, or to take over locks that it didn't have? How much information does the server need to keep to prevent this? 5. The stringprep and nameprep building blocks are no longer used by the community that developed them (IDNA). I am not sure if there are problems with the approach, or if the lack of maintenance would be problematic for NFS. If the WG is aware of this then I would say there is no issue. 6. Some behaviors are specified by reference to POSIX or left unspecified. For example, there are mentions of hard and soft links but no definitions or requirements on the behavior of links (not even a mention of POSIX in this context). Another comparison is to fsync() which at another point is mentioned as being a POSIX operation. Even where there is a reference to POSIX it doesn't actually point to a normative reference document as far as I can tell. One example from 18.3.4: "If the server receives a full file COMMIT request, that is starting at offset 0 and count 0, it should do the equivalent of fsync()'ing the file." |
2008-12-02
|
29 | Lisa Dusseault | [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault |
2008-12-02
|
29 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-12-02
|
29 | Lars Eggert | State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead::Revised ID Needed by Lars Eggert |
2008-11-30
|
29 | Russ Housley | [Ballot comment] The Gen-ART and Transport review from David Black provides some useful comments. They should be addressed if the document is updated. |
2008-11-30
|
29 | Russ Housley | [Ballot discuss] Given the length of this document, I am very pleased that David Black was able to perform a Gen-ART and Transport review. … [Ballot discuss] Given the length of this document, I am very pleased that David Black was able to perform a Gen-ART and Transport review. He caught one very important problem. The review says: > > Section 5.10 on character case for Unicode references a very > old RFC (RFC 1345) and provides a case determination algorithm > (substring match on "CAPITAL" or "SMALL" in a Unicode character > name) that is wrong and potentially dangerously so. This > section needs to be rewritten to reference a Unicode document > that defines the notion of case for a particular version of > Unicode. The good news is that everything needed to get this right > is in Section 14's profiles of "stringprep" (Unicode 3.2 is > referenced from Section 14 via RFC 3454), so a small rewrite of > Section 5.10 to remove the case determination algorithm and > direct the reader to Section 14 for all internationalization > details will probably fix this. I would remove the reference > to RFC 1345 as part of this. |
2008-11-30
|
29 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2008-11-28
|
29 | Lars Eggert | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Lars Eggert |
2008-11-28
|
29 | Lars Eggert | David Black's review requires a response and will likely require a revision. |
2008-11-27
|
29 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-11-22
|
29 | Lars Eggert | [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert |
2008-11-22
|
29 | Lars Eggert | Ballot has been issued by Lars Eggert |
2008-11-22
|
29 | Lars Eggert | Created "Approve" ballot |
2008-10-21
|
29 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Nicolas Williams |
2008-10-21
|
29 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Nicolas Williams |
2008-10-14
|
29 | Lars Eggert | Tentatively putting this on the 2008-12-04 agenda as an early warning to others to keep the agenda otherwise light. |
2008-10-14
|
29 | Lars Eggert | Tentatively putting this on the 2008-12-06 agenda as an early warning to others to keep the agenda otherwise light. |
2008-10-14
|
29 | Lars Eggert | Placed on agenda for telechat - 2008-12-04 by Lars Eggert |
2008-09-23
|
29 | Cindy Morgan | Last call sent |
2008-09-23
|
29 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2008-09-22
|
29 | Lars Eggert | Last Call was requested by Lars Eggert |
2008-09-22
|
29 | Lars Eggert | State Changes to Last Call Requested from AD Evaluation by Lars Eggert |
2008-09-22
|
29 | (System) | Ballot writeup text was added |
2008-09-22
|
29 | (System) | Last call text was added |
2008-09-22
|
29 | (System) | Ballot approval text was added |
2008-09-19
|
29 | Lars Eggert | Brian Pawslowski (beepy@netapp.com) is the document shepherd, although the document writeup names Spencer Shepler - but Spencer is a co-editor. |
2008-09-19
|
29 | Lars Eggert | [Note]: 'Brian Pawslowski (beepy@netapp.com) is the document shepherd. ' added by Lars Eggert |
2008-09-19
|
29 | Lars Eggert | State Changes to AD Evaluation from Publication Requested by Lars Eggert |
2008-09-19
|
29 | Lars Eggert | AD evaluation happened during WG LC. |
2008-09-19
|
29 | Lars Eggert | State Change Notice email list have been change to nfsv4-chairs@tools.ietf.org, draft-ietf-nfsv4-minorversion1@tools.ietf.org from nfsv4-chairs@tools.ietf.org |
2008-09-18
|
29 | Cindy Morgan | Intended Status has been changed to Proposed Standard from None |
2008-09-18
|
29 | Cindy Morgan | State Changes to Publication Requested from AD is watching by Cindy Morgan |
2008-09-18
|
29 | Cindy Morgan | (1.a) Who is the Document Shepherd For this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd For this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Spencer Shepler. Spencer has reviewed the documents and believes they are ready for publication. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received formal review/walk-throughs in combination with an extended working group last call. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns exist. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No such concerns exist. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? There is consensus within the NFSv4 working group. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Yes. Are the IANA registries clearly identified? Yes. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? Yes. See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? N/A (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This Internet-Draft describes NFS version 4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version one include: Sessions, Directory Delegations, and parallel NFS (pNFS). Working Group Summary This document is the result of long construction, review, and prototyping. While not all features of NFSv4.1 have been prototyped or implemented the mainline features have received reasonable prototyping. Document Quality The NFSv4.1 specification was subjected to a series of formal reviews or walk-throughs that resulted in close review and resultant issues and resolutions. As a result, the NFSv4.1 documents are complete and of reasonably high quality. |
2008-09-05
|
26 | (System) | New version available: draft-ietf-nfsv4-minorversion1-26.txt |
2008-08-20
|
25 | (System) | New version available: draft-ietf-nfsv4-minorversion1-25.txt |
2008-08-06
|
24 | (System) | New version available: draft-ietf-nfsv4-minorversion1-24.txt |
2008-05-12
|
23 | (System) | New version available: draft-ietf-nfsv4-minorversion1-23.txt |
2008-05-01
|
22 | (System) | New version available: draft-ietf-nfsv4-minorversion1-22.txt |
2008-02-25
|
21 | (System) | New version available: draft-ietf-nfsv4-minorversion1-21.txt |
2008-02-25
|
20 | (System) | New version available: draft-ietf-nfsv4-minorversion1-20.txt |
2008-01-29
|
19 | (System) | New version available: draft-ietf-nfsv4-minorversion1-19.txt |
2007-12-22
|
18 | (System) | New version available: draft-ietf-nfsv4-minorversion1-18.txt |
2007-11-19
|
17 | (System) | New version available: draft-ietf-nfsv4-minorversion1-17.txt |
2007-11-12
|
16 | (System) | New version available: draft-ietf-nfsv4-minorversion1-16.txt |
2007-10-31
|
15 | (System) | New version available: draft-ietf-nfsv4-minorversion1-15.txt |
2007-09-25
|
14 | (System) | New version available: draft-ietf-nfsv4-minorversion1-14.txt |
2007-08-13
|
13 | (System) | New version available: draft-ietf-nfsv4-minorversion1-13.txt |
2007-07-12
|
12 | (System) | New version available: draft-ietf-nfsv4-minorversion1-12.txt |
2007-06-15
|
11 | (System) | New version available: draft-ietf-nfsv4-minorversion1-11.txt |
2007-03-06
|
10 | (System) | New version available: draft-ietf-nfsv4-minorversion1-10.txt |
2007-03-05
|
09 | (System) | New version available: draft-ietf-nfsv4-minorversion1-09.txt |
2006-10-25
|
08 | (System) | New version available: draft-ietf-nfsv4-minorversion1-08.txt |
2006-10-05
|
07 | (System) | New version available: draft-ietf-nfsv4-minorversion1-07.txt |
2006-08-25
|
06 | (System) | New version available: draft-ietf-nfsv4-minorversion1-06.txt |
2006-08-15
|
05 | (System) | New version available: draft-ietf-nfsv4-minorversion1-05.txt |
2006-07-21
|
04 | (System) | New version available: draft-ietf-nfsv4-minorversion1-04.txt |
2006-06-22
|
03 | (System) | New version available: draft-ietf-nfsv4-minorversion1-03.txt |
2006-06-12
|
29 | Lars Eggert | Draft Added by Lars Eggert in state AD is watching |
2006-03-09
|
02 | (System) | New version available: draft-ietf-nfsv4-minorversion1-02.txt |
2005-12-13
|
01 | (System) | New version available: draft-ietf-nfsv4-minorversion1-01.txt |
2005-10-21
|
00 | (System) | New version available: draft-ietf-nfsv4-minorversion1-00.txt |