An Authorization Information Format (AIF) for ACE
draft-ietf-ace-aif-07
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
* I support Rob's discuss/find.
Francesca Palombini No Objection
Thank you for the work on this document Many thanks to Marco Tiloca for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/P7tlVXlIMMJJ8cc9hBA1jMOqVZY/, to Alexey Melnikov for his media-type review: https://mailarchive.ietf.org/arch/msg/media-types/rxzyZhpOLwH1UuueYwlMSENSOak/, and to Carsten for addressing them. Francesca
John Scudder No Objection
Lars Eggert No Objection
The IANA review of this document seems to not have concluded yet. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "traditionally"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread". Thanks to David Schinazi for their General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/_BxkOEZJVOgcLQdyMj3dV0NYRB0). ------------------------------------------------------------------------------- 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 2.2. , paragraph 3, nit: - conditionalized access based on state outside the identification of - ---- Section 1. , paragraph 3, nit: > structure that can be used for many different applications and as a specific > ^^^^^^^^^^^^^^ Consider using "many". Section 1.1. , paragraph 4, nit: > ically secured (or transmitted in a secure way). This section discusses the i > ^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "securely" to avoid wordiness. Section 2. , paragraph 3, nit: > identified (e.g., as part of the armor around it). The generic model of such > ^^^^^^^^^^^^^^^^^^^ Consider using "the surrounding armor".
Murray Kucherawy No Objection
I support Robert's DISCUSS. The shepherd writeup seems to have been done in something of a hurry, and I'd like to see that cleaned up if possible before publication. Specifically: The first question doesn't contain a complete answer. The Document Quality section is not answered at all. "No" is a curious answer to #13; it's saying references are not split into "Normative" and "Informative"? The answer to #14 is similarly curious. The answer to #18 is confusing; it appears to be a registry snapshot, not a confirmation that any new registries are properly defined. Lastly, #20 was not answered. The Abstract seems to suggest very broad application. Should there be a sentence in there that indicates the context of the work (specifically, ACE)? In Section 5.1, "Required Parameters" shouldn't be "none", but rather "N/A"; see Section 5.6 of RFC 6838 for more information. The second paragraph of Section 6 (about default-deny) strikes me as something that should really be up in Section 2 or Section 3; it's something fundamental and ought to be called out up front.
Robert Wilton (was Discuss) No Objection
Thanks for addressing my discuss and comments. Regards, Rob
Roman Danyliw No Objection
** Section 5.2. The registration policy is Specification required [RFC8126]. The designated expert will engage with the submitter to ascertain the requirements of this document are addressed. To help the DE, is there a way to be clearer on what requirements need to be satisfied? Is it the bulleted list in the SecCons? Section 4? ** Section 6. I was under the impression that AIF didn’t have an explicit requirement to use CoAP. For example, draft-ietf-ace-mqtt-tls-profile appears to use the information model but isn’t restricted to CoAP. Therefore, is it more accurate to say: OLD The security considerations of [RFC7252] apply NEW When AIF is used with CoAP, the security considerations of [RFC7252] apply.
Zaheduzzaman Sarker No Objection
Éric Vyncke No Objection
Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Loganaden Velvindron for the shepherd's write-up even if there is no justification for the intended status and little is written about WG consensus beyond "no objections". I hope that this helps to improve the document, Regards, -éric # COMMENTS I like when "internet of things" is used without its "IoT" acronym ;) ## Abstract In "This specification provides a generic information model and format" should this rather be "This specification provides a generic information and a data models" ? ## Section 2 Suggestion: to avoid the reader to stop wondering at figure 1, please introduce "Toid" and "Tperm" before the figure 1. ## Section 2.3 I took me several reading and parsing of this section to understand the need and the specification of "dynamic-GET". May I suggest a rewrite about: the issue that this section wants to address, be specific that this doc define "dynamic methods" (not defined anywhere else) ? See also Rob's comment. ## Section 3 In the first paragraph, should the plural form be used for 'information model' ? As two of them are defined before.
(Benjamin Kaduk; former steering group member) Yes
(Martin Vigoureux; former steering group member) No Objection