Hi Charlie, I'm resending the message as I realized it did not go to the ANIMA WG list.
Thank you for the review of BRSKI-PRM. I addressed the points you identified. All of them were easy to address. By rereading the review comments, I thought about your statement "The protocol is more elaborate that I would have thought necessary, but I could find no problems with it.". Is there anything we could improve in the approach itself or the description, which caught your eye? We restructured the document a while ago to make it better readable and aligned it with experiences gained from the implementation. If there is anything we can improve in the specification, which you feel would help better understanding, please let us know. Also, if you think that optimizations in the protocol itself could be done to reduce complexity, would also be interesting. Based on the current state of the document (before WGLC), changes could still be done. Best regards Steffen > -----Original Message----- > From: Charlie Kaufman <[email protected]> > Sent: Montag, 5. Dezember 2022 08:22 > To: [email protected]; [email protected]; [email protected] > Subject: Secdir review of draft-ietf-anima-brski-prm-05 > > Reviewer: Charlie Kaufman > Review result: Has nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > This Standards Track ID extends a family of protocols for limited function > devices to obtain certificates from their surrounding environment with the > assistance of an on-line manufacturer's authority that can authenticate > information as coming from their device. It extends the BRSKI (RFC8995) > protocol to deal with devices that prefer to accept incoming initialization > requests rather than initiating outbound requests. It does this be defining a > new > node called a "registrar-agent" that acts as a client to both the > to-be-registered > "pledge" and the domain registrar. > > The protocol is more elaborate that I would have thought necessary, but I > could > find no problems with it. > > Typos: > p1 "To establishment the" -> "To establish the" > p4 "In this scenarios it is" -> "In this scenario it is" > p5 "defined i this" -> "defined in this" > p8 "as describe in" -> "as described in" > p8 "it SHOULD initiate to that Registrar" --- initiate what? a request? a > connection? > p9 "This operational parameters" -> "These operational parameters" > p9 "presume the" -> "presumes the" > p11 "constraint environments" -> "constrained environments" > p12 "endpoints were the" -> "endpoints where the" > p12 "endpoints were additional" -> "endpoints where additional" > p45 "a manufactures pledge" -> "a manufacturer's pledge" > p64 "on misusage" -> "of misuse" > p64 "an registrar-agent" -> "a registrar-agent" > p64 "rouge" -> "rogue" > > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
