Hi Steffen, See inline with [mj].
> On Jan 3, 2025, at 9:12 PM, Fries, Steffen <steffen.fr...@siemens.com> wrote: > > Hi Mahesh, > > Thank you very much for the review and your comments. I will provide the > response inline in this email to keep the context. > We will provide an updated version to datatracker containing the comment > resolution as indicated below and we finalized the discussion on the comment > resolution. Intermediate versions will be available on the ANIMA git. > > > From: Mahesh Jethanandani <mjethanand...@gmail.com > <mailto:mjethanand...@gmail.com>> > Sent: Wednesday, December 25, 2024 9:14 AM > To: draft-ietf-anima-brski-...@ietf.org > <mailto:draft-ietf-anima-brski-...@ietf.org> > Cc: anima@ietf.org <mailto:anima@ietf.org> > Subject: AD review of draft-ietf-anima-brski-prm-15 > > 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. > [stf] Just upfront: We will provide answers below and also extend the > document regarding the proposed enhancements. We’ll also incorporate the > NITS, as they improve readability. > > 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. > > [stf] It is a good idea to provide a separate section regarding operational > considerations with the points you mentioned above. Some of the points have > already been addressed in section 5 (architecture) like the last bullet > point for deployment options (stand-alone vs. integrated Registrar-Agent), > which can also be referred to. In addition, also section 6 (refers to > certain operational considerations in the description of the components. In > addition, for BRSKI there is already a separate document targeting > operational considerations, which is more elaborate: > https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > > <https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/> > and > https://datatracker.ietf.org/doc/draft-richardson-anima-masa-considerations/ > <https://datatracker.ietf.org/doc/draft-richardson-anima-masa-considerations/>. > We will include a reference to these drafts as well. [mj] Unfortunately, both the drafts have expired, and I do not know what the plan is for their revival. Even if they are, they are I-D at this time, and the time it will take to progress them to an RFC status could stall this work. Have you considered incorporating some of the relevant text here? > > 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. > [stf] We will include a terminology definition of the Registrar-Agent. > > Figures and Diagrams: > > The architectural diagrams could be more detailed, especially to clarify the > interaction between components (Pledge, Registrar Agent, Registrar). > [stf] I guess you are referring to Figure 2 and Figure 3 here as Figure 1 > already contains the clarification. We will add the protocol information in > the respective figures. Section 5 containing the figures also has the verbal > description of the interaction. It may also be good to add a forward > reference to section 7, which contains a detailed description of the > exchanges between the involved components. > > 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. > [stf] We will review and enhance the section accordingly to explain boundary > conditions. Specifically as the Registrar-Agent is a new and likely a > stand-alone component the handling of compromised Registrar-Agents should be > included. > > > 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. > [stf] The intention of including logging was exactly to support failure > detection and handling. The points you listed above can be used to enhance > that section and provide more details and pointers to deployed technology. We > will elaborate more on these. [mj] Thanks for adding most of these above points. BTW, the four bullet items in the first paragraph that have been added are malformed. Can they be fixed? Cheers. > > 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. > [stf] Good points. We will add this to the Privacy Considerations. > > 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]. > [stf] Both drafts only appear in the change history in Appendix C, which will > be deleted before final publication. So I don’t think it needs to be solved > separately. > > Found terminology that should be reviewed for inclusivity; see > https://www.rfc-editor.org/part2/#inclusive_language > <https://www.rfc-editor.org/part2/#inclusive_language> for background and more > guidance: > > * Term "he"; alternatives might be "they", "them", "their" > [stf] In general agree, but I could not find an occurrence of “he” in the > document. Could you provide a pointer to the section? > > * 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" > [stf] Replaced “traditional” in the YANG module section with “common” > > 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. > [stf] I double checked the document, we use “Pledge” in the context of > explanations of abbreviations or terms like BRSKI-PRM, PVR, and PER to have > an easier connection between the abbreviation and the related term. With this > approach we aligned to BRSKI and thought it might be good to keep the same > use of capitalization. > > Document references draft-ietf-netconf-sztp-csr, but that has been published > as > RFC9646. > [stf] thanks, updated accordingly > > Document references draft-ietf-anima-jws-voucher-10, but -14 is the latest > available revision. > [stf] This will be automatically updated in the new version > > Document references draft-irtf-t2trg-taxonomy-manufacturer-anchors-03, but -04 > is the latest available revision. > [stf] This will be automatically updated in the new version > > Document references draft-ietf-anima-brski-ae-12, but -13 is the latest > available revision. > [stf] This will be automatically updated in the new version > > Document references draft-ietf-anima-brski-discovery-04, but -05 is the latest > available revision. > [stf] This will be automatically updated in the new version > > 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". > [stf] included > > 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”. > [stf] included > > 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. > [stf] changed to stand-alone to match other occurances > > 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. > [stf] included > > 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. > [stf] change to “ignoring” > > 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. > [stf] done as suggested > > 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". > [stf] change to “a” > > 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. > [stf] changed to “choose” > > 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". > [stf] removed “additional” as suggested > > 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. > [stf] done as suggested > > 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. > [stf] deleted repeated 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"? > [stf] “signed” was meant, > > 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. > [stf] done as suggested > > 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. > [stf] changed to “store” > > 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. > [stf] delete double occurrence > > 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". > [stf] changed to “DoS-attacks” > > 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. > [stf] corrected > > 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". > [stf] added comma > > 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”. > [stf] added comma > > > [stf] The next set of comments seems to be doubled from the above(Section > 7.2, paragraph 4 - Section 7.11.2.1, paragraph 13). Will proceed with the > comments to the Appendix > > > 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”. > > > [stf] Proceeded with comment incorporation here > > "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". > [stf] Was in Appendix C. Corrected but belongs to history of changes, which > will be deleted > > "Appendix B.", paragraph 8 > > request to IETF-voucher-request-prm to to allow better listing of voucher > > rel > > ^^^^^ > Possible typo: you repeated a word. > [stf] Was in Appendix C. Corrected but belongs to history of changes, which > will be deleted > > - The acronym "PRM" is used in the title and throughout the document > without an initial definition. Please define it upon first > occurrence. > [stf] Done already in the Abstract and the Introduction of the draft. > > - References to sections within the document sometimes use "Section" > with a capital "S" and other times with a lowercase "s." Please use > it consistently. > [stf] double checked the main part of the document. No changes in Appendix C > for history of changes > > - In Section 5.2, the phrase "nomadic connectivity" is misspelled as > "nomdic connectivity." > [stf] was already corrected > > - Terms like "bootstrapping phase" and "boot-strapping phase" are used > interchangeably. Pick one, probably the latter, and apply it > consistently. > [stf] aligned to “bootstrapping phase” > > - 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. > [stf] double checked formatting style > > - 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. > [stf] could not find the indicated repetition > > - 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. > [stf] Not sure I understand the request. What is meant by lists? > > - 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. > [stf] changed to 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. > [stf] double checked the TXT and HTML version in datatracker contain numbers > for figures and tables. They were included automatically, based on the MD > template we used to create the draft > > Best regards > Steffen > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com> > > > > > > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
