Re: [apps-discuss] DMARC and the conflict of extensions vs. deployment

Daves comments match my understanding of the intent of the draft charter.

Mike

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Dave Crocker
> Sent: Saturday, April 13, 2013 5:01 PM
> To: Paul Hoffman
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs.
> deployment
> 
> 
> 
> On 4/13/2013 7:13 AM, Paul Hoffman wrote:
> > At the time of chartering, DMARC has already achieved an estimated
> coverage of 60% of the Internet's mailboxes. Consequently, any extensions
> or revisions that create software or operations incompatibilities with this
> significant installed base need to be considered carefully. The strong
> preference is for the working group to preserve existing software and
> procedures. For changes likely to affect the installed base, the working group
> will actively seek to include developers and operators of DMARC-based
> mechanisms outside the core set of working group participants in its
> consensus discussions.
> > =====
> >
> > To me, that says that the WG cannot produce an incremental extension
> because existing software and procedures would have to be updated.
> 
> 
> Speaking for myself only, of course, but...
> 
> 
> That's an unexpected interpretation of the text.
> 
> Normally, an "incremental extension" is taken to mean that it provides
> /additional/ capabilities that are not essential to core operation.
> (cf., smtp extensions or mime).
> 
> That is, whatever was original working will still work, albeit without whatever
> new and spiffy capabilities are specified in the incremental extensions.
> 
> By way of a marked contrast, cf. IPv4 vs. IPv6.
> 
> While I can certainly imagine a frame of mind that counts IPv6 as an
> "incremental extension" to IPv4, that frame of mind is certainly not the one
> intended for reading the draft charter.
> 
> To summarize:  the charter seeks to constrain work that might /force/ a
> change in the existing installed base, by virtue of creating an interoperability
> problem, rather than to necessarily constrain value-add enhancements that
> are optional.
> 
> d/
> --
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss