Alternatively, we could go through working group last call,
IETF last call, and IESG push-back. For any interesting
push-back, we are probably looking at delays in the range of
6 months. (That estimate is, of course, not merely
theoretical.)
I would rather have a 6 month pushback from the IESG than a spec that is
dependent on the next release of Windows Server to become viable.
Nicely put. I agree completely with this sentiment.
Sounds nice to me, too.
The only problem is that I don't know what it means.
There has been no input suggesting that the current -base proposal is difficult
to deploy for Windows, or otherwise depends on its release cycle.
Certainly there has been no working group agreement that the current proposal is
deficient in this regard, and it seems to me that the working group has been
rather diligent in its effort to worry about such things.
So I have no idea where that reference comes from or how it relates to the
concern about substantial delays.
The first does not delay deployment in the slightest. As far as I am
concerned its damn the torpedoes.
Is this supposed to mean that a delayed approval by the IESG will not delay
deployment of the specification?
Perhaps folks have not noticed the amount of change that can be imposed by the
IESG phase of the process?
Were the industry that insensitive to change, it would already be deploying the
original version of DKIM in larger numbers.
At any rate, the tone of the comments on this thread is that folks do not seem
worried about another half-year of delay for publishing the base DKIM spec.
Please tell me I'm misunderstanding this.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html