Hi Deb, Thanks for the comments.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Deb Cooley via Datatracker <[email protected]> > Envoyé : mardi 3 juin 2025 16:47 > À : The IESG <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Deb Cooley's No Objection on draft-ietf-netmod-rfc8407bis- > 25: (with COMMENT) > > > Deb Cooley has entered the following ballot position for > draft-ietf-netmod-rfc8407bis-25: 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.) > > ------------------------------------------------------------------- > COMMENT: > ------------------------------------------------------------------- > > I am balloting 'no objection', but I am serious about these > comments. It > should always be a goal for an RFC (at whatever level) to be clear, > concise, > and understandable. My comments below all reflect that goal: > > Thank you to Yoav Nir for their secdir review. > > Section 1.1: This is long and incomprehensible unless one is > intimately > familiar with the original RFC. Recommend moving it to either a > later section > or to an Appendix. [Med] Already clarified the reasoning as part of Ketan's thread. > > Section 3.7, general: The word 'especially' is not defined. What > does > 'especially disruptive' vs merely 'disruptive' mean? What about > 'especially > sensitive information' vs merely 'sensitive information'? Either > remove these > descriptors or define what they mean. > [Med] That same wording is inherited from RFC6087 and then RFC8407. Every data node can be sensitive if accessed by illegitimate party, however the disruption impact may be more or less severe. The intent here is to restrict the analysis to those that are critical. > Section 3.7.1, para 3: Why not 'MUST use' vs 'have to use' for > both the > requirement for secure transport and mutual authentication? [Med] What value using a normative langue would bring for this specific case (which is about actual use)? As you know, RFC8174 has the following: Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative. > > Section 3.7.1: This comment applies to every place in this section > that uses > the word 'particularly'. What makes data 'particularly sensitive'? > Is it > defined somewhere? [Med] This provided in the text: * "Typically, particularly sensitive readable -- data nodes are ones that are protected by a -- "nacm:default-deny-read" or a "nacm:default-deny-all" extensions -- statement. " * " -- e.g., ones that are protected by a "nacm:default-deny-write" -- or a "nacm:default-deny-all" extensions statement, " * " -- or get-config) are particularly sensitive or vulnerable (e.g., -- if they might reveal customer information or violate personal -- privacy laws)." Again, the descriptor (particularly) doesn't > actually help > to define what makes data more or less sensitive, or contain more > or less > vulnerabilities. Is it merely up to the editors of the draft to > decide? [Med] The examples in the text help identify what falls under that category. We can't provide a definitive list, but authors/reviews can help tag those. This can't be automagically extracted, if you will. What > if I, as the editor, decide that the lifetime symmetric key > variable, written > into a Yang data module isn't 'particularly sensitive', would that > be ok? As > it is my choice as the editor? [I will note that RFC8341 puts the > word > 'particular' in front of nearly every noun in the draft, also with > no > explanation of what makes any of those users, requests, protocols, > etc special, > or hmmm particular.] > > Section 6, last sentence: Are there new or increased security > risks that don't > need to be discussed? Please remove the phrase 'that need to be > discussed' as > it just raises more questions about what isn't being said. > [Med] OK to remove from my side. Hope Mahesh is OK as he suggested it in his AD review. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
