The Authenticated Received Chain (ARC) Protocol
draft-ietf-dmarc-arc-protocol-23
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-04
|
23 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-13
|
23 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-03
|
23 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2019-05-29
|
23 | (System) | RFC Editor state changed to REF from EDIT |
2019-04-24
|
23 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-12-21
|
23 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-12-21
|
23 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-12-21
|
23 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-12-21
|
23 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-12-19
|
23 | (System) | RFC Editor state changed to MISSREF |
2018-12-19
|
23 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-12-19
|
23 | (System) | Announcement was received by RFC Editor |
2018-12-19
|
23 | (System) | IANA Action state changed to In Progress |
2018-12-19
|
23 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-12-19
|
23 | Amy Vezza | IESG has approved the document |
2018-12-19
|
23 | Amy Vezza | Closed "Approve" ballot |
2018-12-19
|
23 | Amy Vezza | Ballot approval text was generated |
2018-12-19
|
23 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-12-18
|
23 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-23.txt |
2018-12-18
|
23 | (System) | New version approved |
2018-12-18
|
23 | (System) | Request for posting confirmation emailed to previous authors: Seth Blank , Murray Kucherawy , Kurt Andersen , Brandon Long |
2018-12-18
|
23 | Kurt Andersen | Uploaded new revision |
2018-12-13
|
22 | Alexey Melnikov | Document: draft-ietf-dmarc-arc-protocol (1) The RFC is marked "Experimental", and it is listed correctly. This is the proper RFC. (2) Technical Summary: The Authenticated … Document: draft-ietf-dmarc-arc-protocol (1) The RFC is marked "Experimental", and it is listed correctly. This is the proper RFC. (2) Technical Summary: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles a message to see what entities have handled it before, and to see what the message's authentication assessment was at each step in the handling. This allows to convey original authentication assessments across trust boundaries. Working Group Summary: The working group process was quite involved, and because this document is Experimental, there was active discussions on implementations and experiments that are detailed in the document. Additionally, an example is included in Appendix B to show a mock up of a message that has multiple ARC signatures. Document Quality: The document lists the existing implementations of the protocol, and appears to cover a broad spectrum of both puchased software as well as open source. Personnel: Document Shepherd: Tim Wicinski Area Director: Alexey Melnikov (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd first did a technical review of the document; and followed that with an editorial review. There were several small editorial issues that were passed along to the authors, but do not affect the document itself. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd does not have any concerns about the depth or breath of reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other reviews are needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? There are no concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors have confirmed there are no known IPR disclosures. (8) Has an IPR disclosure been filed that references this document? There are no IPR disclosures. (9) How solid is the WG consensus behind this document? Consensus is strong, and is both broad and deep in terms of the working group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None needed (13) Have all references within this document been identified as either normative or informative? All references have been identified as normative or informative. The only concern is the Informative References refer to previous versions of this document. This should not be a problem moving forward, but it could be addressed. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. There are no new IANA registries created by this document. There are additions to existing registries, and the Document Shepherd's review confirms the registries are clearly identified, and the additions are consistent. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. |
2018-12-13
|
22 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2018-12-12
|
22 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-12-12
|
22 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-22.txt |
2018-12-12
|
22 | (System) | New version approved |
2018-12-12
|
22 | (System) | Request for posting confirmation emailed to previous authors: Seth Blank , Murray Kucherawy , Kurt Andersen , Brandon Long |
2018-12-12
|
22 | Kurt Andersen | Uploaded new revision |
2018-12-04
|
21 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::Point Raised - writeup needed |
2018-11-21
|
21 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2018-11-21
|
21 | Benjamin Kaduk | [Ballot comment] Section 3 Do we really need a trailer appended to the (new) BCP 14 boilerplate? Section 3.5 (I note that "Seal" is used … [Ballot comment] Section 3 Do we really need a trailer appended to the (new) BCP 14 boilerplate? Section 3.5 (I note that "Seal" is used in other IETF contents to enclude encryption, e.g., RFC 1508. I don't see a need for this usage to change, though.) Section 9.2 Are there any concerns about privacy relating to the possibility of using a tailored set of [ARC Sets inducing] DNS queries, to fingerprint/identify specific clients/recipients? |
2018-11-21
|
21 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-11-21
|
21 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3829 These would be DISCUSS-worthy comments but this is an Experimental document so I am just making … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3829 These would be DISCUSS-worthy comments but this is an Experimental document so I am just making them comments. IMPORTANT S 9. > handlers for a message. This record may include Personally > Identifiable Information such as IP address(es) and domain names. > Such information is also included in existing non-ARC related header > fields such as the "Received" header fields. > > 9. Security Considerations You need to document what the semantics of a received message with an ARC Chain is. As I understand it, it's that the highest-numbered instance N vouches that: It processed a message with this body, a given authres, and ARC chains 1..N-1. And then instance N-1 vouches that it received a message with a given authres, and ARC chains 1..N-2, and so on. Is that correct? COMMENTS S 4.1.3. > > To preserve the ability to verify the integrity of a message, the > signature of the AMS header field SHOULD include any DKIM-Signature > header fields already present in the message. > > 4.1.3. ARC-Seal (AS) It would be useful to state the rationale here for why you have separate signatures for headers and body. S 7.2. > Through the collection of ARC-related data, an ADMD can identify > handling paths that have broken authentication. > > An Authenticated Received Chain allows an Internet Mail Handler to > potentially base decisions of message disposition on authentication > assessments provided by different ADMDs. "potentially base" seems pretty handwavy. As below, I think you need to provide some guidance about what on would actually do. |
2018-11-21
|
21 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-11-21
|
21 | Benjamin Kaduk | [Ballot comment] [I may not get to finish reading this by the telechat time, but noted in reading the DMARC charter that The working … [Ballot comment] [I may not get to finish reading this by the telechat time, but noted in reading the DMARC charter that The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. This work is not exactly an authentication technology, in that it just claims to allow additional recording of existing authentication processing, but it does seem that such recorded results might then be used as part of authentication decisions later down the line. I assume everyone is okay with this situation, based on ballot positions so far.] |
2018-11-21
|
21 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-11-21
|
21 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-11-21
|
21 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-11-20
|
21 | Adam Roach | [Ballot comment] Thanks to everyone for the work that went into this document. I'm excited by this experiment, and hope it eventually grows into something … [Ballot comment] Thanks to everyone for the work that went into this document. I'm excited by this experiment, and hope it eventually grows into something we can put on the standards track. --------------------------------------------------------------------------- id-nits reports: ** There are 3 instances of too long lines in the document, the longest one being 15 characters in excess of 72. --------------------------------------------------------------------------- §7.2: > remote-ip[1]=10.10.10.13 Please consider using an IPv6 address here. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ In any case, please use an address from the ranges reserved by either RFC 5737 or (preferably) RFC 3849. --------------------------------------------------------------------------- Appendix B: > Received: from example.org (example.org [208.69.40.157]) ... > Received: from segv.d1.example (segv.d1.example [72.52.75.15]) ... > Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) ... > [208.69.40.157]) by clochette.example.org with ESMTP id The two comments I made on §7.2 apply to these four IP addresses as well. |
2018-11-20
|
21 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-11-20
|
21 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-11-20
|
21 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-11-20
|
21 | Ben Campbell | [Ballot comment] Thanks for including the Experimental Considerations |
2018-11-20
|
21 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-11-20
|
21 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-11-19
|
21 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-11-19
|
21 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-11-19
|
21 | Ines Robles | Request for Telechat review by GENART Completed: Ready. Reviewer: Ines Robles. Sent review to list. |
2018-11-16
|
21 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-11-07
|
21 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ines Robles |
2018-11-07
|
21 | Jean Mahoney | Request for Telechat review by GENART is assigned to Ines Robles |
2018-11-07
|
21 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-21.txt |
2018-11-07
|
21 | (System) | New version approved |
2018-11-07
|
21 | (System) | Request for posting confirmation emailed to previous authors: Seth Blank , Murray Kucherawy , Kurt Andersen , Brandon Long |
2018-11-07
|
21 | Kurt Andersen | Uploaded new revision |
2018-11-06
|
20 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-20.txt |
2018-11-06
|
20 | (System) | New version approved |
2018-11-06
|
20 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , dmarc-chairs@ietf.org, Murray Kucherawy , Brandon Long |
2018-11-06
|
20 | Kurt Andersen | Uploaded new revision |
2018-11-06
|
19 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-11-05
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-11-05
|
19 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-19.txt |
2018-11-05
|
19 | (System) | New version approved |
2018-11-05
|
19 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Murray Kucherawy , Brandon Long |
2018-11-05
|
19 | Kurt Andersen | Uploaded new revision |
2018-11-03
|
18 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-11-03
|
18 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dmarc-arc-protocol-18. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dmarc-arc-protocol-18. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. IANA understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete. First, in the Email Authentication Result Names registry on the Email Authentication Parameters registry page located at: https://www.iana.org/assignments/email-auth/ three, new values are to be registered as follows: Auth Method(s): arc Code: none Specification: [ RFC-to-be Section 2.2 ] Status: Active Auth Method(s): arc Code: pass Specification: [ RFC-to-be Section 2.2 ] Status: Active Auth Method(s): arc Code: fail Specification: [ RFC-to-be Section 2.2 ] Status: Active As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the Email Authentication Methods registry also on the Email Authentication Parameters registry page located at: https://www.iana.org/assignments/email-auth/ three, new values are to be registered as follows: Method: arc Definition: [ RFC-to-be ] ptype: smtp Property: client-ip Value: IP address of originating SMTP connection Status: active Version: 1 Method: arc Definition: [ RFC-to-be ] ptype: header Property: oldest-pass Value: The instance id of the oldest validating AMS, or 0 if they all pass (see Section 5.2 of [ RFC-to-be ]) Status: active Version: 1 Method: dkim Definition: [ draft-ietf-dmarc-rfc7601bis ] ptype: header Property: s Value: value of signature "s" tag Status: active Version: 1 As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the Permanent Message Header Field Registry on the Message Headers registry page located at: https://www.iana.org/assignments/message-headers/ there are three registrations that will have their references changed to [ RFC-to-be ]: Header field name: ARC-Seal Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): [ RFC-to-be ] Related information: [RFC6376] Header field name: ARC-Message-Signature Applicable protocol: mail Status: draft Author/Change controller: IETF Specification document(s): [ RFC-to-be ] Related information: [RFC6376] Header field name: ARC-Authentication-Results Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): [ RFC-to-be ] Related information: [ draft-ietf-dmarc-rfc7601bis ] IANA Question --> Should the "Related Information" references simply be added to the "Reference" field in the Permanent Message Header Field Names registrations? As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Fourth, in the Enumerated Status Codes registry on the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry page located at: https://www.iana.org/assignments/smtp-enhanced-status-codes/ a single, new registration is to be made as follows: Code: X.7.29 Sample Text: ARC validation failure Associated basic status code: 550 Description: This status code may be returned when a message fails multiple authentication checks, including ARC validation Reference: [ RFC-to-be ] Submitter: K. Andersen Change controller: IESG As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-11-03
|
18 | Ines Robles | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Ines Robles. Sent review to list. |
2018-10-26
|
18 | Cindy Morgan | Placed on agenda for telechat - 2018-11-21 |
2018-10-26
|
18 | Alexey Melnikov | Ballot has been issued |
2018-10-26
|
18 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-10-26
|
18 | Alexey Melnikov | Created "Approve" ballot |
2018-10-26
|
18 | Alexey Melnikov | Ballot writeup was changed |
2018-10-26
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2018-10-26
|
18 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2018-10-25
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-10-25
|
18 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
2018-10-25
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2018-10-25
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2018-10-23
|
18 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-10-23
|
18 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-06): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski … The following Last Call announcement was sent out (ends 2018-11-06): From: The IESG To: IETF-Announce CC: tjw.ietf@gmail.com, Barry Leiba , draft-ietf-dmarc-arc-protocol@ietf.org, Tim Wicinski , dmarc@ietf.org, alexey.melnikov@isode.com, dmarc-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Authenticated Received Chain (ARC) Protocol) to Experimental RFC The IESG has received a request from the Domain-based Message Authentication, Reporting & Conformance WG (dmarc) to consider the following document: - 'Authenticated Received Chain (ARC) Protocol' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of message handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, to identify Internet Mail Handlers that might break existing authentication mechanisms, and to convey original authentication assessments across trust boundaries. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-10-23
|
18 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-10-23
|
18 | Alexey Melnikov | I have several comments about the document, mostly about incorrect classification of references as Informative. I will send my comments separately. However I don't think … I have several comments about the document, mostly about incorrect classification of references as Informative. I will send my comments separately. However I don't think this should delay IETF LC. |
2018-10-23
|
18 | Alexey Melnikov | Last call was requested |
2018-10-23
|
18 | Alexey Melnikov | Last call announcement was generated |
2018-10-23
|
18 | Alexey Melnikov | Ballot approval text was generated |
2018-10-23
|
18 | Alexey Melnikov | Ballot writeup was generated |
2018-10-23
|
18 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2018-10-23
|
18 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2018-10-23
|
18 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2018-10-22
|
18 | Barry Leiba | Document: draft-ietf-dmarc-arc-protocol (1) The RFC is marked "Experimental", and it is listed correctly. This is the proper RFC. (2) Technical Summary: The Authenticated … Document: draft-ietf-dmarc-arc-protocol (1) The RFC is marked "Experimental", and it is listed correctly. This is the proper RFC. (2) Technical Summary: The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles a message to see what entities have handled it before, and to see what the message's authentication assessment was at each step in the handling. This allows to convey original authentication assessments across trust boundaries. Working Group Summary: The working group process was quite involved, and because this document is Experimental, there was active discussions on implementations and experiments that are detailed in the document. Additionally, examples are included in Appendix B (XXX) to show a mock up of a message at each step in the chain. Document Quality: The document lists the existing implementations of the protocol, and appears to cover a broad spectrum of both puchased software as well as open source. Personnel: Document Shepherd: Tim Wicinski Area Director: Alexey Melnikov (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Document Shepherd first did a technical review of the document; and followed that with an editorial review. There were several small editorial issues that were passed along to the authors, but do not affect the document itself. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The Document Shepherd does not have any concerns about the depth or breath of reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other reviews are needed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? There are no concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors have confirmed there are no known IPR disclosures. (8) Has an IPR disclosure been filed that references this document? There are no IPR disclosures. (9) How solid is the WG consensus behind this document? Consensus is strong, and is both broad and deep in terms of the working group. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. None needed (13) Have all references within this document been identified as either normative or informative? All references have been identified as normative or informative. The only concern is the Informative References refer to previous versions of this document. This should not be a problem moving forward, but it could be addressed. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There are no downward normative references. (16) Will publication of this document change the status of any existing RFCs? No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. There are no new IANA registries created by this document. There are additions to existing registries, and the Document Shepherd's review confirms the registries are clearly identified, and the additions are consistent. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. |
2018-10-22
|
18 | Barry Leiba | Responsible AD changed to Alexey Melnikov |
2018-10-22
|
18 | Barry Leiba | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-10-22
|
18 | Barry Leiba | IESG state changed to Publication Requested |
2018-10-22
|
18 | Barry Leiba | IESG process started in state Publication Requested |
2018-10-22
|
18 | Barry Leiba | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-10-22
|
18 | Barry Leiba | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2018-10-02
|
18 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-18.txt |
2018-10-02
|
18 | (System) | New version approved |
2018-10-02
|
18 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Murray Kucherawy , Brandon Long |
2018-10-02
|
18 | Kurt Andersen | Uploaded new revision |
2018-10-02
|
17 | Tim Wicinski | Changed document writeup |
2018-10-02
|
17 | Tim Wicinski | Changed document writeup |
2018-10-01
|
17 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-17.txt |
2018-10-01
|
17 | (System) | New version approved |
2018-10-01
|
17 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Brandon Long , Murray Kucherawy , Seth Blank , Tim Draegen , dmarc-chairs@ietf.org |
2018-10-01
|
17 | Kurt Andersen | Uploaded new revision |
2018-08-29
|
16 | Barry Leiba | Tag Revised I-D Needed - Issue raised by WGLC set. |
2018-08-29
|
16 | Barry Leiba | Notification list changed to Barry Leiba <barryleiba@computer.org>, Tim Wicinski <tjw.ietf@gmail.com> from Barry Leiba <barryleiba@computer.org> |
2018-08-29
|
16 | Barry Leiba | Document shepherd changed to Tim Wicinski |
2018-08-29
|
16 | Barry Leiba | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2018-07-18
|
16 | Barry Leiba | Notification list changed to Barry Leiba <barryleiba@computer.org> |
2018-07-18
|
16 | Barry Leiba | Document shepherd changed to Barry Leiba |
2018-07-17
|
16 | Barry Leiba | WGLC ends 3 August |
2018-07-17
|
16 | Barry Leiba | IETF WG state changed to In WG Last Call from WG Document |
2018-07-17
|
16 | Barry Leiba | Intended Status changed to Experimental from None |
2018-07-17
|
16 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-16.txt |
2018-07-17
|
16 | (System) | New version approved |
2018-07-17
|
16 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Tim Draegen , Murray Kucherawy , Brandon Long |
2018-07-17
|
16 | Kurt Andersen | Uploaded new revision |
2018-06-24
|
15 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-15.txt |
2018-06-24
|
15 | (System) | New version approved |
2018-06-24
|
15 | (System) | Request for posting confirmation emailed to previous authors: Steven Jones , Kurt Andersen , Brandon Long , Murray Kucherawy , Seth Blank , dmarc-chairs@ietf.org |
2018-06-24
|
15 | Kurt Andersen | Uploaded new revision |
2018-04-23
|
14 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-14.txt |
2018-04-23
|
14 | (System) | New version approved |
2018-04-23
|
14 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Steven Jones , Murray Kucherawy , Brandon Long |
2018-04-23
|
14 | Kurt Andersen | Uploaded new revision |
2018-03-21
|
13 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-13.txt |
2018-03-21
|
13 | (System) | New version approved |
2018-03-21
|
13 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Steven Jones , Murray Kucherawy , Brandon Long |
2018-03-21
|
13 | Kurt Andersen | Uploaded new revision |
2018-03-18
|
12 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-12.txt |
2018-03-18
|
12 | (System) | New version approved |
2018-03-18
|
12 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Steven Jones , Murray Kucherawy , Brandon Long |
2018-03-18
|
12 | Kurt Andersen | Uploaded new revision |
2018-01-22
|
11 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-11.txt |
2018-01-22
|
11 | (System) | New version approved |
2018-01-22
|
11 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Seth Blank , Steven Jones , dmarc-chairs@ietf.org, Brandon Long |
2018-01-22
|
11 | Kurt Andersen | Uploaded new revision |
2017-12-19
|
10 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-10.txt |
2017-12-19
|
10 | (System) | New version approved |
2017-12-19
|
10 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Murray Kucherawy , Steven Jones , dmarc-chairs@ietf.org, Brandon Long |
2017-12-19
|
10 | Kurt Andersen | Uploaded new revision |
2017-09-07
|
09 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-09.txt |
2017-09-07
|
09 | (System) | New version approved |
2017-09-07
|
09 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Murray Kucherawy , Brandon Long |
2017-09-07
|
09 | Kurt Andersen | Uploaded new revision |
2017-07-21
|
08 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-08.txt |
2017-07-21
|
08 | (System) | New version approved |
2017-07-21
|
08 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Murray Kucherawy , Brandon Long |
2017-07-21
|
08 | Kurt Andersen | Uploaded new revision |
2017-07-20
|
07 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-07.txt |
2017-07-20
|
07 | (System) | New version approved |
2017-07-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Brandon Long , dmarc-chairs@ietf.org |
2017-07-20
|
07 | Kurt Andersen | Uploaded new revision |
2017-07-17
|
06 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-06.txt |
2017-07-17
|
06 | (System) | New version approved |
2017-07-17
|
06 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Brandon Long |
2017-07-17
|
06 | Kurt Andersen | Uploaded new revision |
2017-06-29
|
05 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-05.txt |
2017-06-29
|
05 | (System) | New version approved |
2017-06-29
|
05 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Brandon Long |
2017-06-29
|
05 | Kurt Andersen | Uploaded new revision |
2017-06-20
|
04 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-04.txt |
2017-06-20
|
04 | (System) | New version approved |
2017-06-20
|
04 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Brandon Long |
2017-06-20
|
04 | Kurt Andersen | Uploaded new revision |
2017-04-28
|
03 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-03.txt |
2017-04-28
|
03 | (System) | New version approved |
2017-04-28
|
03 | (System) | Request for posting confirmation emailed to previous authors: Kurt Andersen , Steven Jones , Brandon Long |
2017-04-28
|
03 | Kurt Andersen | Uploaded new revision |
2017-03-16
|
02 | Cindy Morgan | New version available: draft-ietf-dmarc-arc-protocol-02.txt |
2017-03-16
|
02 | (System) | Secretariat manually posting. Approvals already received |
2017-03-16
|
02 | Cindy Morgan | Uploaded new revision |
2016-12-02
|
01 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-01.txt |
2016-12-02
|
01 | (System) | New version approved |
2016-12-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Kurt Andersen" , "J. Adams" , "Brandon Long" , "John Rae-Grant" , "Steven Jones" , dmarc-chairs@ietf.org |
2016-12-02
|
01 | Kurt Andersen | Uploaded new revision |
2016-06-25
|
00 | (System) | This document now replaces draft-andersen-arc instead of None |
2016-06-25
|
00 | Kurt Andersen | New version available: draft-ietf-dmarc-arc-protocol-00.txt |