Re: [precis] Last Call: <draft-ietf-precis-framework-15.txt> (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard

[Pete Resnick <[e-mail]>]

John,

Peter has had a start on answering these meat of the issues, and unless 
there are objections (by you, or anyone else), I'd ask that the 
remainder of the technical discussion be taken to the precis mailing 
list alone. That said, a couple process points that I think are 
appropriate to discuss here:

On 4/23/14 11:17 PM, John C Klensin wrote:

> I have deliberately waited until the end of the Last Call period
> as posted [1], hoping that you would get (or generate) more
> focused comments on the draft in the interim.

Please don't do that in the future. In this particular case (and mea 
culpa for this), I completely missed this note before the IESG telechat 
started, and wish we could have had this discussion going before the 
IESG got the document. In the end, the outcome is as per your first 
recommendation anyway:

> Recommendation: Tentatively approve the document now if that
> seems otherwise justified (I suggest below that it is not) but
> do not issue a Protocol Action Notice or handoff to the RFC
> Editor until after a sufficient number of of "profile
> replacements" and "guidelines" have been completed and examined
> through the IETF Last Call process to validate the "framework"
> provisions.

The IESG tentatively approved the document today, but it's announcement 
is contingent on a final review by me and a writeup. (In the 
datatracker, you'll see this recorded as "Approved::Point Raised".) I 
was going to do that anyway to deal with other comments that came up 
during AD Evaluation and Last Call, but I'll take your comments into 
account as well. If we end up in a place where I think we need to bring 
it back to the IESG, I can always do that.

But I do want to comment on the overall process issue:

> The issues
> discussed in this note were raised while what became the PRECIS
> WG (originally known by names like "Stringprep-bis") was being
> discussed and chartered and again on several occasions during
> the meetings of the WG.   At least in my opinion, they were
> never discussed seriously: the WG made one important improvement
> (shifting to a rule-based inclusion approach) but has
> essentially ignored the fundamental problem.  Because the
> predecessors of this note have not been actively considered in
> the WG or while its charter was being created, I don't actually
> expect it to accomplish anything other than to get some issues
> on the record.  But I think the circumstances require one last
> try.
>    

As much as we've failed in many ways to keep the spirit of our 
procedures alive, they do still exist. The IETF is *not* supposed to be 
another of the "formal review" SDOs where nothing happens until formal 
last calls and final reviews. We are supposed to be running a process 
where consensus is *built* during document creation, and importantly 
where failures are identified early and throughout the process, not 
late. Part of the way the IETF operates is that we *don't* wait until 
it's a big formal deal to address problems. Part of the social contract 
is that participants take responsibility for that and make their 
concerns known while consensus building is still going on. We talk a lot 
in the IESG about how to push things back earlier in the process, to not 
have late surprises and to not rely on things like formal DISCUSSes of 
the IESG for getting good work out of the IETF. Participants have to be 
part of that as well and use the tools we have to make sure that our 
process operates effectively.

RFC 2026, Section 6.5.1, defines what to do if a participant's views 
have not been adequately considered by the Working Group or that the 
Working Group has made an incorrect technical choice. In particular, the 
first step is to approach the chairs directly, at which point the chairs 
are supposed to figure out how to resolve the matter, bringing in other 
members of the WG (or the WG as a whole) when needed. If that doesn't 
work, *then* you bring that concern to the AD to attempt to resolve. 
(And of course, after that you can appeal to the IESG.)

The PRECIS WG has been discussing this document for round about three 
years. The WG made the decision to send this document to the IESG two 
months ago. I do not know whether you discussed this matter directly 
with the chairs, but I know that you have not discussed it directly with 
me. If you hadn't come to the conclusion that things had gone off the 
rails until recently, there's not much that you could have done 
differently, but my sense from your message is that you have had this 
concern for quite some time and that the WG has been missing it. 
(Indeed, I have been following PRECIS better than some of my WGs, and I 
know I've been in the room at f2f sessions, and *I* missed that you had 
this concern.)

This concern should have been escalated long ago. You should have 
followed 2026/6.5.1 and brought this to the chairs, and then to me as 
the AD if you weren't getting heard. The IETF only works when all 
participants take the responsibility to raise concerns during the 
process. If the senior members of the community aren't going to take 
that responsibility, why are we surprised when people are discouraged 
about how our processes work?

As I said, I'll review these concerns, and I'll take the document back 
to the IESG (or even the WG) if that is warranted. But this isn't the 
way the process is supposed to work.

Disappointedly,

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]