On 7/30/24 22:31, John R. Levine wrote:
> Thanks for your note.  I think we've addressed everything in the main 
> 7489bis but some of the stuff in the reporting docs looks like it still 
> needs to be fixed.
> 
> If you're willing to futz with the markdown, pull requests with proposed 
> changes would be great.

Thank you for your encouragement. I've made my first pull request
starting with the aggregate reporting draft.

https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/18


> On Mon, 29 Jul 2024, Daniel K. wrote:
>> 1) Errata from RFC 7489 is not incorporated into the text.
>>
>> [...]
>>
>> Errata: 5365 (filename suffix), 5371 (GZIP RFC reference):
>> Both seem to be uncontroversial and should be addressed in
>> [I-D.ietf-dmarc-aggregate-reporting].

I've included a commit addressing this.


>> Erratum 5440 (changing: "v=DMARC1" to "v=DMARC1;")

Alex included some changes for this, already.


>> Should the _report._dmarc value get its own ABNF with only rua/ruf tags?
>>
>> Right now I see this record referred to as a TXT RR:
>>
>>      the DNS administrator for the Report Consumer will
>>      need to publish a TXT resource record at [...] with
>>      the value
>> "v=DMARC1;".
>>
>> Maybe it could be referred to as a DMARC Report

Apologies for the abrupt end in the middle of this sentence, I guess I
was interrupted while writing. I think I meant it to continue like this:

Maybe it could be referred to as a DMARC Reporting Authorization Record,
as the allowed syntax is really a subset of the full DMARC syntax. v /
rua / ruf

Proposed ABNF:

dmarc-reporting-auth-record  =
    dmarc-version
    (dmarc-sep "rua=" dmarc-urilist)
    (dmarc-sep "ruf=" dmarc-urilist)
    [dmarc-sep] *WSP


>> 2) Botched ABNF for 'ridtxt' in the txt version of the document.

I've included a commit addressing this.


>> 3) ABNF for 'ridtxt' is too strict

I've included a commit addressing this.


>> 4) This warning text is sometimes shown even if
>>    there's no need to wrap the command output:
>> 5) Overlap in the examples of dmarcbis and failure-reporting
>> 6) Inconsistent requirements for validating third party report consumers.
>> 7) Formal definition

I'll come back to these at a later time.


>> 9) XSD Schema
>>
>> The IPAddress type has a mix of [A-Fa-f0-9] and [A-Fa-f\d] in the
>> patterns. Use only one of them for consistency.

Alex also addressed this already.


Daniel K.

_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to