Hi, Yaroslav,

Thanks a lot for the review. Thought I believe it is the documents that define 
the data nodes/subtree themselves should take care of their sensitivity, it 
does no harm to reiterate these concerns in this document.
The authors have added a new subsection inside section 9 (Security 
Considerations) to incorporate your comments below. Please review the diff at : 
https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-17.txt,
 and let us know if you have further comments. 

Thanks a lot!

Best Regards,
Qiufang // co-author

-----Original Message-----
From: Yaroslav Rosomakho via Datatracker [mailto:[email protected]] 
Sent: Sunday, January 4, 2026 8:39 PM
To: [email protected]
Cc: [email protected]; [email protected]; 
[email protected]
Subject: draft-ietf-netmod-system-config-16 ietf last call Secdir review

Document: draft-ietf-netmod-system-config
Title: System-defined Configuration
Reviewer: Yaroslav Rosomakho
Review result: Has Issues

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.

The document is straightforward and easy to read, but the security 
considerations section would benefit from some improvements. 1. While the 
document does not introduce new protocol mechanisms, it normatively specifies 
in sections 6.2-6.4 how existing mechanisms can be used to modify system 
configuration. The Security Considerations section does not explicitly discuss 
the implications of granting write access. 2. Even though the defined <system> 
is read-only it may contain extremely sensitive information. The current NACM 
reference seems to be too shallow for the sensitivity involved. It would be 
great to explicitly mention authorization granularity and audit best practices.
3. The security implications of potential merge conflicts or precedence rules 
between <system> configuration and <running> or <operational> configuration are 
not discussed. Misconfiguration in these interactions could lead to unintended 
system behavior including security policy bypass and availability risks. This 
should be acknowledged in the Security Considerations section. 4. The document 
currently references RFC 8446. Given ongoing updates, this reference should be 
updated to draft-ietf-tls-rfc8446bis (RFC-to-be 9846).


_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to