--On Tuesday, 20 December, 2005 18:50 -0800 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
>>> Having this point in this charter mostly serves as a
>>> statement of mistrust, rather than providing any useful
>>> education or constraint.
>>
>>...
> > Adding such a statement is all about education. It is
> perfectly
> > reasonable to not trust that newcomers will understand IETF
> policy;
> > heck, many folks who have been active for years don't.
>
> 1. You said you disagreed, but then provided an argument for
> not trusting participants ("people who do not understand the
> IETF rules".)
>...
Dave,
As I am sure you will recall, I've been very concerned since you
first proposed this about the notion of a WG that starts on the
assumption that almost all of the work is done and proven in the
field and that the IETF's role is limited to fine-tuning that
really does not change anything... unless the feature to be
changed is definitively proven to "not work". I believe that,
in situations that are superficially similar, my colleague Dave
Crocker has argued that the IETF should not take on the work at
all because there is no value added other than endorsement. But
perhaps my memory is bad or this situation is subtly different.
It seems to me that you and your colleagues have asked for a
charter constraint that asserts wide deployment and, on that
basis, appears to constrain the choices and changes the IETF can
make. I am sympathetic to the desire for that constraint but I
think we all need to accept that it is an unusual request.
Because it is unusual, it also seems to me that
(i) you are obligated to demonstrate that sufficient
production-level deployment actually exists to justify
such a request and that it has been successful in
solving whatever problem the proposed work is intended
to solve. Normally, that would be a ridiculously
onerous requirement to place on a charter proposal for a
WG. But, because this effort has requested --and
written into the draft charter-- some unusual
restrictions on the IETF on the basis of the deployment
level, the situation, IMO, changes: if you want or need
the restrictions, then you should be willing to accept
the added scrutiny and text. While I am convinced that
a great deal of effort, collaboration, and compromise
have gone into the current proposals, I have yet to see
evidence of significant and successful deployment.
(ii) this WG proposal and several of your recent
comments request that IETF give up most design control
--including the ability to determine whether the need
for a change is significant enough to be considered --
before (from an IETF process standpoint) the effort has
started. I completely agree with you about the
difference between "broken" and "maybe could be made
better" and the importance of understanding where to
draw the line. But the intent of this charter appears
to be to vest the decision about what changes are
appropriate (or not) entirely in the self-designated
leadership of the WG, placing constraints on the usual
processes of review and interactions. It is
reasonable, IMO, for the IETF to respond by including in
the charter things that would be obvious were the WG
more normal and conventional, and even to impose some
extra conditions that would be unusual for a more
conventional WG setup, simply to stress that those
elements of WG operation and review had not changed.
(iii) you are obligated to be quite explicit about the
value added by IETF involvement given those constraints,
much more explicit that would be expected of a normal WG
that had not requested the constraints.
There is certainly a case to be made that the push-back you are
getting would be unreasonable were this a conventional WG
charter proposal. But, because of the request for constraints
on permitted changes, it is not a conventional WG charter
proposal and suggestions about additional review, additional
constraints, and specific additional language all seem to me to
be appropriate as a result.
> 2. You cannot seriously think that adding the language Ted
> suggests -- [...] -- will make any difference to the working
> group process.
Viewed in the light of the above, some language along the lines
I think Ted and others have suggest might actually be quite
valuable in delineating how far the WG (or its leadership) is
expected or permitted to go in application of the requested
"restricted changes" principle. Such language could be useful
in documenting an agreement, setting expectations, and
preventing future misunderstandings. Should it be the
community's expectation that having such agreements, and having
them documented, would not "make any difference to the working
group process", then the WG should not be chartered... but I'm
sure you did not intend your comment to be read that way.
> 3. Adding such language is not a remedy for bad working group
> management or participation, yet that is exactly what Ted and
> you seem to be targeting. Since it does not target technical
> details of the work to be specified -- remember you said
> "education" -- that means that we now need to make charters
> bullet-proofed against an essentially infinite range of
> misunderstandings, as well as presuming that participants are
> not to be held responsible for reading basic IETF materials.
>...
While YMMD, I see a level of hyperbole in the above paragraph
that I don't consider appropriate or efficient if the goal is
making progress on finding a set of charter provisions that are
acceptable to both the proponents and the broader community.
>...
>> The same reasoning above applies here. Having people whose
>> sole involvement with the IETF is one new WG know that there
>> is an
>
> You are attempting to impose a new requirement for a charter,
> namely that it be bullet-proofed against ignorant participants.
Perhaps that was Paul's intent, but I didn't read his comment
that way. For me, the key unusual property of this WG proposal
is the claim and request that the IETF constrain itself, a
priori, about the questions that can be asked and the changes
that can be made. Without trying to guess at what consensus
will emerge from the community about whether that request is
reasonable, it seems to me that requests for additional language
to delimit, explain, and emphasize its boundaries are entirely
in order. If you find such requests unreasonable because they
explain or reiterate the obvious or impose new requirements,
then an appropriate remedy would be to remove the (suggested)
constraint that makes the effort unusual.
> That sounds like an interesting item to pursue in the IETF
> process enhancement discussions, because the expectation of
> such content in a charter is not specified in any current IETF
> process documents.
Nor does any current IETF process document anticipate a charter
that constrains the IETF's ability to make changes to a
preexisting specification or that intends to pre-judge the
changes that can be made. If one were trying to kill the DKIM
effort procedurally, one would say "a WG with these formal
constraints on IETF-introduced changes is not covered in any
current process documents, so a charter should not be approved
until the norms for a group requesting such constraints are
established through the process enhancement discussions". No
one appears to have said that, which I consider an Extremely
Good Thing. However, to the extent to which a WG is proposed
with unusual constraints on the community, it seems to me that
community discussion of corresponding additional constraints,
requirements, or explanatory language is entirely in order.
>...
> 2. You are presuming that it is reasonable for someone to come
> in at the end of a working group and require a defense of the
> initial position of the work. Since such a question belongs
> at the beginning of the process -- assuming that anyone has
> noticed that this work continues existing work rather than
> creates new work -- it is not productive to have such basic
> challenges lodged at the end of the process.
Hmm. This clearly is not the "end of a WG", a situation to
which I would join you in objecting. But I trust you will agree
that there needs to be some appropriate time for the community
to raise these issues, expect a response, and be able to
evaluate that response. Usually, the optimal time is when a
charter is proposed and under review, but that is exactly what
is being done here, so I don't see the objection... unless you
believe that the "basic challenge" should have been imposed at
"the beginning" where that is defined at the initiation of a
design team process that was conducted out of sight of the IETF
process and not subject to IETF rules about openness and
participation. At least as important, as you pointed out...
> 1. The question has been discussed and explained at length on
> the mailing list, the two BOFs, and elsewhere, for the last
> year.
My impression has been that a significant fraction of the
community did not find the discussion and explanation
satisfactory and/or persuasive. Now, when there is a request to
approve a charter, is precisely the one at which there needs to
be community rough consensus as to whether the question and its
answer were well-formed, appropriate, and convincing. It seems
to me that trying to suppress the question on the basis that
explanations have been given before --explanations that some
have found unconvincing-- can be taken only as resistance to
community input. I'm sure you didn't intend that reading.
>...
>> At 5:04 PM -0800 12/20/05, Eric Rescorla wrote:
>>> > Since experimentation resulted in significant Internet
>>> > deployment of these specifications, the DKIM working
>>>> group will make every reasonable attempt to keep changes
>>>> compatible with what is deployed, making incompatible
>>>> changes only when they are necessary for the success of
>>>> the specifications.
>>>
>>> As I argued on the DKIM working group list, I think this
>>> text is a bad idea. Part of IETF having change control of a
>>> specification is having the ability to make changes, and the
>>> bar of "necessary to the success of
>
> And Eric seem to keep ignoring, the question of how much
> change to target, when taking in existing technology, is an
> established point that has been experienced a number of times
> already. Different choices have been made. Those seeking to
> field DKIM have reached a consensus on charter language that
> reflect their choice for this case. (In other words, Eric,
> rough consensus has been established on this issue.)
As you have already deduced from the above (and from our
correspondence of several months ago) I share Eric's basic
concern. I won't reiterate those discussions and I think the
discussion above summarizes my view that, if the group is going
to ask for this type of constraint, it is reasonable that the
community delimit the constraint and related behavioral
possibilities to the degree it believes appropriate. But I do
not accept the assertion that "rough consensus has been
established". I am certainly prepared to believe that
consensus --rough or better-- has been established among the
proposers. But the question here, as I see it, is whether there
is community consensus for accepting a charter that contains a
provision that is very unusual in our history rather than
letting the WG and IETF community sort out, as the work
progresses, which changes are appropriate and which ones are not.
> The impression, at this point, is that those seeking to remove
> all limits on the technical changes in fact have no interest
> in protecting the existing work.
See comment about hyperbole above.
> In that light, the folks who developed DKIM would be quite
> seriously crazy to hand it over to the IETF.
One of the things I'm having trouble understanding is why you
want both a strong constraint on changes and a WG. If the
experimental work has resulted in wide deployment, and that
deployment has been successful to the extent that the WG should
be limited to making only those changes that are either trivial
tuning or demonstrably needed on the basis of a clear "doesn't
work" situation, it would seem more appropriate to simply submit
the documents for standardization along the individual
submission path, saving the WG resources that we both keep
pointing out are limited. That path would, of course, raise the
question of whether the IETF was adding value, but that question
follows from the "limited changes" constraint anyway and the
value requirement and threshold would presumably be lower for
something that could be expected to consume fewer resources.
>...
>> It is fortunate that the Atompub WG didn't have language like
>> this in our charter, because we made many improvements from
>> the widely-deployed, pre-IETF Atom 0.3 spec.
>
> And presumably that was the choice of those forming the
> working group, doing the work, and/or planning to deploy the
> result. In the case of DKIM, the decision came down in a
> different place.
I don't think you can make that assertion at this stage, and
maybe that is the essence of our disagreement. My
understanding of what happened with Atompub is that the WG, in
the process of doing the work and considering deployment,
interoperability, and so on, made those decisions. That is
perfectly reasonable; it would have been equally reasonable had
they made the opposite choice. But, with DKIM, you are trying
to preempt that decision-making process in the WG by setting the
decision into the charter. I can't speak for Eric, but I'm
finding that early-decision process -- based on a conclusion
reached by what, from an IETF process standpoint, is the
membership of a self-selected design team-- somewhat troubling.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf