Lars See below. Thanks for the comments
On Wed, Apr 14, 2021 at 4:44 AM Lars Eggert via Datatracker < [email protected]> wrote: > 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. > > "To participate in this experiment, implementations should nterept RFC7489 as follows" > Section 7.3, paragraph 1, comment: > > 7.3. URIs This appears to be some artifact of the XML as the URI is listed in the Informative Reference section. > > 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. > > I believe I've corrected all of these quote mismatches (that is, I've found all the single quoted mentions and have updated them to double quotes). > 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). > > Done > Section 1, paragraph 2, nit: > - DMARC ([RFC7489]) provides a mechanism for publishing organizational > - - - > + DMARC [RFC7489] provides a mechanism for publishing organizational > > Fixed > 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 > + +++++++++++++++++++++++ + > > Fixed > Section 1.2, paragraph 7, nit: > - handling policy for non-existent subdommains. This is provided > - - > + handling policy for non-existent subdomains. This is provided > > Fixed > 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 > + + > > Fixed > Section 2.7, paragraph 2, nit: > - is a broader definition than that in NXDOMAIN [RFC8020]. > - --------- > + is a broader definition than that in [RFC8020]. > > Fixed > 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- > + + > > Fixed > "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 > + + > > Fixed
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
