Dave Crocker wrote:
Michael Thomas wrote:
Not to be too jaded, but does anybody think this will have any practical
effect whatsoever?
1. It shows legitimate due diligence. A real-world encounter suggests
an operational problem and this note attends to it.
2. It dispatches the issue from the near-term IETF agenda, thereby
relieving the working group from a hassle.
Which is to say that it will have no practical effect whatsoever.
I tend to view both of these as practical effects. (And, yeah, I
suspect I know the sort of thing you actually had in mind and no, I
don't think this will deal with it.)
Practical from a process CYA maybe, but not in the real world of
interoperability.
What would actually be better here, IMO, is to find out _how_ this
happened.
And my point #2, above, is exactly why I suggest it would *not* be better.
It is not the job of this wg to diagnose misbehaviors by s/w or
operators. That's better done elsewhere, like
No. Sorry. If we're only interested in process CYA this is a fine way
to do that. I'm a lot more interested in whether the spec will
interoperate though. Going into ostrich mode to run out the clock is
only good when you luck out and it really was an outlier. And if we're
depending on luck, what's currently in draft is as good as anything.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html