[Int-area] AD review of draft-ietf-intarea-rfc8335bis-04

["Eric Vyncke (evyncke)" <[e-mail]>]

# Éric Vyncke, INT AD, AD review for draft-ietf-intarea-rfc8335bis-04
CC @evyncke

Thank you for the work put into this document. Please find below my AD review, thanks for your patience while waiting for it.

As the responsible AD, I expect all the points below to be addressed, either by a revised I-D, or an email reply. Of course, authors and WG can reject my points, but this needs to be justified. Once all the points are addressed, I will proceed with the publication process, i.e., IETF Last Call.

Special thanks to Tal Mizrahi for the shepherd's detailed write-up including the WG consensus, the justification of the intended status (but see my point below about the 6 authors).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this AD reviews follows the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## Critical issues

### Confirmation of the SIX authors

As there are 6 authors, i.e., larger than the usual limit of 5, I wonder whether the editor (who apparently did most of the work in the -bis draft) and the other authors have considered moving the RFC 8335 authors (who did not provide text to this -bis) to the Contributors section.

### Sections 2 and 2.1

When the probed interface is identified by address, please be clear that this is a unicast address or can it also be multicast, any cast, or broadcast?

### Section 4.1

Suggest to extend the description of `No Such Table Entry` case when the Interface Identification Object is not an IPv[46] address, e.g., a data-link layer address as indicated by the AFI being neither 1 nor 2.

It is also unclear whether the state of the NDP/ARP cache entry is important, I guess that an cache entry in the 'unreachable' state should return 'not ok', but I was unable to find where it is specified in the text.

### Interface enumeration

Should there be a security consideration point about enumerating the interfaces as the if-index values can probably and quickly be enumerated ?

### Dual-stack behaviour      

As I hope that sending an ICMPv4 Echo Extended Request to a router, asking about an interface that has only an IPv6 address is allowed, should there be text about this nice feature ?

## Non-critical / cosmetic issues

Note: these points must also be addressed.

### Abstract

s/This document describes a network diagnostic /This document *specifies* a network diagnostic / ? as it is a proposed standard

### Section 4

What about the IPv6 flow label ?

### Section 7

It is unclear whether the change history needs to be kept (there is no RFC Editor note), I would prefer to keep the diff with RFC 8335 while deleting the history of the drafts.

### Acknowledgments

Should the acknowlegments for RFC 8335 be removed or explicitely marked "for RFC 8335" ?

### Return of deployment experience with RFC 8335

A small section about the experience gained with RFC 8335 (dated 2018) would be useful, possibly in the appendix. E.g., whether the PROBE packets were able to be sent over the public Internet and/or through middleboxes (for some definitions of middleboxes ;-) ).

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try especially as this I-D uses the Kramdown file format by starting the block with `~~~ aasvg` ;-)