Re: [dmarc-ietf] DMARCbis rev 29
Well done! I feel that rough consensus must be close. > On Dec 2, 2023, at 5:10 AM, Alessandro Vesely wrote: > > On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote: >> There are only four open items on the issue tracker - though I think the SPF >> question >> (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/116) was >> resolved. But is that really all there is to do? > > > I'd hope most of the other questions are solved as well. Aren't they? > > *auth* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/118 > This was rehashed in the end of October, when Scott explained how the correct > way to fix SPF is appropriate usage of qualifiers. There seemed to be > agreement that such clarification deserves its own paragraph in DMARCbis, but > it never made it to rev 29. > > *reject* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/115 > This was discussed ad nauseam. My understanding is that participants > convinced that MUST NOT is right finally consented to accept Barry's text. > > *define* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96 > To say when people can hold they implement or enforce DMARC. Seth proposed > some text in the beginning of April. Don't recall the conclusion. Do we > need to add text for this? > > > We should review *aggregate reporting*. For one point, we should add XML > documents to the normative references: > > Extensible Markup Language (XML) 1.0 (Fifth Edition) > https://www.w3.org/TR/xml/ > > W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures > https://www.w3.org/TR/xmlschema11-1/ > > W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes > https://www.w3.org/TR/xmlschema11-2/ > > There are a few other points which deserve a review, summarized in a thread > started by Olivier about mid November. Should I create a new ticket for that? > > > Best > Ale > -- > > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis rev 29
On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote: There are only four open items on the issue tracker - though I think the SPF question (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/116) was resolved. But is that really all there is to do? I'd hope most of the other questions are solved as well. Aren't they? *auth* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/118 This was rehashed in the end of October, when Scott explained how the correct way to fix SPF is appropriate usage of qualifiers. There seemed to be agreement that such clarification deserves its own paragraph in DMARCbis, but it never made it to rev 29. *reject* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/115 This was discussed ad nauseam. My understanding is that participants convinced that MUST NOT is right finally consented to accept Barry's text. *define* https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/96 To say when people can hold they implement or enforce DMARC. Seth proposed some text in the beginning of April. Don't recall the conclusion. Do we need to add text for this? We should review *aggregate reporting*. For one point, we should add XML documents to the normative references: Extensible Markup Language (XML) 1.0 (Fifth Edition) https://www.w3.org/TR/xml/ W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures https://www.w3.org/TR/xmlschema11-1/ W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes https://www.w3.org/TR/xmlschema11-2/ There are a few other points which deserve a review, summarized in a thread started by Olivier about mid November. Should I create a new ticket for that? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis rev 29
On 12/1/23 11:14 AM, Dotzero wrote: On Wed, Oct 25, 2023 at 10:04 AM Todd Herr wrote: I further think that the best way to produce the next rev of DMARCbis is for the chairs and the editors (and perhaps the ADs) to huddle together and create/update issues in the Github repository for the sections of text for which changes have been proposed. At a minimum, the outcome of this meeting would be several bullet points all following this pattern: * Create/update GitHub issue with $TITLE using text from $MAILING_LIST_THREAD Todd, as editor whose mail client isn't one that lends itself well to piecing together multiple threads into a coherent list... I never saw a response to this post to the list by Todd. As we reach the end of 2023 and the start of 2024, I agree that the chairs, AD and editors should address what issues are left to be addressed and/or need to be added to the list of on-topic open issues. I think this would be helpful. There are only four open items on the issue tracker - though I think the SPF question (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/116) was resolved. But is that really all there is to do? Tracker link: https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues --Steve. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)
On Wed, Oct 25, 2023 at 10:04 AM Todd Herr wrote: > On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba > wrote: > >> Now that we have a consensus call on the main issue that has remained >> open: >> >> 1. Do we need to retain our session at IETF 118 and discuss this (or >> something else) further? >> >> ...or... >> >> 2. Do we have what we need to finish up the DMARCbis document, and >> should the chairs cancel the session at 118? >> >> Oh, and... >> >> 3. Is there something else (such as the reporting documents) that we >> should use the time at 118 to discuss? Or can we continue with those >> on the mailing list for now? My sense is that aggregate reporting, at >> least, is just about ready to go and doesn't need the face-to-face >> time. >> >> > I think canceling the session at 118 is the way to go. > > I further think that the best way to produce the next rev of DMARCbis is > for the chairs and the editors (and perhaps the ADs) to huddle together and > create/update issues in the Github repository for the sections of text for > which changes have been proposed. At a minimum, the outcome of this meeting > would be several bullet points all following this pattern: > >- Create/update GitHub issue with $TITLE using text from >$MAILING_LIST_THREAD > > Todd, as editor whose mail client isn't one that lends itself well to > piecing together multiple threads into a coherent list... > > -- > > *Todd Herr * | Technical Director, Standards & Ecosystem > *e:* todd.h...@valimail.com > *p:* 703-220-4153 > *m:* 703.220.4153 > > I never saw a response to this post to the list by Todd. As we reach the end of 2023 and the start of 2024, I agree that the chairs, AD and editors should address what issues are left to be addressed and/or need to be added to the list of on-topic open issues. In the interest of completing the working groups objectives, off-topic posts/threads should be shut down quickly so that we can focus on resolving open on-topic issues. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)
On Tue, Oct 24, 2023 at 2:15 PM Barry Leiba wrote: > Now that we have a consensus call on the main issue that has remained open: > > 1. Do we need to retain our session at IETF 118 and discuss this (or > something else) further? > > ...or... > > 2. Do we have what we need to finish up the DMARCbis document, and > should the chairs cancel the session at 118? > > Oh, and... > > 3. Is there something else (such as the reporting documents) that we > should use the time at 118 to discuss? Or can we continue with those > on the mailing list for now? My sense is that aggregate reporting, at > least, is just about ready to go and doesn't need the face-to-face > time. > > I think canceling the session at 118 is the way to go. I further think that the best way to produce the next rev of DMARCbis is for the chairs and the editors (and perhaps the ADs) to huddle together and create/update issues in the Github repository for the sections of text for which changes have been proposed. At a minimum, the outcome of this meeting would be several bullet points all following this pattern: - Create/update GitHub issue with $TITLE using text from $MAILING_LIST_THREAD Todd, as editor whose mail client isn't one that lends itself well to piecing together multiple threads into a coherent list... -- *Todd Herr * | Technical Director, Standards & Ecosystem *e:* todd.h...@valimail.com *p:* 703-220-4153 *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
