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