[ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata
Pasi.Eronen at nokia.com
Pasi.Eronen at nokia.com
Wed Mar 11 07:24:10 PDT 2009
Eliot Lear wrote:
> As to the chair's request, FWIW I *have* given Dave suggested
> changes, and I believe he has accepted some of them. I must admit
> some confusion about the process at this point. It seems that there
> is an outstanding request of Pasi about whether this draft can
> proceed. Here are my questions:
Since "whether this draft can proceed" could be interpreted in
multiple ways, let me clarify slightly: assuming we have rough WG
consensus about the content, this definitely can proceed, using the
same process we normally use for drafts (IETF Last Call, IESG
Evaluation, RFC Editor queue, and finally RFC NNNN).
> 1. If it does proceed, what happens with rfc4871bis? I would
> expect we get to have this whole discussion over again because new
> avenues open themselves up when we are talking about a revision to
> the standard, like deprecating i=, adding r=, and perhaps even
> eliminating the concept of UAID.
This depends on how the charter scopes the work item.
For example, IPSECME is currently working on IKEv2bis (4306bis),
which is quite tightly scoped in the charter:
"A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the
specification, taking into account implementation and
interoperability experience. In some cases, the revision may include
small technical corrections; however, impact on existing
implementations must be considered. Major changes and adding new
features is beyond the scope of this work item. The starting point
for this work is draft-hoffman-ikev2bis."
So, the "bis" draft has absolutely no new features (IPSECME WG is also
working on new features, but they're in separate documents), and no
technical changes that don't count as "small technical corrections"
(which BTW in many cases means just resolving internal inconsistencies
-- one part of the RFC conflicts with some other part, and both can't
be right -- one way or the other).
At other times, it could be better to have a more open charter
(allowing the WG to redesign the protocol if they so decide), but
for 4871bis, I'd probably recommend something closer to the IPSECME
approach (new features go to separate documents, and no big changes
in 4871bis either).
If we want to emphasize completing 4871bis quickly, the extreme
scoping would be "draft-ietf-dkim-rfc4871-errata-NN plus the errata
currently submitted to RFC Editor, no other changes". Another
possibility would be this plus "...and remove all features/options
that don't have at least two independent and interoperable
implementations" (so it could be updated to Draft Standard).
More information about the ietf-dkim