Issue 180 has been opened in regards to this notice - https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues/180
On Tue, Feb 4, 2025 at 9:03 PM Roman Danyliw via Datatracker < [email protected]> wrote: > Roman Danyliw has entered the following ballot position for > draft-ietf-dmarc-dmarcbis-38: Discuss > > 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/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 9.3. and 9.4. Status column > > -- Section 9.3 “Each registration includes the tag name; the specification > that > defines it; a brief description; and its status, which is one of "current", > "experimental", or "historic".” > > -- Section 9.4 “In addition to a reference to a permanent specification, > each > registration includes the format name, a brief description, and its > status, > which must be one of "current", "experimental", or "historic".” > > The status column was defined in RFC7489 and already in the existing IANA > registries. However, there doesn't appear to be adequate guidance on > setting > and using it. Specifically: > > (1) What are the criteria used to set a particular code point to “current”, > “experimental” or “historical” status? There is no guidance for the > designated > expert. > > It can’t be the status of a given RFC since the registration procedure is > “specification required” allowing for non-RFC documents. Section 9.3 > appears > to be updating the registry to amend existing code points to historic > status > (e.g., pct, rf, ri) so the WG must have some intuition that would benefit > from > being document here. > > (2) What does experimental or historic signal to implementers? What do > they do > with this information? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Ines Robles for the GENART review. > > ** Section 4.7 > v: Version (plain-text; REQUIRED). Identifies the record retrieved > as a DMARC Policy Record. It MUST have the value of "DMARC1". > The value of this tag MUST match precisely; > > What does it mean to “match precisely”? Is this saying a case-sensitive > match > to “DMARC1”? I ask because the meaning of the two sentences isn’t clear > to me. > > Isn’t this first normative MUST duplicative to the ABNF in Section 4.8 > (i.e., > “dmarc-version = "v" equals %s"DMARC1"”) > > ** Section 4.6 > (a) v: Version (plain-text; REQUIRED). Identifies the record retrieved > as a DMARC Policy Record. It MUST have the value of "DMARC1". > The value of this tag MUST match precisely; if it does not or it > is absent, the entire record MUST be ignored. It MUST be the > first tag in the list. > > (b) A DMARC Policy Record MUST comply with the formal specification found > in Section 4.8 in that the "v" tag MUST be present and MUST appear > first. > > Isn’t there duplication here. Both (a) and (b) say that v must appear > first > AND is required. > > ** Section 5.4 > Mail Receivers are encouraged to maintain anti-abuse technologies to > combat the possibility of DMARC-enabled criminal campaigns. > > No issues with the sentiment. However, is the WG confident that “criminal > campaigns” isn’t too narrow? For example, what about DMARC-enabled > espionage > campaigns? Could this sentence read (roughly) “Mail Receivers are > encouraged > to maintain anti-abuse technologies to mitigate the possibility of > DMARC-enabled abuse”? > > ** Section 9.2 > IANA has added the following in the "Email Authentication Result > Names" registry: > > -- There are already entries for these Auth Methods. Shouldn’t the > guidance be > to replace the reference for them to this document? > > -- The current references for each of these Auth Methods includes a section > number for RFC7489. Should section numbers be added for each reference > here? > > ** Section 9.3 > The set of entries to be defined in this registry is as follows: > > As above, the current registry has already registered all of these. The > key > detail is that some have had their status changed and an updated reference > is > needed. > > Same comment for Section 9.4 > > > > -- Todd Herr Some Guy in VA LLC [email protected] 703-220-4153 Book Time With Me: https://calendar.app.google/tGDuDzbThBdTp3Wx8
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
