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

# 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"?

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

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

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.

# 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

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.

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