John C Klensin wrote:
In addition, there is, I think, one other approach that might be appropriate, but only in very limited circumstances. That approach applies where there is a well-thought-out approach with design team consensus, evidence of implementation, and no clearly-identified technical concerns. Then, and only then, I think that an approach of "the WG gets to challenge the base spec and assumptions, but to change them only if there is good reason and consensus to do so" is plausible with a standards track target. I think that XMPP, and the XMPP language, probably is an instance of that case. Other than claims and counterclaims, I've seen little that would permit the IETF community to form a consensus about exactly what stage the DKIM work (and implementation, deployment, and demonstrate that it accomplishes whatever is being claimed) is really at, a consensus that seems to me to be necessary to determine whether it should be chartered as a WG if there are going to be any restrictions at all on what that WG can consider. That strikes me as sad since, beyond philosophical debates, it seems to me to be the key issue.
I obviously think it's closer to #4 than anything else. Note I wasn't weighing in about whether this piece of word-smithy vs that was better or not, just my concern that the lack of negotiation/feedback make the backward compatibility problem far more nettlesome than other protocols that have that luxury. There is a substantial risk that a bunch of gratuitous thrashing around -- or worse a greenfield makeover ala MEGACO -- will cause this effort to crater. Given MARID, I don't think we get many chances and that this is really a situation where the best is the enemy of the good. As such, I think it's reasonable for the charter to limit the scope of changes to those that will really tighten up the mature parts of the specs instead of a, IMO, futile -- and destructive -- trip back to first principles. False dichotomy? Maybe, but not out of the question if there is no limit at all, and that's pretty bothersome for those of us who advocated taking this to ietf and tried really hard to make this look like something that would pass ietf muster. Finally, I understand that for many people there are larger principles at stake about the nature of ietf, etc, etc. I can't tell you how thrilled I am that we are the posterboy for _that_ argument. Mike _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf