Skip to main content

Network File System (NFS) Version 4 Minor Version 1 Protocol
RFC 5661

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