WRITEUP for draft-ietf-precis-problem-statement

The following comments were received during IESG evaluation and IETF calls and responses are included within . To note, of all of the comments received, none were blocking, none were asking for substantial changes.

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]

For the understanding of the document, it would require much more than just RFC3454, 5894. It would also
require Unicode understanding, internationalization terms understanding, stringprep profiles, etc… To a point
where most references become normative. So we disagree and did not include any separation of normative
and non-normative.

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

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

Stringprep Profiles are not necessarily exactly using another profile. They may (and do) have
variations, such as exceptions on their base profile or usage. Therefore, grouping might confuse the reader.
The listing was made by RFC number ordering. We agree that a better ordering would help reading. So we
change the ordering to have the similar profiles all together.

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

done

-- 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 […]"
done

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

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

-- 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.'
done

- Why do you have a temporary WG name in the draft title? Who will remember
what PRECIS is in 10 years from now? Proposal: 1. either explain PRECIS in the
draft. At the very minimum the acronym. 2. Or remove PRECIS: Stringprep
Revision Problem Statement 3. Alternatively, replace PRECIS: maybe "Stringprep
Revision and IDNA2008 Problem Statement"
Acronym expanded

- Why don't you refer to the latest version of the unicode, i.e. version 6.2?
The draft still refers to version 6.1.
While 6.1 and 6.2 versions may not differ too much, 6.1 was the one discussed during the work of this draft and given that this work has a lot of dependencies on what Unicode does or not, it is preferable to have the current Unicode version while the work was done to be the referenced one. So we are keeping 6.1 as the reference.

- You actually never explained what a (Stringprep) profile is, and what it
contains. For new comers who don't have the full IDNA background, a couple of
extra sentences would be welcome…
Actually, there is a sentence or two on what a profile is. Moreover, the Stringprep RFC is heavily referenced in the document. We are not sure what else could be added without copying a large amount of text from the Stringprep RFC, which is not really the purpose of the document. So we decline this one.

- What's the point to have a reference to [NEWPREP], since you don't mention
where they are?

During IETF 77 (March 2010), a BOF discussed the current state of the
protocols that have defined Stringprep profiles [NEWPREP].

[NEWPREP] "Newprep BoF Meeting Minutes", March 2010.
For the interest of a reader, that BOF included various presentations and meeting notes about the state of the protocols using Stringprep profiles. Therefore, the intent of the reference is to point the reader to additional context info useful for the understanding. The reference points to the Meeting Minutes that can be retreived from the IETF proceedings.

The list of Known IETF Specifications in the introduction is presented as a
complete list. I believe it is already a little stale (see RFC6063 for
example). Should the list be updated to those known specifications at the time
the RFC is published (and a datestamp added to qualify the statement), or
should the statement be softened to "Some known"?
added "Some" as suggested.

- 5.2.2 might have been a good place to explain what
normalization means. You can sort of get it from the
text, but might be nicer to add a definition.
This comment also applies to other internationalization terms used through the document. Normalization is defined more completly in RFC6365 ("Terminology Used in Internationalization in the IETF". Instead of copying multiple paragraphs, we added text and a reference for the reader to 6365.

Section 2 could be dropped as it isn't that important to have RFC
2119 in a problem statement.

The appendix that contains extracts of reviews and Stringprep profiles RFC do contain RFC2119 keywords. So we are keeping this section.

In Section 4:

"For example, Stringprep is based on and profiles may use NFKC
[UAX15], while IDNA2008 mostly uses NFC [UAX15]."
I suggest reviewing the references to see what background
information is required for the reader to understand "NFKC".

At the least, spelling out these acronyms on first use would be
helpful (e.g., "Unicode Normalization Form KC").

we expanded the acronyms as suggested by the document shepherd

In Section 6:

"The above suggests the following guidance for replacing
Stringprep: o A stringprep replacement should be defined."

That sounds obvious.
rephrased.

The appendix is more informative than the rest of the draft. The
text in the Appendix B comes out as rough notes though.

Indeed, that appendix consists of notes copied from a wiki page that
the PRECIS WG used to collect the information.

We agree with the document shepherd. no change to draft

In Section 5.3.3.2:

"It is important to identify the willingness of the protocol-using
community to accept backwards-incompatible changes."

The "tolerance for change" for several "protocol-using communities"
is rated as "not sure". I understand that it is difficult to get
definitive answers for these questions. It's doubtful that people
will choose "better support for different linguistic environments
against the potential side effects of backward incompatibility".
It seems that the WG has taken on an intractable problem.

Your conclusion does not follow. Yes, it is true that we're not sure
how willing some developer communities are to upgrade from Stringprep
(based on Unicode 3.2) to PRECIS (version-agile, currently Unicode
6.1). However, we know that some developer communities are in fact
willing to upgrade, and they have been more involved in the PRECIS WG.
Furthermore, in general applications don't have a choice about what
Unicode version is installed on the underlying system, so as time goes
by Stringprep will become more and more problematic. There was strong
agreement at the NEWPREP BoF to work on a common solution that all
Stringprep-using protocols could re-use. The approach taken in the
PRECIS framework specification is closely modelled on IDNA2008 and
follows the recommendations from RFC 4690. If you are going to
maintain that the PRECIS WG has taken on an intractable problem, then
I think you're also arguing that the IDNABIS WG took on an intractable
problem and that IDNA2008 failed to provide a viable solution to the
shortcomings of IDNA2003 and the Nameprep profile of Stringprep.

We agree with the document shepherd. no change to draft