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. - +1 (858)651-4478