ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

2009-03-11 10:30:47
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).

Best regards,
Pasi
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html