Mohamed Boucadair has entered the following ballot position for draft-ietf-anima-brski-prm-19: 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-anima-brski-prm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Steffen, Thomas, Eliot, and Michael, Thank you for the productive discussion and for addressing almost all my points raised in [1]. The companion discussion [2] triggered by [1] is also instructive. (1) As indicated in the thread, I trust Mahesh will do the right thing with the following (used-to-be DISCUSS point): # Cluster with 8366bis CURRENT: The JSON PVR Data MUST contain the following fields of the “ietf- voucher-request” YANG module as defined in [I-D.ietf-anima-rfc8366bis]; I think this spec should be clustered with 8366bis. There are several structures that used in this document and which depend on what is defined in 8366bis. Changes to the bis will have implications on this one. (2) Here are some few comments found when checking 18/19 diff: * nit OLD: building automation use case mentioned in (Section 3.1.1) NEW: building automation use case mentioned in Section 3.1.1 * Smells like a normative reference. Please change as follows: OLD: if it does not support a more general discovery as defined in [I-D.ietf-anima-brski-discovery] NEW: OLD: if it does not support a more general discovery such as defined in [I-D.ietf-anima-brski-discovery] * nit OLD: limiting for a requests to avoid susceptibility of the pledge NEW: limiting for requests to avoid susceptibility of the pledge * nit (many occurrences) OLD: Algorithms supported for JWS signatures MUST support NEW: Algorithms used for JWS signatures MUST support * Extra references, really? CURRENT: Requirements to the utilized credentials authenticating and artifact signatures on the registrar as outlined in Section 6.3 may have operational implications when the registrar is part of a scalable framework as described in Section 1.3.1 of [I-D.richardson-anima-registrar-considerations]. Besides the above, also consider the existing documents on operational modes for * BRSKI registrars in [I-D.richardson-anima-registrar-considerations] * BRSKI MASA in [I-D.richardson-anima-masa-considerations] I-D.richardson-anima-registrar-considerations cited in "Besides the above," was cited in the sentence right above ;-) Please update. * Commentary not intended initially to make it into the text: CURRENT: Documents that define exclusively modules following the extension in [RFC8971] are not required to include the security template in Section 3.7.1. Likewise, following the template is not required for modules that define YANG extensions such as [RFC7952]. I provided this text to motivate what you can safely remove the old paragraph. But, if you want to include it, then some tweaking is needed (Section 3.7.1 ref is broken in the context of this draft + we don't use 7952 here), I suggest: CURRENT: Documents that define exclusively modules following the extension in [RFC8971] are not required to include the YANG security template per the guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis]. Many thanks again for editing such a well-written document. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/anima/qHRppN_6T3KBdsjOksxu8bw4byI/ [2] https://mailarchive.ietf.org/arch/msg/anima/8HLrJ_PLjIbf11gZjMTuXkC2Z9g/ _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
