Gunter Van de Velde has entered the following ballot position for draft-ietf-anima-brski-prm-18: 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: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-prm-18 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-anima-brski-prm-18.txt # for your convenience, please find some non-blocking COMMENTS # My review is rather generic and high level, it is not my area of expertise. If my comments refer to items obvious when familiar with the technology, then feel free to ignore. # comments # ======== 14 Abstract GV> Would this abstract be a viable alternative? " This document defines the BRSKI-PRM (Pledge in Responder Mode) variant of the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. BRSKI-PRM supports the secure enrollment of devices, referred to as pledges, into a domain where direct communication with the registrar is not possible. Instead, the pledges interact with a proxy entity that relays authenticated and authorized enrollment requests to the registrar. This approach accommodates deployment scenarios where network constraints, operational considerations, or topological factors prevent direct pledge-to-registrar communication. The protocol extensions defined in this document maintain the security and trust properties of BRSKI while enabling broader applicability in constrained or segmented environments. " 183 Security information about the customer domain, specifically the 184 customer domain certificate, are exchanged and authenticated 185 utilizing signed data objects, the voucher artifacts as defined in 186 [RFC8995]. GV> original text reads odd. Revised textblob: " Security information pertaining to the customer domain, specifically, the customer domain certificate, is exchanged and authenticated through the use of signed data objects, namely the voucher artifacts, as defined in [RFC8995]. " 3789 10.2. Service Name and Transport Protocol Port Number Registry 3790 3791 IANA has registered the following service names: 3792 3793 *Service Name:* brski-pledge 3794 *Transport Protocol(s):* tcp 3795 *Assignee:* IESG i...@ietf.org (mailto:i...@ietf.org) 3796 *Contact:* IETF Chair ch...@ietf.org (mailto:ch...@ietf.org) 3797 *Description:* The Bootstrapping Remote Secure Key Infrastructure 3798 Pledge 3799 *Reference:* [THISRFC] GV> Does this need to be the iesg and the chair to be as assignee and contact? At first glance this looks unusual. This seems to have happened in v18 of the draft. Gunter Van de Velde RTG Area Director _______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
