Lightweight Certificate Management Protocol (CMP) Profile
draft-ietf-lamps-lightweight-cmp-profile-21

I have reviewed the document for the Well-Known URI Path Segments for this document: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile/. I think there is an issue in section 6.1 that looks like a copy/paste type of error:

Snippet from table 1 in section 6.1 (page 79):

+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get CA Certificates | getcertreqtemplate | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+

The "Get CA Certificates" PKI Management Operation is listed twice. The second time it refers to the same section 4.3.1. The path Segment says "getcertreqtemplate". I compared it to the CoAP Transfer from table 2 in section 6.2, and section 6.2 seems correct and it contains a PKI Management Operation of "Get Certificate Request Template" which is what I think was meant in section 6.1.

From Table 2 section 6.2 (page 82) - Notice no duplicate and reference to 4.3.3
+---------------------------------------+---------+---------+
| Get CA Certificates | crts | Section |
| | | 4.3.1 |
+---------------------------------------+---------+---------+
| Get Root CA Certificate Update | rcu | Section |
| | | 4.3.2 |
+---------------------------------------+---------+---------+
| Get Certificate Request Template | att | Section |
| | | 4.3.3 |
+---------------------------------------+---------+---------+
| CRL Update Retrieval | crls | Section |
| | | 4.3.4 |
+---------------------------------------+---------+---------+


So I think section 6.1 needs to be updated as follows:

+----------------------------+--------------------+---------+
| Get CA Certificates | getcacerts | Section |
| | | 4.3.1 |
+----------------------------+--------------------+---------+
| Get Root CA Certificate | getrootupdate | Section |
| Update | | 4.3.2 |
+----------------------------+--------------------+---------+
| Get Certificate Request Template | getcertreqtemplate | Section |
| | | 4.3.3 |
+----------------------------+--------------------+---------+
| CRL Update Retrieval | getcrls | Section |
| | | 4.3.4 |
+----------------------------+--------------------+---------+

The rest of it looks correct to me.

[Ballot comment]
Section 1.7 uses a SHOULD NOT before that expression is defined in Section 1.9.

The bulk of the SHOULDs in this document would benefit from review and possible tuning.  SHOULD presents a choice for the implementer; it would be helpful to include with that choice some guidance about when one might legitimately deviate from what's stated.  If SHOULD is being used as "you really oughta do this, but you don't really have to and things will interoperate just fine", it doesn't deserve SHOULD; if what you mean is "yes you have to do this from now on, but we're retaining backward compatibility here" then it should say that explicitly.  In other cases, I wonder if you don't really mean MUST.

For instance, in 3.1, you have this:

    -- SHOULD contain a name representing the originator of the
    --  message; otherwise, the NULL-DN (a zero-length
    --  SEQUENCE OF RelativeDistinguishedNames) MUST be used

Looks great; I have no wiggle room.  Then you have this:

    -- SHOULD be the subject of the CMP protection certificate, i.e.,
    --  the certificate corresponding to the private key used to
    --  sign the message

Well, what if I don't do that?  Does anything break?  Can I just put whatever in there and everything still works?  If nothing breaks, why isn't this "MAY" or something that doesn't use a BCP 14 keyword?  If something breaks, why isn't this a MUST?

In 3.4:

"Each EE SHOULD know its own identity to fill the sender field."

What happens if I don't?  And what interoperability aspect fails if I don't know my own identity?  Should this be better expressed as "Each EE SHOULD fill the sender field with its own identity?"  Why isn't that a MUST?

The two SHOULDs at the bottom of 3.5 seem suspect too.  Since you're giving me a choice, I'm within specifications to consider the input valid if all of those tests fail.  Is that what's intended?

I'm not going to get into any of them past the bottom of Section 3, but hopefully you can see what I'm getting at.  I would typically DISCUSS this pattern, but since I'm so late to the party, I'll leave it to Roman to decide how much this observation weighs on the strength of the document.

Next steps after the telechat: Thanks for -16 and -17 to address all IESG review feedback to date.  Unfortunately, not enough of the IESG has balloted on this document.  At least more more AD position is required.  A few have volunteered to add a ballot early next week.

[Ballot comment]
Thanks for this document. It is clear even though it is a tad long :-)
Some minor comments:

  Though CMP is a capable protocol it is so far not used very widely.
  The most important reason appears to be that the protocol offers a
  too large set of features and options.

I would say [citation needed] here...

In section 6:
        HTTP SHOULD be used and CoAP MAY be used
 
        File-based transfer MAY be used in case offline transfer is required.

I find these different levels of usage odd. Clearly devices have no real choice here. If they can support HTTP, there is no need for CoAP.
If they cannot do HTTP and therefor can only do CoAP, there is no choice either. If they are offline, clearly they cannot use anything but
file based transfer. I would set all of these to MAY ?

In section 6.1:

        the recommendations provided in [I-D.ietf-uta-rfc7525bis] SHOULD be considered.

"considered" is already a watered down version of "followed". So either use MUST be considered or "SHOULD be followed" and not "SHOULD be considered"

[Ballot comment]
Hi,

Thanks for this document.  I just have a couple of comments:

(1) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments

  In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other
  environments using NETCONF/YANG modules, SZTP-CSR
  [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes
  different types of certificate requests to obtain a public-key
  certificate for a locally generated key pair.  One option is using a
  CMP p10cr message.  Such a message is of the form ietf-ztp-types:cmp-
  csr from module ietf-ztp-csr and offers both proof-of-possession and
  proof-of-identity.  To allow PKI management entities to also comply
  with this profile, the p10cr message MUST be formatted by the EE as
  described in Section 4.1.4 of this profile, and it MAY be forwarded
  as specified in Section 5.2.

Given the MUST statement above, should this document "update" ietf-netconf-sztp-csr?


(2) p 7, sec 1.5.  Use of CMP in SZTP and BRSKI Environments

  In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]
  environments, BRSKI-AE: Alternative Enrollment Protocols in BRSKI
  [I-D.ietf-anima-brski-ae] describes a generalization regarding the
  employed enrollment protocols to allow alternatives to EST [RFC7030].
  For the use of CMP, it requires adherence to this profile.

Similar to my comment above, should the "requires adherence" be "MUST adhere", and should this document "update" (BRSKI) [RFC8995]?

Thanks,
Rob

[Ballot comment]
Thank you for the work on this document, which although long I found quite easy to read.

Many thanks to Robert Sparks for his ART ART review: https://mailarchive.ietf.org/arch/msg/spasm/msD0CJEIXAeQnqDNawoqS28WPKY/ and to the authors for addressing his comments. I agree with him and haven't found any ART issues. I understand and share his concern about whether the document unintentionally allows behavior that the framework it is profiling would not, but I trust the working group and the responsible AD to have that covered.

Francesca

[Ballot comment]
Due to time pressure, I am relying completely on the Internet directorate review done by Sheng Jiang: https://datatracker.ietf.org/doc/review-ietf-lamps-lightweight-cmp-profile-15-intdir-telechat-jiang-2022-11-22/

Thank you Sheng for this review.

[Ballot comment]
Firstly, thank you very much to the authors for writing this -- I especially liked Section 1.1 :-)

I have a number of editorial suggestions to (hopefully) further improve the document


1: Sec 1
"Therefore, this document aims at tailoring the available options and specifying at an adequate detail how" - "at an adequate detail how" seems to be missing "level"?
Actually, I think rewriting it as: "Therefore, this document aims to tailor the available options and specify how to use them in adequate detail to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible." is more readable.

2: Sec 1.3
"are not deployed on-site but in a high protected data center environment" - s/high/highly/

3: Sec 1.6
"This results in violating the general rule that a certificate request transaction must include a certConf message (since moreover, using implicitConfirm is not allowed there, neither)."
You seem to have a bunch of double-negatives here -- I think the last word should be "either" or the "not" should be dropped.

4: Sec 1.7
"To minimize ambiguity and complexity through needless variety, this document specifies exhaustive requirements on generating PKI management messages on the sender side." - "on generating" or "for generating"

5: Sec 1.8
"Section 5 profiles responding to requests, exchange between PKI management entities, ..." -- exchanges

6: Sec 1.9
"The figure above shows an architecture example with at least one LRA" -- architectural... actually, I don't know, but the current seems wrong.

7: Sec 3.6.1
"An EE SHALL NOT send error messages. PKI management entities SHALL NOT send error messages in upstream direction, either." -- the upstream.

[Ballot comment]
# Internet AD comments for draft-ietf-lamps-lightweight-cmp-profile-15
CC @ekline

Thanks to Niklas Widell for the IoT-DIR review.

## Nits

### S3.1

* s/signthe/sign the/

### S4.1

* "allows for providing proof-of-possession any method that a key can used for"

  ->

  "allows for providing proof-of-possession using any method that a key can be used for"

  perhaps?

### S4.1.1

* "further requests MUST be sent using separate PKI management operation"

  ->

  "further requests MUST be sent using separate PKI management operations"?

### S4.2

* "requests the revocation of an own certificate" ->
  "requests the revocation of an owned certificate"?

### S4.3.4

* "to identify a CRL for which is available" ->
  "to identify a CRL for which information is available"?

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

The IANA Functions Operator has completed its review of draft-ietf-lamps-lightweight-cmp-profile-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

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/

twenty new registrations will be made as follows:

+====================+===============================+===============+
| Path Segment | Description | Reference |
+====================+===============================+===============+
| initialization | Enrolling an End Entity to a | [ RFC-to-be ] |
| | New PKI over HTTP | |
+--------------------+-------------------------------+---------------+
| certification | Enrolling an End Entity to a | [ RFC-to-be ] |
| | Known PKI over HTTP | |
+--------------------+-------------------------------+---------------+
| keyupdate | Updating a Valid Certificate | [ RFC-to-be ] |
| | over HTTP | |
+--------------------+-------------------------------+---------------+
| pkcs10 | Enrolling an End Entity Using | [ RFC-to-be ] |
| | a PKCS#10 Request over HTTP | |
+--------------------+-------------------------------+---------------+
| revocation | Revoking a Certificate over | [ RFC-to-be ] |
| | HTTP | |
+--------------------+-------------------------------+---------------+
| getcacerts | Get CA Certificates over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| getrootupdate | Get Root CA Certificate | [ RFC-to-be ] |
| | Update over HTTP | |
+--------------------+-------------------------------+---------------+
| getcertreqtemplate | Get CA Certificates over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| getcrls | CRL Update Retrieval over | [ RFC-to-be ] |
| | HTTP | |
+--------------------+-------------------------------+---------------+
| nested | Batching Messages over HTTP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| ir | Enrolling an End Entity to a | [ RFC-to-be ] |
| | New PKI over CoAP | |
+--------------------+-------------------------------+---------------+
| cr | Enrolling an End Entity to a | [ RFC-to-be ] |
| | Known PKI over CoAP | |
+--------------------+-------------------------------+---------------+
| kur | Updating a Valid Certificate | [ RFC-to-be ] |
| | over CoAP | |
+--------------------+-------------------------------+---------------+
| p10 | Enrolling an End Entity Using | [ RFC-to-be ] |
| | a PKCS#10 Request over CoAP | |
+--------------------+-------------------------------+---------------+
| rr | Revoking a Certificate over | [ RFC-to-be ] |
| | CoAP | |
+--------------------+-------------------------------+---------------+
| crts | Get CA Certificates over CoAP | [ RFC-to-be ] |
+--------------------+-------------------------------+---------------+
| rcu | Get Root CA Certificate | [ RFC-to-be ] |
| | Update over CoAP | |
+--------------------+-------------------------------+---------------+
| att | Get Certificate Request | [ RFC-to-be ] |
| | Template over CoAP | |
+--------------------+-------------------------------+---------------+
| crls | CRL Update Retrieval over | [ RFC-to-be ] |
| | CoAP | |
+--------------------+-------------------------------+---------------+
| nest | Batching Messages over CoAP | [ 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."

The IANA Functions Operator understands that this is the only action 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-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-lightweight-cmp-profile@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:  (Lightweight Certificate Management Protocol (CMP) Profile) 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: - 'Lightweight
Certificate Management Protocol (CMP) Profile'
  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-24. 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 aims at simple, interoperable, and automated PKI
  management operations covering typical use cases of industrial and
  IoT scenarios.  This is achieved by profiling the Certificate
  Management Protocol (CMP), the related Certificate Request Message
  Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
  but sufficiently detailed and self-contained way.  To make secure
  certificate management for simple scenarios and constrained devices
  as lightweight as possible, only the most crucial types of operations
  and options are specified as mandatory.  More specialized or complex
  use cases are supported with optional features.




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



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

Shepherd Write-up for draft-ietf-lamps-lightweight-cmp-profile-10


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


(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 aims at simple, interoperable, and automated PKI
    management operations covering typical use cases of industrial and
    IoT scenarios.  This is achieved by profiling the Certificate
    Management Protocol (CMP), the related Certificate Request Message
    Format (CRMF), and HTTP-based or CoAP-based transfer.  The profile
    is expected to provide certificate management for simple scenarios
    and constrained devices, only the most crucial types of operations
    and options are mandatory to implement.  While special and complex
    use cases are supported as well, these use cases employ recommended
    or optional features.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    Vendors with CMP implementations have indicated that they intend to
    support the lightweight CMP profile.
   
  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 shepherd did a thorough review of the document during
  WG Last Call.  All issues were resolved.


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

  The PKIX WG developed RFC 4210 (CMP) and RFC 4211 (CRMF).  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.

  One place: s/MUST not/MUST NOT/

  There is 1 instance of lines with non-ascii characters in the document.


(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,
  which has already been sent to the IESG for publication. 

  There are four related Internet-Drafts that are coming to the IESG
  at roughly the same time.  Please publish all four at the same
  time with consecutive RFC numbers.  The documents are:
 
    1.  draft-ietf-lamps-cmp-updates
  2.  draft-ietf-lamps-cmp-algorithms
    3.  draft-ietf-lamps-lightweight-cmp-profile
    4.  draft-ietf-ace-cmpv2-coap-transport


(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 2986,
  but it is already in the downref registry, so no special action is
  needed.


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

  None.


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

Shepherd Write-up for draft-ietf-lamps-lightweight-cmp-profile-10


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


(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 aims at simple, interoperable, and automated PKI
    management operations covering typical use cases of industrial and
    IoT scenarios.  This is achieved by profiling the Certificate
    Management Protocol (CMP), the related Certificate Request Message
    Format (CRMF), and HTTP-based or CoAP-based transfer.  The profile
    is expected to provide certificate management for simple scenarios
    and constrained devices, only the most crucial types of operations
    and options are mandatory to implement.  While special and complex
    use cases are supported as well, these use cases employ recommended
    or optional features.

  Working Group Summary:

    There is consensus for this document in the LAMPS WG.

  Document Quality:

    Vendors with CMP implementations have indicated that they intend to
    support the lightweight CMP profile.
   
  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 shepherd did a thorough review of the document during
  WG Last Call.  All issues were resolved.


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

  The PKIX WG developed RFC 4210 (CMP) and RFC 4211 (CRMF).  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.

  One place: s/MUST not/MUST NOT/

  There is 1 instance of lines with non-ascii characters in the document.


(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,
  which has already been sent to the IESG for publication. 

  There are four related Internet-Drafts that are coming to the IESG
  at roughly the same time.  Please publish all four at the same
  time with consecutive RFC numbers.  The documents are:
 
    1.  draft-ietf-lamps-cmp-updates
  2.  draft-ietf-lamps-cmp-algorithms
    3.  draft-ietf-lamps-lightweight-cmp-profile
    4.  draft-ietf-ace-cmpv2-coap-transport


(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 2986,
  but it is already in the downref registry, so no special action is
  needed.


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

  None.


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