Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS)
draft-ietf-precis-problem-statement-09

Well done.  I've a number of non-blocking comments:

The shepherd writeup says this:
   Given that the document itself is informative, no normative 
   references were appropriate and all of the references are 
   informative. 

I think this is wrong.  Normative references are those that are necessary to the understanding of the document at hand, and they exist even for Informational documents.  In this case, I think the following are normative:
Stringprep [RFC3454]
IDNA Rationale [RFC5894]

You should probaby scrub this for consistent use of "Stringprep" (vs "stringprep").

-- Section 1 --
In the list of known Stringprep uses, I would find it easier to read and more convenient if items based on the same profile were grouped in sub-bullets.  Something like this (significantly abbreviating here):

o  The Nameprep profile
   o  IAX using Nameprep
o  NFSv4 and NFSv4.1
o  The iSCSI profile
o  The Nodeprep and Resourceprep profiles
o  The SASLprep profile
   o  IMAP4 using SASLprep
   o  Plain SASL using SASLprep
   o  NNTP using SASLprep
o  The LDAP profile
   o  PKIX subject identification using LDAPprep
   o  PKIX CRL using LDAPprep
o  The unicode-casemap Unicode Collation

Then you can also note that in the following paragraph like this:
NEW
   Moreover, many reuse the same
   Stringprep profile, such as the SASL one,
   as can be seen from the groupings above.

OLD
   This algorithm is based
   on an inclusion-based approach
NEW
   This algorithm uses
   an inclusion-based approach

-- Section 4 --
   For example, Stringprep is based on and profiles may
   use NFKC [UAX15], while IDNA2008 mostly uses NFC [UAX15].

Because of the citations and because it's not central to what you're saying, I don't think it's necessary to expand NFKC and NFC.  But it might be helpful to say something like, "for example, for normalization Stringprep [...]"

   a localpart which is similar to a username and used
   for authentication, a domainpart which is a domain name and a
   resource part which is less restrictive than the localpart.

Because of the complexity of this and the imbedded "and" in the first item, this list really demands the Oxford comma, "domain name, and".  I'm not sure the RFC Editor will get it right.

-- Section 5.2.6 --
Is "phishing" now a sufficiently common and lasting term that we can use it without explanation?  In any case, in the next sentence the issue *is* to be considered (not "are").

-- Section 7 --
To address the SecDir review comment, you might add something like this: "See the Stringprep Security Considerations, [RFC3454] Sevtion 9.  See also the analyses in the subsections of Appendix B, below.'