Network File System (NFS) Version 4 Minor Version 1 Protocol
draft-ietf-nfsv4-minorversion1-29
Yes
Lars Eggert
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 29 and is now closed.
Lars Eggert
Yes
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
(2008-12-04)
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.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Dan Romascanu Former IESG member
No Objection
No Objection
()
David Ward Former IESG member
No Objection
No Objection
()
Jari Arkko Former IESG member
No Objection
No Objection
()
Jon Peterson Former IESG member
No Objection
No Objection
()
Lisa Dusseault Former IESG member
(was Discuss)
No Objection
No Objection
()
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Pasi Eronen Former IESG member
No Objection
No Objection
(2008-12-04)
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".
Ron Bonica Former IESG member
No Objection
No Objection
()
Ross Callon Former IESG member
No Objection
No Objection
()
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2008-11-30)
The Gen-ART and Transport review from David Black provides some useful comments. They should be addressed if the document is updated.
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()