Network File System (NFS) Version 4 Minor Version 1 Protocol
Note: This ballot was opened for revision 29 and is now closed.
(Lars Eggert) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) (was Discuss) No Objection
(Pasi Eronen) No Objection
Comment (2008-12-04 for -** No value found for 'p.get_dochistory.rev' **)
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".
(Russ Housley) (was Discuss) No Objection
The Gen-ART and Transport review from David Black provides some useful comments. They should be addressed if the document is updated.
(Cullen Jennings) No Objection
(Chris Newman) (was Discuss) No Objection
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.