Hi Authors of draft-ietf-anima-brski-prm, First of all, thank you for working on the document. I am trying out a slightly different process by having Last Call Expert Reviews done before or in tandem with my AD review. Please address the comments provided by the experts also. While I expect some kind of response to the COMMENTS I have provided, I will leave it up to you to decide if you want to address the NITS or not.
The draft effectively highlights scenarios (e.g., NAT/firewall traversal) where traditional BRSKI fails, justifying the need for a pledge responder mode. Aligning to existing BRSKI mechanisms with EST and voucher exchanges ensures compatibility. With these capabilities come potential issues that I would like to see highlighted in a separate section, called Operational Considerations. The introduction of the Registrar Agent introduces an additional component in the architecture. Operational complexity and potential misconfiguration in deploying and managing this entity could pose challenges. With the added interaction between the Pledge, Registrar Agent, and the Registrar might come additional latency. While the draft discusses backward compatibility, edge cases in heterogeneous deployment (e.g., mixed-mode BRSKI and BRSKI-PRM) need further elaboration. For example, the draft introduces new roles and behaviors, such as the Registrar Agent and Pledge Responder Mode, which extend the traditional BRSKI model. However, it does not explicitly discuss: How these new components coexist with legacy BRSKI components in mixed environments. Whether traditional BRSKI pledges and registrars can seamlessly interact with those using BRSKI-PRM. Please clarify whether and how existing Registrars can interoperate with Pledges using PRM without requiring significant updates. Terminology Section: Although a general terminology section has been defined, one that is dedicated to terms used in this draft would have been preferred. In either case, defining new terms (e.g., Registrar Agent) upfront would enhance readability. Figures and Diagrams: The architectural diagrams could be more detailed, especially to clarify the interaction between components (Pledge, Registrar Agent, Registrar). Security Consideration: The draft addresses security extensively, including: - Mutual authentication. - Voucher-based onboarding. - Protection against replay attacks. However, even though there is mention of it, further elaboration on potential risks introduced by the Registrar Agent, such as man-in-the-middle attacks or compromised agents would strengthen this section. Logging Considerations: It was refreshing to see that the authors had considered including events that should be logged, and the analysis done. Further improvements could be had by: Clearly outline the key events to log, such as: Communication attempts between the Pledge, Registrar Agent, and Registrar. Voucher requests and responses. Authentication successes or failures. Protocol negotiation and onboarding steps. Allow adjustable logging levels (e.g., debug, info, error) to cater to different operational needs. Include guidance on protecting log files, such as: Encryption of log storage. Controlled access to logs based on roles. Redaction or hashing of sensitive data (e.g., device identifiers, cryptographic keys). Address secure transmission of logs to centralized log servers, particularly in cloud or distributed environments. Include metadata in logs to identify whether a specific interaction pertains to traditional BRSKI or BRSKI-PRM (e.g., log tags like BRSKI vs. PRM). Improve logging around interactions involving the Registrar Agent. Recommend logging detailed error codes and diagnostic information for failures, such as: Registrar Agent is not reachable. Timeouts during voucher exchange. Authentication failures with the registrar or pledge. Emphasize logging timestamps with time synchronization (e.g., via NTP) to ensure accurate sequencing of events across components. Recommend log output in standard formats (e.g., JSON, syslog) for easy integration with log analysis tools and SIEM systems. Suggest logging key operational thresholds (e.g., high latency, failed onboarding attempts) to trigger alerts for proactive issue resolution. Privacy Considerations: While logging is essential, it may inadvertently capture sensitive or personal data, which the draft does not sufficiently address. - Specify privacy-preserving measures in logs, such as: - Avoid logging personally identifiable information (PII) unless necessary. - Anonymize or pseudonymize data where possible. No reference entries were found for these items, which were mentioned in the text: [draft-ietf-netconf-sztp-csr-06], and [draft-ietf-anima-brski-async-enroll-03]. Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term "he"; alternatives might be "they", "them", "their" * Term "traditional"; alternatives might be "classic", "classical", "common", "conventional", "customary", "fixed", "habitual", "historic", "long-established", "popular", "prescribed", "regular", "rooted", "time-honored", "universal", "widely used", "widespread" NITS: The term "pledge" is sometimes capitalized as "Pledge" and other times in lowercase. Please choose one (I prefer uppercase) and apply it uniformly when referring the entity called Pledge. Document references draft-ietf-netconf-sztp-csr, but that has been published as RFC9646. Document references draft-ietf-anima-jws-voucher-10, but -14 is the latest available revision. Document references draft-irtf-t2trg-taxonomy-manufacturer-anchors-03, but -04 is the latest available revision. Document references draft-ietf-anima-brski-ae-12, but -13 is the latest available revision. Document references draft-ietf-anima-brski-discovery-04, but -05 is the latest available revision. Section 1, paragraph 11 > entity, as defined in [RFC9483]. Typically a device or service that owns a pu > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Typically". Section 3.2, paragraph 1 > ng on behalf of the registrar. In addition the registrar must be able to veri > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition”. Section 5.2, paragraph 2 > ut the operational complexity of standalone Registrar-Agents by integrating > ^^^^^^^^^^ Do not mix variants of the same word ("standalone" and "stand-alone") within a single text. Section 6.1, paragraph 6 > ry to apply DNS-SD with mDNS. For Ethernet it is provided by simply connectin > ^^^^^^^^ A comma is probably missing here. Section 7.2, paragraph 4 > R trigger. The registrar MAY consider to ignore any but the newest PER artifa > ^^^^^^^^^^^^^^^^^^ The verb "consider" is used with the gerund form. Section 7.2, paragraph 7 > re-enrollment can be supported in a similar way. In this case, the pledge MAY > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.2.2.2, paragraph 9 > gistrar converts the PVR artifact to an Registrar Voucher-Request (RVR) arti > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 7.3, paragraph 4 > . Depending on policy, the MASA MAY chose the type of assertion to perform. F > ^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.3.1, paragraph 7 > , the domain registrar MUST add an additional JWS Protected Header and JWS Si > ^^^^^^^^^^^^^^^^^^^^^ This phrase might be redundant. Consider either removing or replacing the adjective "additional". Section 7.3.3, paragraph 1 > re 24 depicts exchanges for the PER request handling and the following subse > ^^^^^^^^^^^ In this context, "PER-request" forms an adjective and is spelled with a hyphen. Section 7.3.4.1, paragraph 5 > MUST verify that * the PER was signed signed with the private key correspondi > ^^^^^^^^^^^^^ Possible typo: you repeated a word. Section 7.3.4.1, paragraph 11 > result in a pledge EE certificate singed by the domain owner (e.g., LDevID > ^^^^^^ Are you sure you meant to write "singed" (a synonym for "burnt"), or did you mean "signed"? Section 7.3.5, paragraph 3 > e-enrollment may be supported in a similar way with the exception that the c > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.4, paragraph 16 > ion 6.1.2. The Registrar-Agent MAY stored information from the first connecti > ^^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.5, paragraph 3 > Voucher Status. If the pledge did not did not provide voucher status telemet > ^^^^^^^^^^^^^^^ This phrase is duplicated. You should probably use "did not" only once. Section 7.11.2, paragraph 2 > r-Agents, pledges are more subject to DoS attacks from Registrar-Agents in B > ^^^^^^ It appears that a hyphen is missing in the plural noun "to-DoS". Section 7.11.2, paragraph 4 > on may be that the pledge does not limited the number of voucher-requests it > ^^^^^^^ The auxiliary verb "do" requires the base form of the verb. Section 7.11.2.1, paragraph 10 > ystem in an authenticated way. In addition it is required that the Registrar- > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". Section 7.11.2.1, paragraph 13 > ignature on "agent-signed-data". Furthermore the registrar also verifies the > ^^^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Furthermore”. Section 7.2, paragraph 4 > R trigger. The registrar MAY consider to ignore any but the newest PER artifa > ^^^^^^^^^^^^^^^^^^ The verb "consider" is used with the gerund form. Section 7.2, paragraph 7 > re-enrollment can be supported in a similar way. In this case, the pledge MAY > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.2.2.2, paragraph 9 > gistrar converts the PVR artifact to an Registrar Voucher-Request (RVR) arti > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Section 7.3, paragraph 4 > . Depending on policy, the MASA MAY chose the type of assertion to perform. F > ^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.3.1, paragraph 7 > , the domain registrar MUST add an additional JWS Protected Header and JWS Si > ^^^^^^^^^^^^^^^^^^^^^ This phrase might be redundant. Consider either removing or replacing the adjective "additional". Section 7.3.3, paragraph 1 > re 24 depicts exchanges for the PER request handling and the following subse > ^^^^^^^^^^^ In this context, "PER-request" forms an adjective and is spelled with a hyphen. Section 7.3.4.1, paragraph 5 > MUST verify that * the PER was signed signed with the private key correspondi > ^^^^^^^^^^^^^ Possible typo: you repeated a word. Section 7.3.4.1, paragraph 11 > result in a pledge EE certificate singed by the domain owner (e.g., LDevID > ^^^^^^ Are you sure you meant to write "singed" (a synonym for "burnt"), or did you mean "signed"? Section 7.3.5, paragraph 3 > e-enrollment may be supported in a similar way with the exception that the c > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 7.4, paragraph 16 > ion 6.1.2. The Registrar-Agent MAY stored information from the first connecti > ^^^^^^ The modal verb "MAY" requires the verb's base form. Section 7.5, paragraph 3 > Voucher Status. If the pledge did not did not provide voucher status telemet > ^^^^^^^^^^^^^^^ This phrase is duplicated. You should probably use "did not" only once. Section 7.11.2, paragraph 2 > r-Agents, pledges are more subject to DoS attacks from Registrar-Agents in B > ^^^^^^ It appears that a hyphen is missing in the plural noun "to-DoS". Section 7.11.2, paragraph 4 > on may be that the pledge does not limited the number of voucher-requests it > ^^^^^^^ The auxiliary verb "do" requires the base form of the verb. Section 7.11.2.1, paragraph 10 > ystem in an authenticated way. In addition it is required that the Registrar- > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". Section 7.11.2.1, paragraph 13 > ignature on "agent-signed-data". Furthermore the registrar also verifies the > ^^^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Furthermore”. "Appendix B.", paragraph 7 > o create a Pledge-Voucher-Request and an Pledge Enroll-Request. From IETF dra > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". "Appendix B.", paragraph 8 > request to IETF-voucher-request-prm to to allow better listing of voucher rel > ^^^^^ Possible typo: you repeated a word. - The acronym "PRM" is used in the title and throughout the document without an initial definition. Please define it upon first occurrence. - References to sections within the document sometimes use "Section" with a capital "S" and other times with a lowercase "s." Please use it consistently. - In Section 5.2, the phrase "nomadic connectivity" is misspelled as "nomdic connectivity." - Terms like "bootstrapping phase" and "boot-strapping phase" are used interchangeably. Pick one, probably the latter, and apply it consistently. - Some references to other documents are not uniformly formatted, with variations in the use of brackets and italics. Ensure all references follow the same formatting style per the IETF guidelines. - Phrases like "BRSKI-PRM introduces new endpoints for the Domain Registrar and pledge, and a new component, the Registrar-Agent" are repeated in both the abstract and introduction. Consider rephrasing to avoid redundancy. - In Section 3.1, lists such as "Building Automation, Infrastructure Isolation Policy, Less Operational Security in the Target-Domain" are presented without commas separating the items. - Some section headings use title case (e.g., "Supported Environments and Use Case Examples"), while others use sentence case (e.g., "Limitations"). Adopt a consistent captilization style, preferably title case. - Figures and tables are presented without numbering, making them difficult to reference. Number all figures and tables sequentially and provide descriptive captions for each. Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
