Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol
draft-ietf-ace-cmpv2-coap-transport-10

[Ballot comment]
Thanks for working on this specification. My review did not notice any transport related issues.

However, I have one observation-

  It seems the word "server" has been used in three ways - 1) CMP server, 2) server and 3) pre-configured/configured server. I would be great if 2) and 3) could be described better based on their role. Right now, this is a bit confusing, for example, when only 2) used and it refers to a CMP server.

[Ballot comment]
Thanks for working on this specification. My review did not notice any transport related issues.

However, I have one observation-

  It seems the word "server" has been used in three ways - 1) CMP server, 2) server and 3) pre-configured/configured server. I would be great if 2) and 3) could be described better based on their role. Right now, this is a bit confusing for example when only 2) used and it refers to a CMP server.

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ace-cmpv2-coap-transport-09
CC @jgscudder

Thanks for this document. I have one minor comment below, which I hope may be helpful.

## COMMENTS

### Section 2.6

In the second paragraph below,

  Alternatively, an EE MAY periodically poll for the current status of
  the CA via the "PKI Information Request" message, see section 6.5 of
  [RFC4210].  If supported, EEs may also use "Support Messages" defined
  in section 4.3 of Lightweight CMP Profile
  [I-D.ietf-lamps-lightweight-cmp-profile] to get information about the
  CA status.

  These mechanisms will help constrained devices, that are acting as
  EEs, to conserve resources by eliminating the need to create an
  endpoint for receiving notifications from RA or CA.  It will also
  simplify the implementation of a CoAP-to-HTTP proxy.

is it right that "these mechanisms" refers to the two mechanisms in the immediately-preceding paragraph? If so, this isn't clear from how you've structured the text. One possible rewrite is,

  Two alternatives are first, an EE MAY periodically poll for the
  current status of the CA via the "PKI Information Request" message,
  see section 6.5 of [RFC4210], or second, if supported, EEs may also
  use "Support Messages" defined in section 4.3 of Lightweight CMP
  Profile [I-D.ietf-lamps-lightweight-cmp-profile] to get information
  about the CA status. These mechanisms will help constrained devices,
  that are acting as EEs, to conserve resources by eliminating the need
  to create an endpoint for receiving notifications from RA or CA.  It
  will also simplify the implementation of a CoAP-to-HTTP proxy.

Or at a minimum, just eliminate the paragraph break between the two paragraphs (i.e., merge them into one, even if no other rewrite).

I also wonder why the first alternative is given as a MAY but the second, as a "may".

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

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-ace-cmpv2-coap-transport-09
CC @jgscudder

Thanks for this document. I have one minor comment below, which I hope may be helpful.

## COMMENTS

### Section 2.6

In the second paragraph below,

  Alternatively, an EE MAY periodically poll for the current status of
  the CA via the "PKI Information Request" message, see section 6.5 of
  [RFC4210].  If supported, EEs may also use "Support Messages" defined
  in section 4.3 of Lightweight CMP Profile
  [I-D.ietf-lamps-lightweight-cmp-profile] to get information about the
  CA status.

  These mechanisms will help constrained devices, that are acting as
  EEs, to conserve resources by eliminating the need to create an
  endpoint for receiving notifications from RA or CA.  It will also
  simplify the implementation of a CoAP-to-HTTP proxy.

is it right that "these mechanisms" refers to the two mechanisms in the immediately-preceding paragraph? If so, this isn't clear from how you've structured the text. One possible rewrite is,

  Two alternatives are first, an EE MAY periodically poll for the
  current status of the CA via the "PKI Information Request" message,
  see section 6.5 of [RFC4210], or second, if supported, EEs may also
  use "Support Messages" defined in section 4.3 of Lightweight CMP
  Profile [I-D.ietf-lamps-lightweight-cmp-profile] to get information
  about the CA status. These mechanisms will help constrained devices,
  that are acting as EEs, to conserve resources by eliminating the need
  to create an endpoint for receiving notifications from RA or CA.  It
  will also simplify the implementation of a CoAP-to-HTTP proxy.

I also wonder why the first alternative is given as a MAY but the second, as a "may".

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

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Daniel Migault for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non blocking)

## Reviews outside of ACE ?

The shepherd's write-up and the mail archive do not mention any review by CORE WG of this document. I understand that CoAP is only a 'transport', but a quick review would have been beneficial.

## idnits issues

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ace-cmpv2-coap-transport-09.txt founds two important issues: wrong BCP14 template and unused reference.

## Section 2.6

The URI in this section uses "", is it the same as "" in section 2.1 ? If so, may I suggest to use the same term ?

## Section 4

Is "MAY" the right verb to be used in `If confidentiality is desired, CoAP over DTLS [RFC9147] MAY be used to provide confidentiality` ? I would have guessed a "SHOULD", or are there alternatives to CoAP over DTLS ?

[Ballot comment]
Thank you to Valery Smyslov for the SECDIR review.

** RFC6712 chose to formally “update” RFC4210.  Would such symmetry be appropriate in this document for RFC4210 and [I-D.ietf-lamps-cmp-updates]? 

** Idnits returned the following actionable feedback:
  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

  == Unused Reference: 'RFC5280' is defined on line 432, but no explicit
    reference was found in the text

** Section 1.
  This document specifies the use of CoAP over UDP as a transport
  medium for the CMP version 2 [RFC4210] , CMP version 3
  [I-D.ietf-lamps-cmp-updates] designated as CMP in this document and
  Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] .


-- Editorial.  There are extra spaces between the reference and punctuation.

-- What does it mean for “CMP version 3” to be “designated as CMP in this document”?  Are all statements which use “CMP” only referring to a particular version of CMP, specifically, [I-D.ietf-lamps-cmp-updates]?

** Section 4.
      Since the Proxy may have access to the CMP-Level metadata and
      control over the flow of CMP messages therefore proper role based
      access control should be in place.

What is “CMP-Level metadata”?

** Section 4. 
-- RFC6712 provides the following caution to motivate the use of TLS:
      CMP provides inbuilt integrity protection and authentication.
      The information communicated unencrypted in CMP messages does not
      contain sensitive information endangering the security of the PKI
      when intercepted.  However, it might be possible for an
      eavesdropper to utilize the available information to gather
      confidential technical or business critical information.

Should this text be added to the following text bullet:
      The CMP protocol does not provide confidentiality of the CMP
      payloads.  If confidentiality is desired, CoAP over DTLS [RFC9147]
      MAY be used to provide confidentiality for the CMP payloads,
      although it cannot conceal that the CMP protocol is used within
      the DTLS layer.

-- RFC6712 also provides the following caution about unprotected HTTP Announcement messages:

    4.  If no measures to authenticate and protect the HTTP responses to
      pushed Announcement messages are in place, their information
      regarding the Announcement's processing state may not be trusted.
      In that case, the overall design of the PKI system must not
      depend on the Announcements being reliably received and processed
      by their destination.

Section 3.7 seems to allow for these over CoAP.  Should similar guidance be provided?

[Ballot comment]
# GEN AD review of draft-ietf-ace-cmpv2-coap-transport-09

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ihMGS0Wl8sdlJlzkSZU-hlm7wRE).

## Comments

### Boilerplate

This document uses the RFC2119 keywords "SHOULD", "NOT RECOMMENDED",
"OPTIONAL", "SHOULD NOT", "SHALL", "MAY", "RECOMMENDED", "SHALL NOT", "MUST
NOT", "MUST", and "REQUIRED", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

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

### Section 4, paragraph 0
```
  4.  Security Considerations
```
Why is this a list of bullets instead of just regular text?

### Uncited references

Uncited references: `[RFC5280]`.

### Outdated references

Document references `draft-ietf-lamps-lightweight-cmp-profile-13`, but `-21` is
the latest available revision.

### Grammar/style

#### Section 2.3, paragraph 1
```
ional and potentially large fields. Thus a CMP message can be much larger tha
                                    ^^^^
```
A comma may be missing after the conjunctive/linking adverb "Thus".

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

[Ballot comment]
Hi,

Thanks for this document.

I have some minor comments/suggestions that may improve this document:

Minor level comments:

(1) p 2, sec 2.1.  CoAP URI Format

      coap://www.example.com/.well-known/cmp
      coap://www.example.com/.well-known/cmp/
      coap://www.example.com/.well-known/cmp/p/
      coap://www.example.com/.well-known/cmp/p//

Presumably the goal here is to keep the URLs reasonable short, is that worth stating at all?


(2) p 3, sec 2.3.  CoAP Request Format

                                        If the CoAP request is
  successful then the server MUST return a Success 2.xx response code
  otherwise server MUST return an appropriate Client Error 4.xx or
  Server Error 5.xx response code.

Noting that this is using RFC 2911 language, is this requirement specific to CMP over CoAP, or is this just restating CoAP behaviour.


(3) p 4, sec 2.4.  CoAP Block-Wise Transfer Mode

  A CMP PKIMesssage consists of a header, body, protection, and
  extraCerts structures which may contain many optional and potentially
  large fields.  Thus a CMP message can be much larger than the Maximum
  Transmission Unit (MTU) of the outgoing interface of the device.  The
  EEs and RAs or CAs, MUST use the Block-Wise transfer mode [RFC7959]
  to transfer such large messages instead of relying on IP
  fragmentation.
  If a CoAP-to-HTTP proxy is in the path between EEs and CA or EEs and
  RA then, if the server supports, it MUST use the chunked transfer
  encoding [RFC9112] to send data over the HTTP transport.  The proxy
  MUST try to reduce the number of packets sent by using an optimal
  chunk length for the HTTP transport.

It wasn't entirely obvious to me as to what entity "the server" is referring to in this paragraph.  Perhaps worth being more specific?


(4) p 4, sec 2.6.  Announcement PKIMessage

  If the server supports CMP Announcements messages, then it MUST send
  appropriate Success 2.xx response code, otherwise it MUST send an
  appropriate Client Error 4.xx or Server Error 5.xx response code.

I found this text very slightly confusing.  E.g., the first part of the sentence is about supporting announcement messages, and the second part is about response codes.  I presume that this is about replying to the register messages, but perhaps this could be made a bit clearer.


(5) p 4, sec 2.6.  Announcement PKIMessage

    A client on receiving a 2.xx success
  response without the Observe option [RFC7641] MAY try after some time
  to register again for announcements from the CMP server.  Since
  server can remove the EE from the list of observers for announcement
  messages, an EE SHOULD periodically re-register itself for
  announcement messages.

Would it be helpful to define or give guidance as what sort of period is recommended here (e.g., once per day, or once per year)?


(6) p 5, sec 3.  Proxy Support

  The CoAP-to-HTTP proxy can either be located closer to the EEs or
  closer to the RA or CA.  The proxy MAY support service discovery and
  resource discovery as described in section 2.2.  The CoAP-to-HTTP
  proxy MUST function as a reverse proxy, only permitting connections
  to a limited set of pre-configured servers.

Given the RFC 2119 MUST, is there a definition or reference as to what is meant by reverse proxy?


(7) p 5, sec 3.  Proxy Support

    It is out of scope of
  this document on how a reverse proxy can route CoAP client requests
  to one of the configured servers.  Some recommended mechanisms are as
  follows:

Perhaps: "It is out of scope of this document to specify how a reverse ..."


(8) p 5, sec 4.  Security Considerations

  *  If PKIProtection is used, the PKIHeader and PKIBody of the CMP
      protocol are cryptographically protected against malicious
      modifications.  As such, UDP can be used without compromising the
      security of the CMP protocol.  Security Considerations for CoAP
      are defined in [RFC7252].

Possibly a question for the SEC ADs, but would "without compromising the integrity of " be better than "without compromising the security" (given CMP does not provide confidentiality, as stated below)?



Nit level comments:

(9) p 4, sec 2.6.  Announcement PKIMessage

    If
  for some reason server cannot add the client to its list of observers
  for the announcements, it can omit the Observe option [RFC7641] in
  the response to the client.

Suggest: "reason server" => "reason, the server"


(10) p 5, sec 3.  Proxy Support

  This section provides guidance on using a CoAP-to-HTTP proxy between
  EEs and RAs or CAs in order to avoid changes to the existing PKI
  implementation.  Since the CMP payload is same over CoAP and HTTP
  transfer mechanisms, a CoAP-to-HTTP cross-protocol proxy can be
  implemented based on section 10 of [RFC7252].

Suggest: is same => is the same.  I also suggest starting a new paragraph from "Since the".


(11) p 6, sec 4.  Security Considerations

  *  Implementations SHOULD use the available datagram size and avoid
      small datagrams containing partial CMP PKIMessage data in order to
      reduce memory usage for packet buffering.

Perhaps "avoid small datagrams" => "avoid sending small datagrams"?


(12) p 6, sec 4.  Security Considerations

  *  A CoAP-to-HTTP proxy can also protect the PKI entities by handling
      UDP and CoAP messages.  Proxy can mitigate attacks like denial of
      service attacks, replay attacks and resource-exhaustion attacks by
      enforcing basic checks like validating that the ASN.1 syntax is
      compliant to CMP messages and validating the PKIMessage protection
      before sending them to PKI entities.

Suggest "Proxy can" => "The proxy can"

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

The IANA Functions Operator has completed its review of draft-ietf-ace-cmpv2-coap-transport-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a single, new registration will be made as follows from the identifier range 256-9999 reserved for IETF specifications:

Content type: application/pkixcmp
Content coding: Content may contain arbitrary octet values. The octet values are the ASN.1 DER encoding of a PKI message, as defined in the [RFC4210] specifications.
ID: [ TBD-at-Registration ]
Reference: [RFC4210][ RFC-to-be ]

Second, in the CMP Well-Known URI Path Segments registry on the Certificate Management Protocol (CMP) registry page located at:

https://www.iana.org/assignments/cmp/

a single, new registration will be made as follows:

Path Segment: ann
Description: The path to send a GET request with CoAP Observer Option to register for CMP announcement messages.
Reference: [ RFC-to-be ]

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. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the Well-Known URIs located at:

https://www.iana.org/assignments/well-known-uris/

the existing registration for:

URI Suffix: cmp

will have the current document, [ RFC-to-be ], added to its reference entry.

Fourth, in the CMP Well-Known URI Path Segments registry on the Certificate Management Protocol (CMP) registry page located at:

https://www.iana.org/assignments/cmp/

the existing registration for:

Path Segment: p

will have the current document, [ RFC-to-be ], added to its reference entry.

The IANA Functions Operator understands that these four actions are the only ones 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.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-04-14):

From: The IESG
To: IETF-Announce
CC: ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-cmpv2-coap-transport@ietf.org, mglt.ietf@gmail.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CoAP Transfer for the Certificate Management Protocol) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'CoAP
Transfer for the Certificate Management Protocol'
  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 2023-04-14. 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 specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  CMP defines the interaction between various PKI
  entities for the purpose of certificate creation and management.
  CoAP is an HTTP-like client-server protocol used by various
  constrained devices in the IoT space.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/



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

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

The IANA Functions Operator has completed its review of draft-ietf-ace-cmpv2-coap-transport-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the CoAP Content-Formats registry on the Constrained RESTful Environments (CoRE) Parameters registry page located at:

https://www.iana.org/assignments/core-parameters/

a new registration is to be made from the 256-9999 range as follows:

Media Type: application/pkixcmp
Encoding: arbitrary octet values
ID: [ TBD-at-Registration ]
Reference: [ RFC-to-be ][RFC4210]

Second, in the CMP Well-Known URI Path Segments registry on the Certificate Management Protocol (CMP) registry page located at:

https://www.iana.org/assignments/cmp/

a new registration will be made as follows:

Path Segment: ann
Description: The path to send a Get request with CoAP Observer Option to register for CMP announcement messages.
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. We are currently requesting that an expert be designated for this registry. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

The existing registration for

URI Suffix: cmp

will have the existing reference which points to the Internet-Draft changed to point to [ RFC-to-be ].

Fourth, in the CMP Well-Known URI Path Segments registry on the Certificate Management Protocol (CMP) registry page located at:

https://www.iana.org/assignments/cmp/

the existing registration for:

Path Segment: p

will have the existing reference which points to the Internet-Draft changed to point to [ RFC-to-be ].

The IANA Functions Operator understands that these four actions are the only ones 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.

For definitions of IANA review states, please see:

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

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-27):

From: The IESG
To: IETF-Announce
CC: ace-chairs@ietf.org, ace@ietf.org, draft-ietf-ace-cmpv2-coap-transport@ietf.org, mglt.ietf@gmail.com, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (CoAP Transfer for the Certificate Management Protocol) to Proposed Standard


The IESG has received a request from the Authentication and Authorization for
Constrained Environments WG (ace) to consider the following document: - 'CoAP
Transfer for the Certificate Management Protocol'
  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-10-27. 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 specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  CMP defines the interaction between various PKI
  entities for the purpose of certificate creation and management.
  CoAP is an HTTP-like client-server protocol used by various
  constrained devices in the IoT space.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

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

Standard Track is the expected status. This is appropriated as interoperability is required.

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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

This document specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP) for the purpose of certificate creation and management.
  CoAP is an HTTP like client-server protocol used by various
  constrained devices in the IoT space.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Currently there is an open source implementation to support CMP over CoAP maintained by @David von Oheimb. I believe these do not follow the draft exactly but are based on this draft. Here are github links:
https://github.com/siemens/LightweightCmpRa
https://github.com/siemens/embeddedCMP


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the document shepherd, Paul Wouters is the AD.

(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 has been through a very long WGLC over ace and lamps. We received some feed backs, but no controversies have been raised.

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

No.

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

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

It would be good to have more reviews, but that what we had.

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

Both co-authors have confirmed on the ace mailing list they are not aware of any IPR.

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

NA

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

none opposed the draft, we believe  a WG consensus has been reached.

(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

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

The nits reports BCP14 not being mentioned, but it is present in the draft.

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

It is likely that cmp-updates will procede to the registration of .well-known/cmp. In any cas eit would be good to progress these drafts together.

More explanation: The draft uses .well-known/cmp. .well-known/cmp is indicated as temporary [iana] and cmp-updates is still a draft. I am not sure we need to wait for cmp-updates to be published, but if the draft is abandoned we may need to indicate IANA that the cmp needs to be moved to permanent after 2022-05-20 - or may be at the publication of this draft.

[iana] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(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 only the cmp well known URI that we should make permanent if the draft is published before cmp-updates

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

no

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

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

The well known uri is already allocated. We may just need to move its temporary status to permanent.

The only allocation is the pkixcmp of the CoAP Content Format Registry code and follows the format of the current registry.


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

NA

(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, YANG modules, etc.

nits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

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

Standard Track is the expected status. This is appropriated as interoperability is required.

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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

This document specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  purpose of certificate creation and management.
  CoAP is an HTTP like client-server protocol used by various
  constrained devices in the IoT space.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Currently there is an open source implementation to support CMP over CoAP maintained by @David von Oheimb. I believe these do not follow the draft exactly but are based on this draft. Here are github links:
https://github.com/siemens/LightweightCmpRa
https://github.com/siemens/embeddedCMP


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel MIgault is the document shepherd, Ben Kaduk is the AD.

(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 has been through a very long WGLC over ace and lamps. We received some feed backs, but no controversies have been raised.

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

No.

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

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

It would be good to have more reviews, but that what we had.

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

Both co-authors have confirmed on the ace mailing list they are not aware of any IPR.

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

NA

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

none opposed the draft.

(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

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

The nits reports BCP14 not being mentioned, but it is present in the draft.

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

The draft uses .well-known/cmp. .well-known/cmp is indicated as temporary [iana] and cmp-updates is still a draft. I am not sure we need to wait for cmp-updates to be published, but if the draft is abandoned we may need to indicate IANA that the cmp needs to be moved to permanent after 2022-05-20 - or may be at the publication of this draft.

[iana] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(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 only the cmp well known URI that we should make permanent if the draft is published before cmp-updates

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

no

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

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

The well known uri is already allocated. We may just need to move its temporary status to permanent.

The only allocation is the pkixcmp of the CoAP Content Format Registry code and follows the format of the current registry.


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

NA

(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, YANG modules, etc.

nits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

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

Standard Track is the expected status. This is appropriated as interoperability is required.

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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

This document specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  purpose of certificate creation and management.
  CoAP is an HTTP like client-server protocol used by various
  constrained devices in the IoT space.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Currently there is an open source implementation to support CMP over CoAP maintained by @David von Oheimb. I believe these do not follow the draft exactly but are based on this draft. Here are github links:
https://github.com/siemens/LightweightCmpRa
https://github.com/siemens/embeddedCMP


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel MIgault is the document shepherd, Ben Kaduk is the AD.

(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 has been through a very long WGLC over ace and lamps. We received some feed backs, but no controversies have been raised.

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

No.

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

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

It would be good to have more reviews, but that what we had.

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

Both co-authors have confirmed on the ace mailing list they are not aware of any IPR.

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

NA

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

none opposed the draft.

(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

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

The nits reports BCP14 not being mentioned, but it is present in the draft.

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

The draft uses .well-known/cmp. .well-known/cmp is indicated as temporary [iana] and cmp-updates is still a draft. I am not sure we need to wait for cmp-updates to be published, but if the draft is abandoned we may need to indicate IANA that the cmp needs to be moved to permanent after 2022-05-20 - or may be at the publication of this draft.

[iana] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(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 only the cmp well known URI that we should make permanent if the draft is published before cmp-updates

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

no

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

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

The well known uri is already allocated. We may just need to move its temporary status to permanent.

The only allocation is the pkixcmp of the CoAP Content Format Registry code and follows the format of the current registry.


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

NA

(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, YANG modules, etc.

nits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

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

Standard Track is the expected status. This is appropriated as interoperability is required.

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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

This document specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  purpose of certificate creation and management.
  CoAP is an HTTP like client-server protocol used by various
  constrained devices in the IoT space.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Currently there is an open source implementation to support CMP over CoAP maintained by @David von Oheimb. I believe these do not follow the draft exactly but are based on this draft. Here are github links:
https://github.com/siemens/LightweightCmpRa
https://github.com/siemens/embeddedCMP


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel MIgault is the document shepherd, Ben Kaduk is the AD.

(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 has been through a very long WGLC over ace and lamps. We received some feed backs, but no controversies have been raised.

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

No.

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

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

It would be good to have more reviews, but that what we had.

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

Both co-authors have confirmed on the ace mailing list they are not aware of any IPR.

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

NA

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

none opposed the draft.

(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

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

The nits reports BCP14 not being mentioned, but it is present in the draft.

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

The draft uses .well-known/cmp. .well-known/cmp is indicated as temporary [iana] and cmp-updates is still a draft. I am not sure we need to wait for cmp-updates to be published, but if the draft is abandoned we may need to indicate IANA that the cmp needs to be moved to permanent after 2022-05-20 - or may be at the publication of this draft.

[iana] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(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 only the cmp well known URI that we should make permanent if the draft is published before cmp-updates

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

no

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

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

The well known uri is already allocated. We may just need to move its temporary status to permanent.

The only allocation is the pkixcmp of the CoAP Content Format Registry code and follows the format of the current registry.


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

NA

(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, YANG modules, etc.

nits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

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

Standard Track is the expected status. This is appropriated as interoperability is required.

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

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

This document specifies the use of Constrained Application Protocol
  (CoAP) as a transfer mechanism for the Certificate Management
  Protocol (CMP).  purpose of certificate creation and management.
  CoAP is an HTTP like client-server protocol used by various
  constrained devices in the IoT space.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

No

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

XXXX

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel MIgault is the document shepherd, Ben Kaduk is the AD.

(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 has been through a very long WGLC over ace and lamps. We received some feed backs, but no controversies have been raised.

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

No.

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

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

It would be good to have more reviews, but that what we had.

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

XXX

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

XXX

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

none opposed the draft.

(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

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

XXX

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

The draft uses .well-known/cmp. .well-known/cmp is indicated as temporary [iana] and cmp-updates is still a draft. I am not sure we need to wait for cmp-updates to be published, but if the draft is abandoned we may need to indicate IANA that the cmp needs to be moved to permanent after 2022-05-20 - or may be at the publication of this draft.

[iana] https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

(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 only the cmp well known URI that we should make permanent if the draft is published before cmp-updates

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

no

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

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

The well known uri is already allocated. We may just need to move its temporary status to permanent.

The only allocation is the pkixcmp of the CoAP Content Format Registry code.

XXX


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

NA

(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, YANG modules, etc.

nits.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?