[Ace] John Scudder's No Objection on draft-ietf-ace-cmpv2-coap-transport-09: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-ace-cmpv2-coap-transport-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/



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