Subject: Re: [precis] Basic issues with framework-17

From: Pete Resnick <[email-masked]>
Date: Tue, 22 Jul 2014 13:35:16 -0400

John and I talked today about how to solve our impasse with the PRECIS 
framework document. I think we have reached a mutually tolerable (note 
that I didn't say "agreeable") path forward:

The key issue for John is the differences between IDNA and PRECIS rules. 
If a change to Unicode occurs, the Designated Expert(s) for IDNA and 
PRECIS (which will likely be the same person(s)) will have to separately 
figure out the impact of the change to IDNA and PRECIS and update the 
rules (and tables) for each accordingly. Without guidance in the 
document as to what those differences are, the job of updating becomes 
significantly harder.

So, the thing we can do (short of restructuring the document) that will 
address John's concern is to add some prose that describes how each of 
the PRECIS Classes differs from the IDNA rules so that a Designated 
Expert who is looking at any Unicode change can figure out what impact 
it has on each of the rule sets in one pass and can update them 
accordingly. That seems to me a perfectly reasonable approach, and will 
unstick this document in a way that John can live with and will give 
other protocols, which are now waiting, *something* to refer to.

Thoughts? Comments?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 Jul 2014 11:54:14 -0600

> that I didn't say "agreeable") path forward:

Thanks to you both for putting your time and energy into finding a solution.

> The key issue for John is the differences between IDNA and PRECIS rules.

Clarifying question: (a) the borrowing of IDNA rules in the PRECIS 
framework, including possible synchronization issues or (b) the 
additional rules that PRECIS defines above and beyond the borrowed 
rules, and the interaction between the PRECIS-specific rules and the 
existing IDNA rules?

I think that the PRECIS registry must not include the IDNA rules. 
Instead, the PRECIS framework document needs to point to the IDNA rules 
by reference - we included them in the document only for ease of 
reading, but if it would be less confusing to simply reference them then 
I'm fine with that!

> document as to what those differences are, the job of updating becomes

Yes, let's avoid that fate.

> other protocols, which are now waiting, *something* to refer to.

That does seem like a tolerable path forward. IMHO ideally we'd have one 
registry of Unicode-based rules, but this is the next-best thing.

BTW I am not averse to restructuring the PRECIS framework document if 
necessary.

And I am still committed to addressing the other feedback that John 
provided. All of it was extremely helpful, but it takes focused time to 
address such feedback and I've had very little of that lately.

Peter

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 22 Jul 2014 14:16:39 -0400

Le 2014-07-22 à 13:35, Pete Resnick <[email-masked]> a écrit :

> John and I talked today about how to solve our impasse with the PRECIS framework document. I think we have reached a mutually tolerable (note that I didn't say "agreeable") path forward:
> 
> The key issue for John is the differences between IDNA and PRECIS rules. If a change to Unicode occurs, the Designated Expert(s) for IDNA and PRECIS (which will likely be the same person(s)) will have to separately figure out the impact of the change to IDNA and PRECIS and update the rules (and tables) for each accordingly. Without guidance in the document as to what those differences are, the job of updating becomes significantly harder.
> 
> So, the thing we can do (short of restructuring the document) that will address John's concern is to add some prose that describes how each of the PRECIS Classes differs from the IDNA rules so that a Designated Expert who is looking at any Unicode change can figure out what impact it has on each of the rule sets in one pass and can update them accordingly. That seems to me a perfectly reasonable approach, and will unstick this document in a way that John can live with and will give other protocols, which are now waiting, *something* to refer to.
> 
> Thoughts? Comments?

I'm fine with adding some text to resolve the issue. However, I would say:
- maybe it will be better to have different experts so that they look at the problem with different eyes (in this context, more eyes is a feature). but they would be better to coordinate. not sure it needs to be  written
- the guideline document is a milestone of precis, and might be a good place to expand this issue.

so fine to me.

Marc.

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Jul 2014 14:27:42 -0400

> - maybe it will be better to have different experts so that they look at the problem with different eyes (in this context, more eyes is a feature). but they would be better to coordinate. not sure…

I think it would be _terrible_ to have different experts here, unless
there's an interlock between then registries.  If there are two
experts, they might draw different conclusions.  Indeed, John, Patrik,
and I all came to different conclusions about the most recent version
of Unicode, and it was only after considerable discussion that Patrik
and I understood what John was worried about.  Different decisions
between the experts would be extremely bad.

I know there's a hurry to get this out, but hoping the experts get it
right if there's no interlock is too dangerous.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 23 Jul 2014 07:12:56 +0200

> right if there's no interlock is too dangerous.

Being the appointed expert for IDNA, I would like to say I would LOVE to have a 2nd person for among other reasons the reasons Andrew list above.

That said, I think the appointed experts should get instructions to _communicate_with_each_other_ (!!!) and synchronize in a coordinated way with IANA. This to solve the issues I think Pete was thinking of addressing by having one and only one person.

I am expert on IDNA, and possibly one person with clue on Unicode.

Not Precis.

But with that knowledge, of course I am happy to continue to help IETF as much as I can.

   Patrik

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 23 Jul 2014 06:35:29 -0400

Le 2014-07-22 à 14:27, Andrew Sullivan <[email-masked]> a écrit :

> and I understood what John was worried about.  

For the same reasons, I come to the other conclusion: another expert will be good to have another set of eyes to carefully look at the unicode changes.  They just need to coordinate themselves. And very likely, the two experts know each other very well...   I'm not concerned too much about a lock where they will have a different opinion on the result. At that time, they could go to the wg(s) to further discussion and come to agreement.

Marc.

> Different decisions

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jul 2014 07:01:08 -0400

--On Wednesday, 23 July, 2014 07:12 +0200 Patrik Fältström
<[email-masked]> wrote:

>>> - maybe it will be better to have different experts so that
>>> they look at the problem with different eyes (in this
>>> context, more eyes is a feature). but they would be better
>>> to coordinate. not sure it needs to be  written
>> 
>> I think it would be _terrible_ to have different experts
>> here, unless there's an interlock between then registries.
>> If there are two experts, they might draw different
>> conclusions.  Indeed, John, Patrik, and I all came to
>> different conclusions about the most recent version of
>> Unicode, and it was only after considerable discussion that
>> Patrik and I understood what John was worried about.
>> Different decisions between the experts would be extremely
>> bad.
>> 
>> I know there's a hurry to get this out, but hoping the
>> experts get it right if there's no interlock is too dangerous.
> 
> Being the appointed expert for IDNA, I would like to say I
> would LOVE to have a 2nd person for among other reasons the
> reasons Andrew list above.
> 
> That said, I think the appointed experts should get
> instructions to _communicate_with_each_other_ (!!!) and
> synchronize in a coordinated way with IANA. This to solve the
> issues I think Pete was thinking of addressing by having one
> and only one person.
> 

Let me suggest that everyone quoted above is correct, but the
solution is a little bit different.

I think the solution, hinted at in Andrew's note, is that "the
expert"  be a team of several people, with different but
complementary knowledge, working together to conduct a review
for IDNA and PRECIS together.  They are finished only when they
agree, either that no changes are needed or on a single set of
changes.
  
We have now discovered a Unicode change issue that requires
careful human attention to detect and that cannot possibly be
detected by simple running of different implementations of a
test suite/ validation procedure.  When we set up the expert
procedure IDNA2008, we assumed that table-running with
independent implementations would be all that is necessary, but
that was based on assumptions that weren't true (sorry, but
anyone who wants to understand that case needs to read
draft-klensin-idna-5892upd-unicode70 -- I'd recommend waiting
for -01, which should show up sometime next week (possibly
sooner) with some additional clarifications).   Because the
algorithms are not sufficient (tghey are still necessary and
very important), the need for multiple people, with multiple
perspectives, to look carefully at new Unicode versions should
be clear.

I think experience from this round indicates that that expert
pool be at least three people (again, with different backgrounds
and perspectives).  Probably more than five would become
unwieldy.  

Because we seem to have disagreement on this subject, I believe
there is now a requirement that the "IANA Considerations"
section of "precis-framework" specify explicitly that:

	* There must be an expert team (or one expert and
	designated advisors), appointed as usual by the IESG,
	with at least three members, with diverse backgrounds
	and a recommended upper limit on membership of five or
	six.
	
	* That expert team is responsible for the reviews
	required by both PRECIS and IDNA, precisely because the
	base rules and categories, are expected/required  to be
	the same (note Peter's comment yesterday that, if the
	copies of the rules and categories used in PRECIS IDNA
	were different from those of IDNA, that was a bug that
	needed fixing).
	
	* The experts are finished, and IETF protocols ready to
	safely use a new version of Unicode, without risk of
	strings that are valid being disallowed, only when they
	agree (even if that agreement requires agreeing to
	disagree on details but move forward).

I'm happy to work with Peter on specific text for the document
if needed.

I can't stress how important this is.  If we don't have
agreement on it, some assumptions that were critical to
yesterday's agreement and consensus are false and the consensus
is meaningless.

If we have different experts with nearly-final authority for
different protocols, it takes us back into exactly the situation
we discussed yesterday -- the base exception lists, tables, and
allowable characters of IDNA and PRECIS will diverge (whether
they are the same today or not).  That is different from the
"profiles", which I would like to think of as per-protocol
exception lists from a base category and rule collection, being
different -- that latter is something we have to live with for
historical or specialty reasons.   If our intent is to design
things to allow that divergence to occur, then yesterday's
discussions about avoiding divergence for user confusion and
maintainability reasons and maybe the one about having a clear
interface for applications developers haven't had any effect,
perhaps suggesting that some of those who agreed to them didn't
understand them.

   regards,
     john

 (even, if PRECIS persists in establishing mappings, pro

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Jul 2014 09:10:59 -0400

> section of "precis-framework" specify explicitly that:

FWIW, rather than saying "we have disagreement" I'd say instead we
have agreement on the problem and a little bit of disagreement on the
mechanism.  I'm ok with John's proposal, but I'm slightly worried
about this setting up IANA to decide whether the experts are in fact
doing the right thing for more than one protocol at the same time,
given that the IANA registries are going to be different.  I'd want to
think about whether that is asking IANA to make substantive
determinations.  I don't have a fully formed opinion right now.

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Jul 2014 09:56:30 -0400

--On Wednesday, 23 July, 2014 09:10 -0400 Andrew Sullivan
<[email-masked]> wrote:

>> Because we seem to have disagreement on this subject, I
>> believe there is now a requirement that the "IANA
>> Considerations" section of "precis-framework" specify
>> explicitly that:
> 
> FWIW, rather than saying "we have disagreement" I'd say
> instead we have agreement on the problem and a little bit of
> disagreement on the mechanism.  I'm ok with John's proposal,
> but I'm slightly worried about this setting up IANA to decide
> whether the experts are in fact doing the right thing for more
> than one protocol at the same time, given that the IANA
> registries are going to be different.  I'd want to think about
> whether that is asking IANA to make substantive

Two quick thoughts:

(1) I am, again, suggesting one expert team for the base
categories and rules, not two.  If they can't figure out whether
they are in agreement and therefore how to give IANA a coherent
set of instructions, IAIA doesn't have a problem, the IESG does.

(2) I don't have an opinion as to whether separate registries
and reviewers/experts are needed to each "profile".  I hope not
but, if the answer is that we do, it is a separate issue
(possibly requiring different expertise) than getting the base
rules and categories right and may need a different set of
experts with a deep understanding of the applicable PRECIS-using
protocols.

(3)  I consider it an important corollary to yesterday's
discussion that we should be moving to (or evolving toward) a
single registry with sub-registries for things that are specific
to PRECIS and/or IDNA and/or PRECIS-related protocols.   As I
said in my earlier note, if the rules and categories that were
copied from IDNA2008 into precis-framework should be identical,
that should be easy -- even the non-normative derived tables
should be the same.  I don't have any reason to believe that
creating unified registries following those general principles
requires instructions to IANA more detailed than "we think it
would be a good idea and you have permission to do it".  YMMD.

    john