Roman Danyliw has entered the following ballot position for draft-ietf-anima-brski-prm-20: 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: ---------------------------------------------------------------------- (updated ballot for -20) Thank you to Paul Kyzivat for the GENART review. Thank you for addressing my DISCUSS feedback. (Comments on -18) ** Section 4. * The use of authenticated self-contained objects addresses both, the TLS challenges and the technology stack challenge. What are “technology stack challenges”? ** Section 6.1 Alternatively, the registrar EE certificate MAY be provided via configuration or a repository What is a “repository” and how is that difference than “configuration”? ** Section 6.1 Further, the Registrar-Agent SHOULD have synchronized time. What is the impact of not having synchronized time? ** Section 6.1.2 Note that this goes against the naming recommendation of [RFC6763]. The _brski-pledge._tcp service, however, targets machine-to-machine discovery. What in RFC6763 suggests a scope that would exclude “machine-to-machine discovery” to provide justification for not following its recommendation? ** Section 6.1.2 For Ethernet, it is provided by simply connecting the network cable. Isn’t this an oversimplification? What if it there is local policy which manages the behavior of the interface? What about provisioning that might need to occur on a switch? ** Section 6.1.2 How to gain network connectivity is out of scope of this document. If this is the case, why is there discussion of WiFi, Ethernet, references to [I-D.richardson-emu-eap-onboarding], and 6LoWPAN. ** Section 6.3 Overall, this 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]. If these operational implications are important, why are they an informative reference in an unadopted I-D? ** Section 6.3.1 This may be supported by a specific naming in the SAN (subject alternative name) component of the Registrar-Agent EE certificate, which allows the domain registrar to explicitly detect already in the TLS session establishment that the connecting client is a Registrar- Agent. What is the standardized approach for this naming scheme to enable interoperability? Is this out of scope? ** Section 7.1.1.1.1 The serial-number member SHALL contain the product-serial-number of the pledge with which the Registrar-Agent assumes to communicate as string. Is this the same serial number as emitted in in mDNS in Section 6.1.2? ** Section 7.1.1.1.2. are there any MTI “alg”s to support to ensure interoperability? ** Section 7.3 The registrar SHOULD verify the TLS client authentication of the Registrar-Agent, in particular if the TLS session is used to obtain the Registrar-Agent EE certificate (see Section 6.3). Why wouldn’t the client authentication be verified? When is this acceptable to do? ** Section 9 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] What does it mean to “consider” these documents? Are they relevant operational considerations? _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
