Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-minorversion1-29

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

[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".

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

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

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

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

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

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

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

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.

[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."

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

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