>>> It's fairly easy to demonstrate interoperability of protocols, but >>> usefulness is much more difficult. DKIM is an infrastructure protocol, >>> designed to provide a basis for other mechanisms, such as domain-based >>> reputation, to operate. Those other mechanisms are as yet nascent; how >>> does one judge usefulness at this point? >> >>This appears to be imposing criteria that go considerably beyond the >> IETF's requirements for Draft. > > So is it your position that a protocol must be advanced if it meets a > minimal set of criteria even in the face of engineering judgement that the > protocol is not yet sufficiently deployed to have a reliable understanding > of the adequacy of the current design?
As I see it, the reasons to go to DS would be Y1. to progress a fairly stable standard along a defined track, and Y2. to review it and perhaps clean it up a little along the way, and Y3. to get broader deployment as a result of higher maturity. As to Y3, there's evidence, as Murray has pointed out and as many of the rest of us are aware, that most deployment comes from publication as PS, and from other sorts of publicity... and DS probably doesn't create the swell of deployment that we might like. Still, as long as the IETF considers the three-stage standards track to have value, I think there's some value in working within it. The reasons not to go to DS would be N1. to avoid wasting our time on nominal advancement that has little or no real value, or N2. to avoid wasting any more time working on something that's not very useful, or N3. in recognition that it's not stable, and that, while it certainly meets stated criteria for DS now, we think we're likely to change it significantly after more experience with it. My opinion is that N1 is arguable, but that N2 and N3 are not the case, and that we shouldn't resist advancing DKIM base to DS for reasons N2 and N3. My opinion is also that, while N1 might be true, the fact the IETF considers it worthwhile overrides that. And note that I'm only advocating advancement for DKIM base at this point; I think we DO need more experience with ADSP before we have any clue whether it's stable (or useful). Barry, as participant _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
