Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists

[[e-mail]]

> On 4/19/14 10:17 AM, [e-mail] 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