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 comment.

The summary of the review is on the right track. 
I have added some points and questions below for your consideration. 


For Section 9 (Security Considerations).
1. After initially stating that “It introduces no new security concerns”, it then introduces multiple concerns. An option could be to move all security concerns content to 5.8, and then reference section 5.8 from section 9: “This RFC introduces no new security concerns, however refer to Section 5.8.” This would be a similar approach to that used in RFC2223. 

Having said that, the content being moved from Section 9 to 5.8 will need more work and discussion on the list. 


For Section 5.8 (Security Management) 
1.There is a short paragraph: 
“An analysis of existing counters might help operators recognize the conditions identified in the Security Considerations for the new protocol before they can impact the network.”
   
Does this advice fit in a document for protocol designers? Could this be updated to be actionable for protocol designers? 


For Section 5.5   
1.Configuration Management discusses: 
“Implementations should not arbitrarily modify configuration data”.  
This paragraph seems to be generally applicable, however the following steps define ACL as a specific use case;  

“There are two parts to this:  
1. A Network Management System (NMS) could optimize ACLs for performance reasons.  
2. Unless the device or NMS is configured with adequate rules and guided by administrators with extensive experience, reordering ACLs can introduce significant security risks.”  

If this has wider applicability, can the two points be generalised?  


General feedback 
1. Some of the examples given throughout the document could be replaced or strengthened to highlight the key consideration in question. For example, section 4.1 says: 
“For parameters that can vary (e.g., speed-dependent), instead of using a constant, set the default value as a function of the variable to reduce the risk of problems caused by technology advancement.
For example, where protocols involve cryptographic keys, Protocol Designers should consider not only key generation and validation mechanisms but also the format in which private keys are stored, transmitted, and restored. Designers should specify any expected consistency checks (e.g., recomputing an expanded key from the seed) that help verify correctness and integrity. Additionally, guidance should be given on data retention, restoration limits, and cryptographic module interoperability when importing/exporting private key material. Refer to [I-D.ietf-lamps-dilithium-certificates] for an example of how such considerations are incorporated.”  


2. Across the document, there is frequent use of rhetorical questions to convey considerations. Examples from 5.8 include: 
“Should a system automatically notify operators of every event occurrence, or should an operator-defined threshold control when a notification is sent to an operator?” 
“Should certain statistics be collected about the operation of the New Protocol that might be useful for detecting attacks, such as the receipt of malformed messages, messages out of order, or messages with invalid timestamps? If such statistics are collected, is it important to count them separately for each sender to help identify the source of attacks?”
These are important considerations and questions to answer however it seems short of an exhaustive list or direction of things to consider. If these are considerations that should be taken into account when outlining operational considerations could these be phrased as such? If they are placeholders for incomplete sections that will later be built out, adding markers to indicate this could bring clarity.