Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
On 5/29/2019 1:13 PM, John R Levine wrote: You seem to be suggesting that the standards-track DMARCbis should be different because an informational, non-WG RFC has already been published. From a process standpoint that's bad; standards-track RFCs should go through exactly the same process regardless of whether or not they were previously published as Informational. As far as I can tell your proposal to break the document in two has gotten no support at all. Can we stop now? "No support at all?" For the record, I support the "split." But I won't care it is remains. I just think it will complicate a specification and extend the future work of completing a DKIM Policy Model proposed standard which is in need of a tremendous amount of work. -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
On Wed 29/May/2019 19:01:11 +0200 Jim Fenton wrote: > One more point on this: > > On 5/24/19 7:37 AM, John R Levine wrote: >> >> That's because they separated before they were published, so there was >> nothing to be incompatible with. If I knew what would break when >> reorganizing and rewriting a document into pieces, I could fix it, but >> since I don't, and nobody else does, let's not go there. > > > You seem to be suggesting that the standards-track DMARCbis should be > different because an informational, non-WG RFC has already been > published. From a process standpoint that's bad; standards-track RFCs > should go through exactly the same process regardless of whether or not > they were previously published as Informational. Albeit rfc7489 is informational, it is meant to be a spec. So structural changes to the document, however useful to first-time readers, would be a nightmare for those who have already implemented DMARC and are checking what has changed. It would also disrupt many references, thereby invalidating a large part of the literature. A new companion rfc (or a new appendix, or a rewriting of Section 8) meant as an implementation guide could host discussions about the points 1a... 4b listed upthread. It should recount the most useful tips we collected thus far, rather than trying to establish normative duties, IMHO. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
On 5/29/19 10:13 AM, John R Levine wrote: >> You seem to be suggesting that the standards-track DMARCbis should be >> different because an informational, non-WG RFC has already been >> published. From a process standpoint that's bad; standards-track RFCs >> should go through exactly the same process regardless of whether or not >> they were previously published as Informational. > > As far as I can tell your proposal to break the document in two has > gotten no support at all. Can we stop now? > This was about a broader process issue and not specifically about splitting the document into parts (I should have changed the subject line). But yes, we can stop talking about the document split. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis issue: Separating reporting and policy
You seem to be suggesting that the standards-track DMARCbis should be different because an informational, non-WG RFC has already been published. From a process standpoint that's bad; standards-track RFCs should go through exactly the same process regardless of whether or not they were previously published as Informational. As far as I can tell your proposal to break the document in two has gotten no support at all. Can we stop now? Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
