Agree with John/Scott/Kurt on keeping this in 7489 and trying to weasel word around it for now.
I tried to reference 8499 thinking we'd done the right thing in there, and Kurt pointed out the error of my ways. We should take an item to really sort this out in 7489bis. and John has heard me on several occasions appreciating the simplicity in https://www.ietf.org/archive/id/draft-levine-dbound-dns-03.txt tim On Fri, Apr 10, 2020 at 11:21 AM Kurt Andersen (b) <kb...@drkurt.com> wrote: > On Fri, Apr 10, 2020 at 6:49 AM Scott Kitterman <skl...@kitterman.com> > wrote: > >> On Friday, April 10, 2020 9:38:40 AM EDT Todd Herr wrote: >> > >> > I don't disagree, but what I was going for here was some level of >> > consistency with section 3.2 of RFC 7489. . . >> > > And it needs to stay entirely in RFC7489 :-) > > >> > Dale twice in his comments expresses doubt that it's possible for >> anyone to >> > know all PSDs; the mention of a specific PSL in the abstract was an >> attempt >> > to answer those doubts. >> >> > But how to address Dale's concerns about how one knows all PSDs? >> >> To the extent this is a problem, it's RFC 7489's problem. This document >> leverages it's existing definitions. That's intentional. While the >> current >> RFC 7489 definitions aren't ideal, as an extension to that work, I don't >> think >> it make sense to try and fix it here. That's work for 7489bis. > > > Agreed. Dale's concern is a non sequitur. We can always invoke the ghost > of DBOUND-past :-D > > --Kurt > _______________________________________________ > 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
