Subject: [Sandbox-mailoutput] [Django development] Evaluation: <draft-ietf-precis-framework-22.txt> to Proposed Standard

From: IETF Secretariat <[email-masked]>
Date: Sun, 08 Feb 2015 20:38:26 -0800

The attached message would have been sent, but the tracker is in development mode.
It was not sent to anybody.

Subject: Evaluation: <draft-ietf-precis-framework-22.txt> to Proposed Standard
From: IESG Secretary <[email-masked]>
To: "IANA" <[email-masked]>
Date: Sun, 08 Feb 2015 20:38:26 -0800

Evaluation for <draft-ietf-precis-framework-22.txt> can be found at
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

Last call to expire on: 2015-02-19 00:00

        Please return the full line with your position.

                      Yes  No-Objection  Discuss  Abstain
Adrian Farrel        [   ]     [ X ]      [   ]    [   ]     
Alissa Cooper        [   ]     [ X ]      [   ]    [   ]     
Barry Leiba          [ X ]     [   ]      [   ]    [   ]     
Benoit Claise        [   ]     [ X ]      [   ]    [   ]     
Brian Haberman       [   ]     [ X ]      [   ]    [   ]     
Jari Arkko           [   ]     [ X ]      [   ]    [   ]     
Joel Jaeggli         [   ]     [ X ]      [   ]    [   ]     
Kathleen Moriarty    [   ]     [ X ]      [   ]    [   ]     
Martin Stiemerling   [   ]     [ X ]      [   ]    [   ]     
Pete Resnick         [ X ]     [   ]      [   ]    [   ]     
Richard Barnes       [   ]     [ X ]      [   ]    [   ]     
Spencer Dawkins      [   ]     [ X ]      [   ]    [   ]     
Stephen Farrell      [   ]     [ X ]      [   ]    [   ]     
Ted Lemon            [   ]     [ X ]      [   ]    [   ]     

Has enough positions to pass.

DISCUSSES AND COMMENTS
======================
Adrian Farrel:

Comment [2014-04-22]:
Not my area of expertise, but ... :-)

Why isn't BCP18 an important reference?

Alissa Cooper:

Comment [2014-04-21]:
Nice work. I have one comment in Section 4.3, which says:

One consequence of disallowing space characters in the
   IdentifierClass might be to effectively discourage the use of ASCII
   space (or, even more problematically, non-ASCII space characters)
   within identifiers created in newer application protocols; given the
   challenges involved in properly handling space characters in
   identifiers and other protocol strings, the Working Group considered
   this to be a feature, not a bug.

I find the use of the phrase “even more problematically” confusing given that
it comes after “to effectively discourage.” I think the intended meaning here
is that if non-ASCII space characters were to be used (or _encouraged_), that
would be even more problematic than if ASCII space characters were to be used
(or encouraged), right? I would suggest the following edit to the first part of
the first sentence:

One consequence of disallowing space characters in the
   IdentifierClass might be to effectively discourage the use of ASCII
   space (or the even more problematic non-ASCII space characters)
   within identifiers created in newer application protocols;

Barry Leiba:

Comment [2014-04-24]:
After discussion, I'm moving this to a non-blocking comment.  I still think
that the working group and the responsible AD did not handle this right, and
strongly urge not repeating this mechanism in future.

The registry created in Section 9.1 is very odd indeed.  I guess IANA is
expected to assume that the format of the registry will look like the
non-normative table in the appendix, but Section 9.1 doesn't say what the
format of the registry will be.  In the IANA review, it's clear that they're
not sure what's going to happen here.

But the real oddity here is that the specification of the registry involves an
*enormous* startup cost for the designated expert, *and* requires that the DE
be appointed and start her work immediately.  Normally, IANA takes the required
actions as soon as the document's approval is announced, but in this case they
will have to wait for the DE to be appointed and to derive the entire content
of the registry.

It seems to me that the right way to have handled this would have been for the
working group to have engaged the appropriate experts and made the table
Appendix A *be* the initial contents of the registry, rather than explicitly
denouncing Appendix A and leaving it as a seemingly quite onerous startup task
that will delay the IANA actions indefinitely.

Why was it done this way, and what is the plan to get the registry content
specified in a reasonable time?  Should approval of the document wait for that
content to be specified?  Or are we really expecting to approve the document
with the content of the registry left open?

UPDATE AFTER DISCUSSION:
The response to my final questions says that IDNAbis did it this way, the
intent is to use the same expert as for that registry, and it's not expected to
be terribly burdensome.

It's good to hear that it won't be burdensome, but it still seems that the
working group produced an incomplete document.  The right way to have handled
this would have been to involve the appropriate experts near the end of the
working group's process, and to get the table in Appendix A to be the initial
registration data, already vetted by the expert.  That way, the instructions to
IANA would be clear, and the IETF and the IESG would be reviewing the complete
picture.  When the document is approved and IANA creates the registry, they
will contact the authors to confirm that it's all correct, at which point the
authors would ask the expert to check it again.  It's unlikely that there'd be
any changes needed in the roughly four weeks between IETF last call and
document approval, and given that the expert you intend to recruit is also our
liaison to the Unicode Consortium, he could confirm that they are not working
on any updates just now.

As it stands, what the working group seems to be saying is that they don't have
the expertise to get this right, and can't get the right experts involved...
which, in any other context, we would push back on very hard, indeed.

Benoit Claise:

Comment [2014-04-24]:
- More of a series of question than a COMMENT. Disclaimer: the PRECIS work is
very far from my comfort zone, so there might be a little bit of eduction
involved here.

You have identified IdentifierClass and FreeformClass.
As OPS AD, I'm wondering whether future OPS data models should take these
classes into account.
Let me explain. We have:
	SMI Textual Convention (RFC 2579). For example: SnmpAdminString
	YANG typedef (https://tools.ietf.org/html/rfc6020#section-7.3)
	IPFIX data types (RFC 7011)
	AAA 
Should we ideally start specifying our data model strings according to these
classes, to facilitate strings comparison operations? Should we start defining
new SMI TC, YANG typedef, or IPFIX data types? Is there some education required
in OPS? 
I guess that there is no action for the authors at this point, and the next
step is an informal discussion with Pete. 

-
https://datatracker.ietf.org/doc/draft-ietf-precis-framework/shepherdwriteup/
      There is a normative downref to draft-ietf-precis-mappings (an
Informative document).
I see that draft-ietf-precis-mappings in the informative references.

Kathleen Moriarty:

Comment [2014-04-22]:
Thanks for addressing the SecDir comments so quickly!

Pete Resnick:

Comment [2014-04-18]:
The following are all items I mentioned in my AD Eval, but we decided none was
a show-stopper and all could be held until the end of Last Call. The only
substantive point is on 4.1.5, and the world will not end if I end up in the
rough on this point. (We don't expect a whole lot of feedback during Last Call;
the document got a good deal of review by a lot of experts, but the topic is
pretty esoteric for anyone else to have much of a strong opinion.)

Throughout: Change "Informational Note:" to "Note:". I don't see any of them
for which it makes a difference.

3.1: I would move the first paragraph down further in the section. And I would
delete the parenthetical at the end of "Contextual Rule Required"; no need to
introduce undefined terms here.

3.2.4 and 3.3.4: The SHALLs in here seem weird to me. Above, you don't say that
a string with a Disallowed character "SHALL be rejected". If it were me, I'd
simply say:

   Any code points that are not yet designated in the Unicode character
   set are considered Unassigned for purposes of the XXXClass, and such
   code points are to be treated as Disallowed.

4.1:

Change "MUST register" to "are registered". MUSTs for registration seem silly.
(If you want to say, "Implementations MUST NOT use unregistered classes", you
could, but I don't think you want to do that.)

Change "It is RECOMMENDED for profile names to be of the form" to "The naming
convention for profile names is to use the form".

4.1.5: I'm not thrilled with this section in general, but in particular I'm not
sure what "mixed-direction strings are not supported" means. We do know how to
process strings that contain characters with a mix of directionality. Such
strings are sometimes a visual challenge, but not a processing challenge: The
RFC 5893 Bidi Rule exists because IDNs want to be visually stable in either an
LTR or RTL context, and because IDNs use "." as a label separator yet want to
have text display consistent in a context that is unaware of labels. There are
perfectly reasonable cases where none of these hold true, so I think this
section could be softened so that it's not overtly pushing that protocols never
allow mixed direction text or that they should always lean toward using RFC
5893. 

4.2: A bit of ABNF neatening:

OLD
      fullname = namepart [1*(1*SP namepart)]
      namepart = 1*(idpoint)
NEW
      fullname = namepart *(1*SP namepart)
      namepart = 1*idpoint

9.2: It might be nice to add section numbers (3.2 and 3.3) to the registrations
for IdentifierClass and FreeformClass.

9.3: It might be nice to note the naming convention from 4.1 in the template.

Stephen Farrell:

Comment [2014-04-24]:

- I agree with Bary's discuss - it seems weird to not
have the initial registries in hand when the RFC is
being issued. People will, I guess, implement from
Appendix A here anyway, so why not either delete this
and get the registry in place, or else make Appendix A
be the initial registry content.

7.7: This uses the empty set, which is puzzling. I think
you mean that this set is to be populated by the DE in
the IANA registries but if so, saying so would be good.

10.5: This says that a) its all too hard but also b)
"Nevertheless, specifications for application protocols
that use this framework MUST describe how confusable
characters can be abused to compromise the security of
systems that use the protocol in question, along with any
protocol-specific suggestions for overcoming those
threats." That seems like a 6919 MUST (but we know you
won't) to me. Is that a good plan? 

10.6: Prompted by the secdir review, it might be worth a
few words on password hashing, which is very common.  E.g.
say that the canonical form is input to hashing and
therefore just can't be mucked about with. (But say that
nicely:-)

Ted Lemon:

Comment [2014-04-23]:
In section 6, last paragraph, the reference to [UNICODE] would be more helpful
if it said (see Chapter 4 of [UNICODE]), similar to later references in section
7.

Aside from that, this is an excellent attempt to provide a basis for unraveling
the gordian knot of unicode use in standards, and I look forward to seeing how
it works in practice.


---- following is a DRAFT of message to be sent AFTER approval ---
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: RFC Editor <[email-masked]>,
    precis mailing list <[email-masked]>,
    precis chair <[email-masked]>
Subject: Protocol Action: 'PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols' to Proposed Standard (draft-ietf-precis-framework-15.txt)

The IESG has approved the following document:
- 'PRECIS Framework: Preparation and Comparison of Internationalized
   Strings in Application Protocols'
  (draft-ietf-precis-framework-15.txt) as Proposed Standard

This document is the product of the Preparation and Comparison of
Internationalized Strings Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-precis-framework/

Technical Summary

Testing Application protocols using Unicode characters in protocol strings
need to properly prepare such strings in order to perform valid
comparison operations (e.g., for purposes of authentication or
authorization).  This document defines a framework enabling
application protocols to perform the preparation and comparison of
internationalized strings ("PRECIS") in a way that depends on the
properties of Unicode characters and thus is agile with respect to
versions of Unicode.  

Working Group Summary

The WG spent some time deciding how many classes need to be defined
and what kind of class is suitable for "profiling" for different purposes.
In particular the discussion of use of spaces in Identifier class took a bit
of time. But the WG converged at the end.

Document Quality

The approach used by the document is similar to IDNA 2008 approach
(use of Unicode character properties for deciding what to do with characters)
and thus wasn't controversial.

Several protocols intend to use the framework described in this
document, and people from different working groups have been
contributing to this work, including folks involved in iSCSI and
RADIUS.

Personnel

The document shepherd is Alexey Melnikov.
The responsible Area Director is Pete Resnick.