Skip to main content

Certificate Management Protocol (CMP) Algorithms
draft-ietf-lamps-cmp-algorithms-15

Revision differences

Document history

Date Rev. By Action
2024-01-26
15 Gunter Van de Velde Request closed, assignment withdrawn: Niclas Comstedt Telechat OPSDIR review
2024-01-26
15 Gunter Van de Velde Closed request for Telechat review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-10-30
15 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-09-19
15 (System) RFC Editor state changed to AUTH48
2023-08-08
15 (System) RFC Editor state changed to RFC-EDITOR from REF
2023-07-10
15 (System) RFC Editor state changed to REF from EDIT
2023-05-30
15 (System) RFC Editor state changed to EDIT from MISSREF
2023-03-21
15 Russ Housley Added to session: IETF-116: lamps  Wed-0030
2022-07-13
15 Russ Housley Added to session: IETF-114: lamps  Wed-1000
2022-06-12
15 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-06-12
15 Tero Kivinen Assignment of request for Last Call review by SECDIR to Liang Xia was marked no-response
2022-06-09
15 (System) IANA Action state changed to No IANA Actions from In Progress
2022-06-09
15 (System) RFC Editor state changed to MISSREF
2022-06-09
15 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-06-09
15 (System) Announcement was received by RFC Editor
2022-06-09
15 (System) IANA Action state changed to In Progress
2022-06-09
15 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-06-09
15 Cindy Morgan IESG has approved the document
2022-06-09
15 Cindy Morgan Closed "Approve" ballot
2022-06-09
15 Cindy Morgan Ballot approval text was generated
2022-06-09
15 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-06-02
15 (System) Removed all action holders (IESG state changed)
2022-06-02
15 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2022-06-02
15 Sabrina Tanamal IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-06-02
15 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2022-06-02
15 Robert Wilton
[Ballot comment]
Similar to Martin Duke's comment I found it hard to understand what the actual purpose of this document is and hence giving a …
[Ballot comment]
Similar to Martin Duke's comment I found it hard to understand what the actual purpose of this document is and hence giving a bit more context in the introduction may help readers understand the purpose of this document.

Regards,
Rob
2022-06-02
15 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-06-02
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-06-02
15 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-15.txt
2022-06-02
15 (System) New version approved
2022-06-02
15 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2022-06-02
15 Hendrik Brockhaus Uploaded new revision
2022-06-02
14 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on the updates.

This document is expected to be concise as far as I know.  However, it is odd that …
[Ballot comment]
Thanks for working on the updates.

This document is expected to be concise as far as I know.  However, it is odd that the introduction section does not have any description other than terminology section. This  will be very hard for a reader, specially new to this topic, to get the context. I would at least expect some narratives and some references for the readers. Please consider this.
2022-06-02
14 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-06-01
14 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-06-01
14 Erik Kline
[Ballot comment]
# Internet AD comments for {draft-ietf-lamps-cmp-algorithms-14}
CC @ekline

## Nits

### S2.2

* "as one-way hash function" -> "as a one-way …
[Ballot comment]
# Internet AD comments for {draft-ietf-lamps-cmp-algorithms-14}
CC @ekline

## Nits

### S2.2

* "as one-way hash function" -> "as a one-way hash function"?
2022-06-01
14 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-06-01
14 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-06-01
14 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Process note to the IESG: Lars already mentioned this, but reminder - we need to …
[Ballot comment]
Thank you for the work on this document.

Process note to the IESG: Lars already mentioned this, but reminder - we need to approve RFC 8018 as downref in conformance with RFC 8067 (and add it to the downref registry, since as Russ pointed it out, it has already been Last Called as downref for RFC 9045: https://mailarchive.ietf.org/arch/msg/spasm/mmBskP8o1BjKCSYoOXAj1Ik0grA/ ) since it was not Last Called for this document.

Francesca
2022-06-01
14 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-06-01
14 Paul Wouters
[Ballot comment]
Overall the document looks fine, although I wish it had copied less content and depended only on the references cited to avoid accidental …
[Ballot comment]
Overall the document looks fine, although I wish it had copied less content and depended only on the references cited to avoid accidental errors. I think I checked most of these and they seem fine, but it is possible authors/reviewers up to now have made a mistake.

Old DISCUSS:
My only DISCUSS item is on recommending PBKDF2. It is kind of showing it age, and we have a much better replacement with argon2 (RFC 9106). Is there a reason why not to recommend some argon2 setting instead of PBKDF2 ?

Resolved with:
Mike Ounsworth wrote:
Soooooo .... you're gonna shake your head at this, but CMP only supports id-PasswordBasedMac (RFC 4210 section 5.1.3.1), which is sorta PBKDF1 (and not FIPS approved), and therefore a fully RCF4210-compliant CMP implementation will fail a FIPS certification. So "modernizing" CMP to support real PBKDF2 was actually a driving reason for this cmp-algorithms draft in the first place

Your suggestion to add Argon2 to CMP seems good to me, but A) is only useful outside of FIPS-compliant domains (argon2 is not FIPS approved), and B) would likely delay this draft many months, especially if this is the first use of Argon2 in PKIX, in which case we'll have to define OIDs, ASN.1 structs, etc. So based on that, I think I vote to let this document proceed without it. I would support a followup draft that introduces Argon2 for PKIX.
2022-06-01
14 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss
2022-06-01
14 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss
2022-06-01
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-05-31
14 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-05-31
14 Martin Duke
[Ballot comment]
It would be nice if the Introduction motivated this document, perhaps using some of the words in the Security Considerations. I didn’t really …
[Ballot comment]
It would be nice if the Introduction motivated this document, perhaps using some of the words in the Security Considerations. I didn’t really understand what this was trying to do until I got there.
2022-05-31
14 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2022-05-30
14 Paul Wouters
[Ballot discuss]
Overall the document looks fine, although I wish it had copied less content and depended only on the references cited to avoid accidental …
[Ballot discuss]
Overall the document looks fine, although I wish it had copied less content and depended only on the references cited to avoid accidental errors. I think I checked most of these and they seem fine, but it is possible authors/reviewers up to now have made a mistake.

My only DISCUSS item is on recommending PBKDF2. It is kind of showing it age, and we have a much better replacement with argon2 (RFC 9106). Is there a reason why not to recommend some argon2 setting instead of PBKDF2 ?
2022-05-30
14 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2022-05-25
14 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-05-25
14 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-14.txt
2022-05-25
14 (System) New version approved
2022-05-25
14 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2022-05-25
14 Hendrik Brockhaus Uploaded new revision
2022-05-25
13 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from No Record
2022-05-25
13 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-lamps-cmp-algorithms-13

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/v27X7uDX89t_1_CtUsEdOpxjJcY). …
[Ballot comment]
# GEN AD review of draft-ietf-lamps-cmp-algorithms-13

CC @larseggert

Thanks to Dan Romascanu for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/v27X7uDX89t_1_CtUsEdOpxjJcY).

## Comments

### DOWNREFs

DOWNREF `[RFC8018]` from this Proposed Standard to Informational `RFC8018`.
(For IESG discussion. It seems this DOWNREF was not mentioned in the Last Call
and also seems to not appear in the DOWNREF registry.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Grammar/style

#### Section 1, paragraph 0
```
er and output values are provided. Theses ASN.1 values and types are defined
                                  ^^^^^^
```
Did you mean "these"?

#### Section 2.1, paragraph 3
```
(SHAKEs) SHAKE128 and SHAKE256. Currently SHAKE128 and SHAKE256 are the onl
                                ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Currently".

#### Section 7, paragraph 14
```
Usage by CMP To avoid consuming too much computational resources it is recomm
                                    ^^^^
```
Use "many" with countable plural nouns like "resources".

#### Section 7, paragraph 14
```
[RFC4210] which SHOULD NOT be used anymore +============+==============+=====
                                  ^^^^^^^
```
Make sure that "anymore" is used as an adverb, not as an adjective. Did you
mean "any more"?

#### Section 7.2, paragraph 2
```
ted by conforming implementations. Theses algorithms were appropriate at the
                                  ^^^^^^
```
Did you mean "these"?

#### Section 7.2, paragraph 7
```
h CMP to offer implementer a more up to date choice. Finally, the algorithms
                                  ^^^^^^^^^^
```
It appears that hyphens are missing in the adjective "up-to-date".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-05-25
13 Lars Eggert Ballot comment text updated for Lars Eggert
2022-05-23
13 Warren Kumari
[Ballot comment]
Thank you for this document.

The "How the IESG Ballots" page (https://www.ietf.org/standards/process/iesg-ballots/) says:
"The No Objection ballot position, also abbreviated as …
[Ballot comment]
Thank you for this document.

The "How the IESG Ballots" page (https://www.ietf.org/standards/process/iesg-ballots/) says:
"The No Objection ballot position, also abbreviated as NoObj, might be used in these cases:
This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs."

Sadly the above doesn't include a "this is **way** outside my area of expertise, but I recognize at least a few of the words, and Roman says it's all good, so... ¯\_(ツ)_/¯ ?". I'm interpreting that as being in the spirit of NoObj...
2022-05-23
13 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-05-17
13 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-05-16
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Niclas Comstedt
2022-05-16
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Niclas Comstedt
2022-05-13
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-05-13
13 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-13.txt
2022-05-13
13 (System) New version approved
2022-05-13
13 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2022-05-13
13 Hendrik Brockhaus Uploaded new revision
2022-05-11
12 Roman Danyliw Placed on agenda for telechat - 2022-06-02
2022-05-11
12 Roman Danyliw Please revise the document before the telchat per the OPSDIR and GENART review.
2022-05-11
12 Roman Danyliw Ballot has been issued
2022-05-11
12 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2022-05-11
12 Roman Danyliw Created "Approve" ballot
2022-05-11
12 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup
2022-05-11
12 Roman Danyliw Ballot writeup was changed
2022-05-11
12 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-05-08
12 Qin Wu Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Qin Wu. Sent review to list.
2022-05-06
12 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dan Romascanu. Sent review to list.
2022-05-05
12 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2022-05-05
12 (System)
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lamps-cmp-algorithms-12, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lamps-cmp-algorithms-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist
2022-05-05
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2022-05-05
12 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2022-05-03
12 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2022-05-03
12 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2022-05-01
12 Gyan Mishra Assignment of request for Last Call review by GENART to Gyan Mishra was rejected
2022-04-28
12 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2022-04-28
12 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2022-04-28
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2022-04-28
12 Tero Kivinen Request for Last Call review by SECDIR is assigned to Liang Xia
2022-04-27
12 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-04-27
12 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-05-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-cmp-algorithms@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org …
The following Last Call announcement was sent out (ends 2022-05-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-cmp-algorithms@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Certificate Management Protocol (CMP) Algorithms) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Certificate
Management Protocol (CMP) Algorithms'
  as Proposed Standard

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
last-call@ietf.org mailing lists by 2022-05-11. 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


  This document updates RFC 4210 describing the conventions for using
  concrete cryptographic algorithms with the Certificate Management
  Protocol (CMP).  CMP is used to enroll and further manage the
  lifecycle of X.509 certificates.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-algorithms/



No IPR declarations have been submitted directly on this I-D.




2022-04-27
12 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-04-27
12 Cindy Morgan Last call announcement was generated
2022-04-26
12 Roman Danyliw Last call was requested
2022-04-26
12 Roman Danyliw Last call announcement was generated
2022-04-26
12 Roman Danyliw Ballot approval text was generated
2022-04-26
12 Roman Danyliw Ballot writeup was generated
2022-04-26
12 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-04-06
12 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-12.txt
2022-04-06
12 (System) New version accepted (logged-in submitter: Hendrik Brockhaus)
2022-04-06
12 Hendrik Brockhaus Uploaded new revision
2022-02-15
11 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-11.txt
2022-02-15
11 (System) New version approved
2022-02-15
11 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2022-02-15
11 Hendrik Brockhaus Uploaded new revision
2022-02-14
10 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-02-14
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-02-14
10 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-10.txt
2022-02-14
10 (System) New version approved
2022-02-14
10 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2022-02-14
10 Hendrik Brockhaus Uploaded new revision
2022-01-11
09 Roman Danyliw Pending revision per https://mailarchive.ietf.org/arch/msg/spasm/xXjpLOubAZw2VcM2I5rfSG2CD9M/
2022-01-11
09 (System) Changed action holders to Roman Danyliw, Mike Ounsworth, John Gray, Hendrik Brockhaus, Hans Aschauer (IESG state changed)
2022-01-11
09 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2021-12-22
09 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-09.txt
2021-12-22
09 (System) New version approved
2021-12-22
09 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2021-12-22
09 Hendrik Brockhaus Uploaded new revision
2021-11-17
08 (System) Changed action holders to Roman Danyliw (IESG state changed)
2021-11-17
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-17
08 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-08.txt
2021-11-17
08 (System) New version approved
2021-11-17
08 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2021-11-17
08 Hendrik Brockhaus Uploaded new revision
2021-10-26
07 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/spasm/oe3b2yFLHsI3O18ug_3yNHcU-z8/
2021-10-26
07 (System) Changed action holders to Roman Danyliw, Mike Ounsworth, John Gray, Hendrik Brockhaus, Hans Aschauer (IESG state changed)
2021-10-26
07 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2021-10-06
07 Russ Housley
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 4210, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document describes the conventions for using concrete
  cryptographic algorithms with the Certificate Management Protocol
  (CMP).  CMP is used to enroll and further manage the lifecycle of
  X.509 certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    This document is needed to specify the conventions for using
    modern cryptographic algorithms.
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(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 went through many iterations, with discussion at several
  points on the LAMPS mail list.  Then, the  WG Last Call was essentially
  silent, which indicates that the earlier issues were addressed in a
  satisfactory way.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(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.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(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?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(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?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 4210.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  There is a normative dependency on draft-ietf-lamps-cmp-updates.
  The LAMPS WG is about to enter WG Last Call on this document.  In
  addition, draft-ietf-lamps-lightweight-cmp-profile has dependencies
  on this document and draft-ietf-lamps-cmp-updates.

  There is a desire for all three of these documents to receive
  consecutive RFC numbers.


(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 downward normative reference to Informational RFC 2104,
  RFC 3394, RFC 5753, RFC 8017, and RFC 8032; however, these documents
  are already in the downref registry, so no special action is
  needed for them.

  There is also a downward normative reference to Informational RFC 8018.
  This document is (surprisingly) not already in the downref registry, so
  it needs to be called out in the IETF Last Call.  Once this happens,
  please add RFC 8018 to the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 4210, which is clearly stated on the
  title page, but it is not (yet) stated in the Abstract.  I have asked
  the authors to handle it whenever the next revision is needed from
  AD Review or IETF Last Call.


(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.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(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.

  No new IANA registries are needed.


(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.

  None are needed.
2021-10-06
07 Russ Housley
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 4210, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document describes the conventions for using concrete
  cryptographic algorithms with the Certificate Management Protocol
  (CMP).  CMP is used to enroll and further manage the lifecycle of
  X.509 certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    This document is needed to specify the conventions for using
    modern cryptographic algorithms.
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(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 went through many iterations, with discussion at several
  points on the LAMPS mail list.  Then, the  WG Last Call was essentially
  silent, which indicates that the earlier issues were addressed in a
  satisfactory way.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(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.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(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?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(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?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 4210.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  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 downward normative reference to Informational RFC 2104,
  RFC 3394, RFC 5753, RFC 8017, and RFC 8032; however, these documents
  are already in the downref registry, so no special action is
  needed for them.

  There is also a downward normative reference to Informational RFC 8018.
  This document is (surprisingly) not already in the downref registry, so
  it needs to be called out in the IETF Last Call.  Once this happens,
  please add RFC 8018 to the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 4210, which is clearly stated on the
  title page, but it is not (yet) stated in the Abstract.  I have asked
  the authors to handle it whenever the next revision is needed from
  AD Review or IETF Last Call.


(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.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(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.

  No new IANA registries are needed.


(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.

  None are needed.
2021-10-05
07 Russ Housley
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 4210, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document describes the conventions for using concrete
  cryptographic algorithms with the Certificate Management Protocol
  (CMP).  CMP is used to enroll and further manage the lifecycle of
  X.509 certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    This document is needed to specify the conventions for using
    modern cryptographic algorithms.
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(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 went through many iterations, with discussion at several
  points on the LAMPS mail list.  Then, the  WG Last Call was essentially
  silent, which indicates that the earlier issues were addressed in a
  satisfactory way.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(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.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(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?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(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?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 4210.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  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 downward normative reference to Informational RFC 2104,
  RFC 3394, RFC 5753, RFC 8017, and RFC 8032; however, these documents
  are already in the downref registry, so no special action is
  needed for them.

  There is also a downward normative reference to Informational RFC 8018.
  This document is (surprisingly) not already in the downref registry, so
  it needs to be called out in the IETF Last Call.  Once this happens,
  please add RFC 8018 to the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 4210, which is clearly stated on the
  title page, but it is not (yet) stated in the Abstract.  I have asked
  the authors to handle it whenever the next revision is needed from
  AD Review or IETF Last Call.


(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.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(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.

  No new IANA registries are needed.


(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.

  None are needed.
2021-10-04
07 Russ Housley
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 4210, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document describes the conventions for using concrete
  cryptographic algorithms with the Certificate Management Protocol
  (CMP).  CMP is used to enroll and further manage the lifecycle of
  X.509 certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    This document is needed to specify the conventions for using
    modern cryptographic algorithms.
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(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 went through many iterations, with discussion at several
  points on the LAMPS mail list.  Then, the  WG Last Call was essentially
  silent, which indicates that the earlier issues were addressed in a
  satisfactory way.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(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.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(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?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(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?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 5480.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes, all of them are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  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 downward normative reference to Informational RFC 2104,
  RFC 3394, RFC 5753, RFC 8017, and RFC 8032; however, these documents
  are already in the downref registry, so no special action is
  needed for them.

  There is also a downward normative reference to Informational RFC 8018.
  This document is (surprisingly) not already in the downref registry, so
  it needs to be called out in the IETF Last Call.  Once this happens,
  please add RFC 8018 to the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 4210, which is clearly stated on the
  title page, but it is not (yet) stated in the Abstract.  I have asked
  the authors to handle it whenever the next revision is needed from
  AD Review or IETF Last Call.


(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.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(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.

  No new IANA registries are needed.


(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.

  None are needed.
2021-10-04
07 Russ Housley Responsible AD changed to Roman Danyliw
2021-10-04
07 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-10-04
07 Russ Housley IESG state changed to Publication Requested from I-D Exists
2021-10-04
07 Russ Housley IESG process started in state Publication Requested
2021-10-04
07 Russ Housley Changed consensus to Yes from Unknown
2021-10-04
07 Russ Housley Intended Status changed to Proposed Standard from None
2021-10-04
07 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-10-04
07 Russ Housley
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-lamps-cmp-algorithms-07


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for Standards Track.
 
  This new RFC will update RFC 4210, which is a Proposed Standard.
 

(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  This document describes the conventions for using concrete
  cryptographic algorithms with the Certificate Management Protocol
  (CMP).  CMP is used to enroll and further manage the lifecycle of
  X.509 certificates.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    This document is needed to specify the conventions for using
    modern cryptographic algorithms.
   
  Personnel:

    Russ Housley is the document shepherd.
    Roman Danyliw is the responsible area director.


(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 went through many iterations, with discussion at several
  points on the LAMPS mail list.  Then, the  WG Last Call was essentially
  silent, which indicates that the earlier issues were addressed in a
  satisfactory way.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(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.

  Several people that were involved in the PKIX WG were part of the
  review that took place during LAMPS WG Last Call.


(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?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(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?

  The authors have explicitly stated that they are unaware of any
  additional IP that was introduced in the updates to the document.

  The authors have explicitly stated that they do not hold any IPR
  related to the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the LAMPS WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document, once it is approved, will update RFC 5480.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes, all of them are normative.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  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 downward normative reference to Informational RFC 2104,
  RFC 3394, RFC 5753, RFC 8017, and RFC 8032; however, these documents
  are already in the downref registry, so no special action is
  needed for them.

  There is also a downward normative reference to Informational RFC 8018.
  This document is (surprisingly) not already in the downref registry, so
  it needs to be called out in the IETF Last Call.  Once this happens,
  please add RFC 8018 to the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  This new RFC will update RFC 4210, which is clearly stated on the
  title page, but it is not (yet) stated in the Abstract.  I have asked
  the authors to handle it whenever the next revision is needed from
  AD Review or IETF Last Call.


(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.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(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.

  No new IANA registries are needed.


(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.

  None are needed.
2021-09-13
07 Russ Housley Notification list changed to housley@vigilsec.com because the document shepherd was set
2021-09-13
07 Russ Housley Document shepherd changed to Russ Housley
2021-09-13
07 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2021-08-22
07 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-07.txt
2021-08-22
07 (System) New version approved
2021-08-22
07 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2021-08-22
07 Hendrik Brockhaus Uploaded new revision
2021-07-06
06 Russ Housley Added to session: IETF-111: lamps  Mon-1430
2021-07-06
06 Russ Housley Removed from session: IETF-111: lamps  Thu-1500
2021-07-06
06 Russ Housley Added to session: IETF-111: lamps  Thu-1500
2021-06-30
06 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-06.txt
2021-06-30
06 (System) New version approved
2021-06-30
06 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2021-06-30
06 Hendrik Brockhaus Uploaded new revision
2021-05-07
05 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-05.txt
2021-05-07
05 (System) New version approved
2021-05-07
05 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , John Gray , Mike Ounsworth
2021-05-07
05 Hendrik Brockhaus Uploaded new revision
2021-05-05
04 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-04.txt
2021-05-05
04 (System) New version approved
2021-05-05
04 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , Mike Ounsworth , Serge Mister , lamps-chairs@ietf.org
2021-05-05
04 Hendrik Brockhaus Uploaded new revision
2021-02-22
03 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-03.txt
2021-02-22
03 (System) New version approved
2021-02-22
03 (System) Request for posting confirmation emailed to previous authors: Hans Aschauer , Hendrik Brockhaus , Mike Ounsworth , Serge Mister
2021-02-22
03 Hendrik Brockhaus Uploaded new revision
2021-01-20
02 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-02.txt
2021-01-20
02 (System) New version approved
2021-01-20
02 (System) Request for posting confirmation emailed to previous authors: Hendrik Brockhaus , lamps-chairs@ietf.org
2021-01-20
02 Hendrik Brockhaus Uploaded new revision
2020-11-10
01 Russ Housley Added to session: IETF-109: lamps  Tue-1600
2020-11-02
01 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-01.txt
2020-11-02
01 (System) New version approved
2020-11-02
01 (System) Request for posting confirmation emailed to previous authors: Hendrik Brockhaus
2020-11-02
01 Hendrik Brockhaus Uploaded new revision
2020-10-24
00 Hendrik Brockhaus New version available: draft-ietf-lamps-cmp-algorithms-00.txt
2020-10-24
00 (System) WG -00 approved
2020-10-24
00 Hendrik Brockhaus Set submitter to "Hendrik Brockhaus ", replaces to (none) and sent approval email to group chairs: lamps-chairs@ietf.org
2020-10-24
00 Hendrik Brockhaus Uploaded new revision