Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

- Document: draft-ietf-intarea-rfc8335bis-02. 
- Reviewer: Susan Hares 
- Review Date: 1/31/2026 
- Intended Status: Proposed standard 

## Sumarry 
- status: - Has Issues
- Overall Summary: This document provides a good specification for PROBE, a valuable addition to the Operator arsenal of tools.
   
It has two issues as a document (not a technology): it lacks a management/operations considerations section and 
a security considerations section. 

The management/operations section should provide tips for managing pings/probes within a network to prevent overloading routers or hosts. The Security section should talk about the critical information found in interface names, identifiers or addresses. 
This advice is not in RFC4884 (which this updates). 

NITS:
1. Section 1.3 needs to untangle the English in this sentence to multiple sentences. 

Old text:/
   This document defines a unique use of ICMP Extensions [RFC4884]:
   while normally, ICMP Extensions are defined to start at a given point
   and continue to the end of the packet, if the extension object is an
   Interface Identification Object as defined in this memo, then the
   extension structure (including the checksum) consists only of that
   single ICMP Extension Object. /

It can be written as 2 sentence to clarify. 

2. Technical NIT - RFC8335 behavior being extended. 

Sometimes, it is just necessary to code around the bad behavior of initial implementations. 
However, the authors should realize that the IESG really, really hates 
a document that codes around the bad behavior of an RFC that is being deprecated. 

Just thought you should think about this carefully.  The bad behavior also 
allows some data to be passed after the Interface Identification Object 
without having any checksum or integrity. Seems like a questionable  
concept.  I was looking for the security section to explain to me why 
you thought this was reasonable. 

3. Editorial NIT section 2.0, paragraph starting with Section 7. last sentence 

old text/  The behavior when it contains a different Extension
    Object is not defined by this memo but may be defined in the future./
 

New text:/ The behavior when it contains a different Extension
    Object is not defined by this memo./

We are the IETF, new standards can always update old standards. 
The last clause for this sentence is not needed. 

4. Compliance with operational guidelines (optional but recommended): 

- Fault Management: Are failure detection/recovery mechanisms specified? 
Error handling for packet fields is covered in ICMP Message Processing 
Code Field processing. It would be good to know what happens, if experience 
(which is evident by the bis), has denoted any other failure conditions. 

- Configuration Management: Are configuration changes to enable/disable the feature clearly defined? 
The configuration is hinted at in main document and Appendix A (with application).
=It would be useful to know if a YANG model is planned/exists.  

- Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly identified? 
I did not find hte performance metics for correct operations of the code.


| Review Item      | RFC 5706 Considerations                                                                               
|----------------- |-------------------------------------------------------------------------------------------------
| deployment       | As a BIS, this document must have hints for deployment and managed in a network.  That wisdom | 
|                  | is missing (probably should go to manageability/operations section)                           |
--------------------------------------------------------------------------------------------------------------------
| Migration path   | The RFC8335 path plan is to allow "stuff" after ICMP Extension Structure. When "stuff" is     |
|                  | allowed after valid fields without an integrity checksum, bad things can be passed            |
--------------------------------------------------------------------------------------------------------------------
| transition from  | It would be good to know if early deployments have found any problems when transition from    |  
| RFC8335 to bis   | RFC8335 to this solution.  Does this solution help ward off DOS attacks? Is there a place     |
|                  | during the transition that might cause operational issues.                                    |
--------------------------------------------------------------------------------------------------------------------
| Impact on network| What happens when this protocol gets used to attack a node?  Is there more traffic on node    |
| Operation control|  when this happens: 
|  plane           |                                                                                               |
--------------------------------------------------------------------------------------------------------------------    
| Verifying Correct| Has a test plan been written for performance for this new feature?  if so, can it be shared? |
| Operation        | Do utilies show up ETE probe timings like Ping timing? What load on routers or hosts?        | 
--------------------------------------------------------------------------------------------------------------------