Re: [dmarc-ietf] Charter improvements

[Dave Crocker <[e-mail]>]

On 7/16/2013 8:39 AM, J. Trent Adams wrote:
> * Tone down the "marketing puffery".

While I think the existing text isn't all that puffed-up, something 
along the lines of what it says is still helpful to include.

The key point is that the existing specification has a sufficiently 
large installed base to warrant considerable care in making changes that 
would disrupt it.


> * Clarify how to address "backward compatibility" with the installed base.

Perhaps:

      In order to protect the installed base, any changes to operational 
practice or bits over the wire need to be incremental and optional. 
That is, they need to be added as extensions to existing practice, 
rather than make changes to it.  This permits unmodified software and 
operations to continue to interoperate with those that are upgraded.


> * a mechanism for determining the organizational domain name based on an
> arbitrary fully-qualified hostname
> -----
>
> If I'm not mistaken, the Apps Area WG has already expressed an interest
> in this work. In that case, I believe that this WG would only need to
> track that effort and ensure that its work addresses the use cases
> required to support DMARC.
>
> QUESTION: Given that it's an important topic, and there's no guarantee
> that the other effort will result in an applicable solution, would it
> still be reasonable to include a mention of this as worth exploration?

Not in a charter, unless the wg is going to explore it, which it won't.


> If so, it'd probably make sense to reference the other work as a
> starting point to clarify we're not planning to spin up a competing
> solution.

In formal IETF terms, other work isn't real yet.  So the reference would 
be to something not yet having any substance.



> -----
> * a mechanism for mitigating the effect of failures of DMARC policy when
> a message transits a mailing list
> -----
>
> I recognize that there's definitely a counter-pressure against including
> this topic as it seems to be a potentially quixotic quest. That being
> said, even if we don't find the perfect solution, it does seem
> reasonable to believe there is a way to provide something more than
> nothing that does help in some meaningful way. I'm not presupposing a
> solution, just that there have been a few possible options discussed at
> the edges which are likely to be worth more rigorous exploration.
>
> QUESTION: Is there value in a WG such as this exploring possible
> solutions to this issue and developing guidance that would potentially
> help improve the utility of the base DMARC specification?

If the wg handles this carefully and pragmatically, there might be some 
benefit in at least documenting the topic, in terms of concerns and 
choices.  I believe there isn't an IETF published paper in this realm, 
in spite of the issue appearing regularly.

It might also chart out one or two pragmatic paths for change that are 
worth exploring.  As such, this would be a non-normative discussion 
paper, rather than a specification.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net