|
Margaret, Itojun,
I am a bit puzzled by some elements of your response.
> The v6ops chairs do believe that the publication of this > document would represent an end-run for two reasons: > > (1) It is proposed that ISATAP would obsolete a portion > of RFC 2893. The v6ops WG is currently updating > RFC 2893, and it will be our decision whether or > not to remove the automatic tunneling mechanism. > ISATAP does not, and should not, obsolete that > mechanism.
I re-read the ISATAP draft, and I am at a loss with this comment. The draft cites 2893 as it goes on using the 2893 nomenclature, but I don't see where it actually proposes to obsolete either 2893, or mechanisms defined in 2893. In any case, the proposition was for an experimental publication; experiments come and go, and certainly do not obsolete standard track recommendations.
> (2) The v6ops WG is currently undergoing a process > to enumerate and analyze the expected scenarios > for IPv4 -> IPv4/IPv6 transition, with the > goal of producing a single, coordinated set > of transition mechanisms, each of which will > include appropriate applicability information. > The publication of a transition mechanism via > another track, before its applicability is > analyzed, would undermine this effort.
I think that there ought to be a different bar for experimental and standard tracks presentation. The standard track document is something we recommend, a solution that we believe is well engineered. An experimental RFC does not convey an endorsement; it is more a license to, well, experiment. Judging an experimental RFC by how it fits with the overall grand plan of the working group defeats the whole concept of experimental RFC, which may well precisely be to experiment outside of this consensus.
This does not mean that we should just say yes. It should just mean that the bar should be different. Not, "does it fit with our plans?" But rather, "If this experiment was conducted, would it hurt the Internet?" For example, it would be quite reasonable, even necessary, to refuse publication of a protocol if its security holes would endanger its users, or even worse other Internet users. It would also be necessary and reasonable to refuse publication of a protocol that would cause or aggravate network congestion.
If the working group wants to refuse the publication of ISATAP, it should do so on technical grounds, because the mechanism would be somehow dangerous, not because it does not fit in the plan. The “does not fit” comment would rather belong to some kind of application statement. And, there is indeed always the possibility to have a standard track RFC obsolete a previous experiment.
> The v6ops chairs will be expressing this opinion to the IESG > in one week. We wanted the WG to be aware of this situation, > and we would welcome your feedback regarding our position.
I would very much like this position to be reconsidered.
-- Christian Huitema
|