Domain-based Message Authentication, Reporting & Conformance
charter-ietf-dmarc-04

[Ballot comment]
Hi Andy/WG,

Looks good to me.

Thanks for taking care of main comments raised in the previous round (status change, milestone, etc.) [1]. I'm not repeating the other nity points here.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/dmarc/mum0nG1c0OeRS6p89BUV_XqrQkY/

[Ballot comment]
Charter 02-01 was clearer about writing a documenting I-D before moving features to historic. With the current charter, the reader may wonder why not an AD status change document cannot be done.

The status change by an AD could also be mentioned in the last paragraph.

[Ballot comment]
NoObj for this charter, however for me it reads odd to see the history of prior charters. The charter would be shorter and straight to the point when only using content of the last two paragraphs. Below you find an edited example:

"
The DMARC Working Group is chartered to produce a document that moves RFC 8617 to Historic or Obsolete status, including text describing its history and current state.

The Working Group is limited to this single deliverable and will adopt no other work items. The document will be submitted to the IESG for publication as Informational.

This work will be completed within six months of rechartering. If the deadline is not met, the Working Group will close, and the community may pursue the work via an Area Director, the Independent Submissions stream, or discontinue it."

[Ballot comment]
"DMARC", paragraph 1
> Accordingly, DMARC is being rechartered to publish a document that moves RFC 8617 to
> historical/obsolete status, including prose describing the history and current status of the work.

The charter states the WG will "publish a document that moves RFC 8617 to historical/obsolete status."
But under the IETF process, an Informational RFC does not, by itself, change another RFC's status.
Per the IESG Statement on Designating RFCs as Historic (2014-07-20), a status-change document is
required — maintained in the datatracker and linked to the affected RFC — to actually effect the reclassification.

Also, the charter uses the phrase "historical/obsolete status" as if these are synonymous. They are not.
Since no replacement for ARC is contemplated, the correct designation is Historic,
not "obsolete." Using both terms in the charter creates ambiguity about what the WG is actually
being asked to produce: a replacement that obsoletes ARC, or a rationale document that
supports a Historic designation. The charter should use "Historic" consistently and precisely.

"DMARC", paragraph 2
> Milestones

The charter states a six-month deadline for the sole deliverable, but the Milestones section
here is blank. For IESG approval, at a minimum, a single milestone should be present.

[Ballot comment]
Hi Andy, DMARC WG,

Thanks for preparing the new charter. Please find below some comments:

# Status Change vs. Document

CURRENT:
  Accordingly, DMARC is being rechartered to publish a document that moves RFC 8617 to
  historical/obsolete status, including prose describing the history and current status of the work.

## As you know, the IESG Statement on Designating RFCs as Historic [1] clarifies the difference between the historic/obsolete.

## Publishing a document allows for more elaborated considerations to document the reasoning and ** lack of operational impacts ** for this specific case. I don’t know if that work already started, but if the prose is condense enough, proceeding with a “status change” may be more appropriate. Maybe better to leave the decision about whether to proceed with a new document or a status change open in the charter.

## nit: s/historical/Historic to match the label we use for such status.

# RFC8617 predates draft-ietf-dmarc-dmarcbis (base doc) + reporting docs (draft-ietf-dmarc-failure-reporting, and draft-ietf-dmarc-aggregate-reporting)

CURRENT:
  DMARC was previously chartered to develop and publish a base document and two reporting documents.
  This work has been completed.

  In the intervening time, the working group also published the Authenticated Received Chain protocol
  as experimental RFC 8617.

NEW:
  DMARC was previously chartered to develop and publish a base document and two reporting documents.
  This work has been completed.

  The working group also published the Authenticated Received Chain protocol
  as an Experimental RFC (RFC 8617).

# “being rechartering” frozen in a charter seems inadequate

OLD: DMARC is being rechartered to

NEW: DMARC is rechartered to

# Consider adding an explicit milestone for better visibility on the expected outcome.

Cheers,
Med

[1] https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-designating-rfcs-as-historic-20140720/

[Ballot comment]
Comments during the external review period found that the charter incorrectly referenced the base DMARC document in the last paragraph, and that the aggregate reporting document also has an informative reference to the failure reporting document. This charter text has been adjusted to remove the references entirely from the last paragraph as they are unnecessary and to allow the working group to remove the reference to failure reporting from aggregate reporting as an option if necessary.

[Ballot comment]
The new version looks good. Please find below one nit and one question:

# (nit) Too "chartered" around

OLD: previous DMARC working group, chartered from 2014 to 2025, was chartered
NEW: previous DMARC working group was chartered from 2014 to 2025

# Not sure what is the point this sentence is trying to make, especially that this "an informative reference"

CURRENT:
  Additionally, the aggregate reporting document (draft-ietf-dmarc-aggregate-reporting-32) contains an informative reference to this document.

[Ballot block]
While I can only support the goal of this draft charter, I find it too vague on some topics.

1) please provide references to `The revision to the original document, along with one of two reporting documents`

2) please also provide reference to `This closure left behind a second reporting document` (even if expired)

About the reclaiming of the I-D from RFC editor, I am afraid that this will be done for something more than fixing typos, i.e., it should be sent back to the to-be-created WG with the full process of WGLC, IETF LC, IESG evaluation. Else, why re-charter this WG ?

[Ballot comment]
I am puzzled by `base document produced by the working group includes normative references to this document`, if I understand the sentence correctly (the use of `this` is a little ambiguous), then a RFC was published with a draft as a normative reference ? Or is the 'original document' not yet published hence this WG (see my BLOCK points as it is really unclear).

Also suggest to request the RFC Editor & the AD to remove the `base document` from the RFC editor queue and send it back to the WG as soon as this WG is chartered.

[Ballot comment]
I found some portions of this charter text odd. I understand the peculiar situation here but still have some concerns and suggestions to address them.

1) The document in question does seem to have a nice/clear short title - DMARC Failure Reporting document. Can this name/term be used consistently to refer to it throughout the charter text rather than referring to it with names such as "dangling"?

2) How about something like below to not use this "un-abandon" term and instead something more positive?
CURRENT
There now appears to be consensus to recharter in order to “un-abandon” the dangling document and complete the work.

SUGGEST
There now appears to be consensus to restart the WG in order to adopt the DMARC Failure Reporting document and complete the work for its publication as an IETF Standard.


3) I find the use of "instance" very odd. Why is it necessary given that the history of WG charters is always archived. Do we want to setup a precedent of multi-instance WGs ? IOW, what is lost if we just remove "This instance of" from that sentence? Also, I believe we do have the option of "restarting" WGs for specific purposes after they have concluded previous work - so, we should just say "restart" (or something like that).

4) I don't find the below sentence as being necessary in the charter since it is about document processing and the IESG are not bound by WG charters as far as this process is concerned. What, if anything, is lost if this sentence is taken away?

CURRENT
The responsible Area Director will have discretion regarding whether a full Last Call and IESG loop is needed to review those limited modifications.

[Ballot comment]
# Internet AD comments for charter-ietf-dmarc-02-00
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

## Comments

* "There now appears to be consensus to recharter in order to “un-abandon”
  the dangling document and complete the work."

  If/when approved, this sentence won't make much sense. It was useful for
  background (thank you), but can probably deleted from subsequent revisions.

[Ballot comment]
** Per:
“However, the working group may
reclaim the base document from the RFC Editor only if”

(Editorial) Shouldn’t this sentence be written without “only” – “However, the working group, with AD concurrence, may reclaim the base document from the RFC Editor if …”

(Process point) Added the words about the AD because technically, the WG can’t pull the document back themselves.

** Per:
“The responsible Area
Director will have discretion regarding whether a full Last Call and
IESG loop is needed to review those limited modifications.”

Why is this sentence needed?  The process described is always the case.

[Ballot comment]
Please find some comments below:

# I guess this will be deleted from the version to be sent for external review:

CURRENT:
  DMARC Charter [DRAFT]

# Not sure which "consensus" we are talking about here. I think that we can simply delete this sentence:

CURRENT:
  There now appears to be consensus to recharter
  in order to “un-abandon” the dangling document and complete the work.

# An instance of a WG: what does that mean?

CURRENT:
  This instance of the DMARC working group

# Business as usual

CURRENT:
  The responsible Area
  Director will have discretion regarding whether a full Last Call and
  IESG loop is needed to review those limited modifications.

Not sure we need to have in this in the charter. "normal" process will be followed for these matters, IMO.

# Should we include a formal milestone for this check?

CURRENT:
  If it fails to meet this deadline or reaches consensus to cease work
  on the document, it will abandon that objective and instead begin the
  work of removing all references from the base document to the failure
  reporting document, and the latter will be permanently abandoned.

Thank you.

Cheers,
Med

This charter is to finish the DMARC failure reporting document which is a normative reference in other documents submitted for publication by the DMARC working group, which was closed.

[Ballot comment]
I support Alissa's 2nd block point.

I _think_ this section 4 is about MTA-MTA authentication, right? For example, s/mime or other e2e signature enhancements would not be in scope, would they? How about new user-to-MUA authentication methods?

[Ballot block]
(1) I realize this re-charter is motivated by a small update, but it seems confusing to maintain text that is out-of-date when publishing a re-charter. Someone already pointed out the issue with RFC 7960; I would also argue that the following change is needed:

OLD
The existing DMARC base specification has been submitted as an
  Independent Submission to become an Informational RFC.
NEW
The existing DMARC base specification has been published as RFC 7489 in the Independent Stream.

(2) "Any issues related to the email authentication space ..." seems like a rather broad charge. I understand the desire to work on draft-levine-appsarea-eaiauth, but does that really justify this much wider charter expansion? I feel like the point of the chartering process is to avoid this kind of catch-all.

[Ballot comment]
"2. Reviewing and improving the base DMARC specification

  The working group will not develop additional mail authentication
  technologies, but may document authentication requirements that are
  desirable."

It's not clear how documenting authentication requirements implies directly improving the base specification.

[Ballot comment]
This is a small Charter update to allow the WG to work on related specs, e.g. to update DKIM/SPF/DMARC to support EAI (internationalized email).

Changed charter milestone "Complete Authenticated Received Chain (ARC) usage recommendations", set due date to February 2019 from February 2017, added draft-ietf-dmarc-arc-usage to milestone, removed draft-jones-arc-usage from milestone

[Ballot comment]

I think the intent here is that the base spec could be updated
or obsoleted by the WG if there's a real need to do that. Given
the history, it could be useful to find a way to say that that
might happen, while still including the "seek to preserve" etc
language which is good. But I'm ok with this as-is if such a
change might re-open a rathole discussion.

[Ballot comment]
> The existing base specification is being submitted as an Independent
>  Submission to become an Informational RFC.

This implies the action is in the present when in fact the submission already occured and in the future still will have.

"The existing base specification (draft-kucherawy-dmarc-base) was submitted as a draft Independent Submission."

I think summarizes what happened.

[Ballot block]
This seems like a reasonable compromise with the overall DMARC effort.  However, this charter seems to provide pretty huge scope.  Can it be cut up into a few chunks?  It already specifies phases; perhaps we could charter only the first phase now?  What's the compelling reason to charter all this work in one fell swoop?