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

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.

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

  The Gen-ART and Transport review from David Black provides some useful
  comments.  They should be addressed if the document is updated.