Lars Eggert has entered the following ballot position for draft-ietf-dmarc-psd-12: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3, paragraph 2, comment: > 3. PSD DMARC Updates to DMARC Requirements > > This document updates DMARC as follows: If I understand things correctly, this document specifies an experiment that - if successful - would lead to an update of RFC7489. It's therefore confusing to see the text in Section 3 that is written as if that update was already being brought into effect. I'd much prefer text that said things like "to participate in this experiment, implementations should do X or Y or Z and/or interpret Section foo of RFC7489 as bar", etc. Section 7.3, paragraph 1, comment: > 7.3. URIs It's unusual for an RFC to have reference sections other than for normative and informative references, because it's not clear what category references here would fall into. Also, I'll note that [psddmarc.org] was cited as an informative reference in that section, so why not this one? ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 3.2, paragraph 3, nit: > to that of the "p" tag defined below. If the 'np' tag is absent, The document uses both single and double quotes throughput (above is an example), and it's not clear if this is deliberate (i.e., there is a meaning to this) or whether this is an editorial oversight that should be corrected. Section 6.1, paragraph 5, nit: > +----------+-----------+---------+-------------------------------+ > | Tag Name | Reference | Status | Description | > +----------+-----------+---------+-------------------------------+ > | np | this | current | Requested handling policy for | > | | document | | non-existent subdomains | > +----------+-----------+---------+-------------------------------+ > You should add an RFC Editor Note instructing them to replace "this document" with the RFC number of this document (to make sure they are aware of the action). Section 1, paragraph 2, nit: - DMARC ([RFC7489]) provides a mechanism for publishing organizational - - - + DMARC [RFC7489] provides a mechanism for publishing organizational Section 1, paragraph 3, nit: - found in Section 3.2 of the DMARC specification. Currently the + found in Section 3.2 of the DMARC specification. Currently, the + + Section 1, paragraph 4, nit: - In the basic DMARC model, PSDs are not organizational domains and are + In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains and are + +++++++++++++++++++++++ + Section 1.2, paragraph 7, nit: - handling policy for non-existent subdommains. This is provided - - + handling policy for non-existent subdomains. This is provided Section 1.2, paragraph 7, nit: - of requesting harsh policy treatment (e.g. reject) is lower. + of requesting harsh policy treatment (e.g., reject) is lower. + + Section 1.2, paragraph 8, nit: - (i.e. if a DMARC record were published for 'example', then mail from + (i.e., if a DMARC record were published for 'example', then mail from + + Section 2.7, paragraph 2, nit: - is a broader definition than that in NXDOMAIN [RFC8020]. - --------- + is a broader definition than that in [RFC8020]. Section 4.1, paragraph 7, nit: - not particpate in DMARC, any Feedback Reporting related to multi- + not participate in DMARC, any Feedback Reporting related to multi- + + "B.3.", paragraph 3, nit: - supposed to be the output domain of the regular PSL lookup, i.e. the + supposed to be the output domain of the regular PSL lookup, i.e., the + + _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
