On 4/19/14 10:17 AM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> I also think the time has come to try and address the more general
> problem
> of misunderstanding and/or misrepresentation of the status of various
> documents. This probably needs to be addressed through a combination of
> automatic labeling as well as some explicit statements here and there.
>
> And this really needs to be spearheaded by the IESG, not the IAB. I
> hope the
> IESG is already considering taking action. If not, they should be.
The timing has been impeccable. The IESG had been privately talking
about the "IETF relevance" issue, including why people are bringing
"done" work to the IETF instead of working inside of the IETF. And
related to "done" work, we have also been discussing the relative merits
of AD-sponsored documents vs. ISE documents and what the appropriate use
of IESG and IETF time is for these things. We've had all of that on our
agenda for our upcoming retreat in a couple of weeks, and planned to
discuss it with the IAB during a joint meeting. Then this DMARC thing
happens, and Vidya published her article on "why I quit writing internet
standards". It could not have been timed better.
I'm trying to get my head around what we should have done differently on
this, both tactically and strategically, so that I can summarize it for
the discussion. But I can say pretty confidently that this is a topic
frontmost in the minds of IESG folks.
On the misunderstanding/misrepresentation issue, I'm not sure asking what
could have been "done differently this time" is the right question. Our
processes were followed AFAIK. The misunderstanding/misrepresentation
of the (preliminary) result of that process is not really a result of
what was done there, but rather the context in which the process operates.
But to my other point - what came out of the process - yes, I entirely
agree we need to look at what could have been done differently.
And on that score I'm not going to presume to offer specific advice. What I
will say is that I think you need to widen your scope to consider other
specifications. I already pointed out on the ietf-822 list how the SPFBIS
specifications contains what I consider to be totally inadequate advice on how
to address a similar, albeit less serious and far easier to address, issue.
In fact I think some examination of how similar issues have been handled in
other recent documents is warranted.
Ned