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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
