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

[Bill Fenner <[e-mail]>]

On Mon, May 4, 2026 at 4:39 AM Eric Vyncke (evyncke) <[e-mail]>
wrote:

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

I tried this; it looks like the only "##" labels allowed are "discuss",
"comment" and "nit", so it ignores everything you wrote:

Warning: Unrecognised h2 section critical issues.

Warning: Unrecognised h2 section non-critical / cosmetic issues.

Warning: Did not find any issues.

Document: draft-ietf-intarea-rfc8335bis

Revision: 04
CC: @evyncke

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

I haven't had this discussion; I was hoping for guidance like this because
I didn't want to sound like I wanted to minimize the other authors'
contributions.

### 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?
>

Yes, it must be unicast.

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

 On AFI being neither 1 nor 2, sure, I can do that.

On the topic of the state, I suppose "unreachable" being missing was an
oversight. It makes sense to me.

I couldn't find any mention of state in RFC 826; I imagine that different
OSes might have different implementations of state in this case. Do you
have a good reference that I can point to to allow implementors to
understand what to report when?

RFC 4861 defines the states to be INCOMPLETE, REACHABLE, STALE, DELAY, and
PROBE. I guess "unreachable" includes INCOMPLETE, DELAY and PROBE?
Obviously REACHABLE is not unreachable, and STALE kind of says "not not
reachable... yet".?

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

Addresses and interface index values are considered together in this
paragraph.  I've replaced the address considerations with ... to make the
interface index considerations more clear. Does this address your issue?

... interface index values can also give away information

that might not want to be shared. For example, a malicious party can

use PROBE to ... if interface index values are

assigned densely, it can determine how many interfaces exist on the
probed node.

### 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 ?
>

Sure, I thought it was obvious, but I can add text.

## 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
>

Sure.


> ### Section 4
>
> What about the IPv6 flow label ?
>

I am not creative enough to come up with a use case for the flow label in
this protocol. It's most obvious to say MBZ. Is that reasonable to you?

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

I think I'll add another section with the diffs from RFC8335, and mark the
current change log as to be removed.

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

I don't think so, but I'm happy to accept guidance here. Most of RFC 8335
is still there, so it makes sense to me to keep the acknowledgements of the
people who made that happen.

### 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 ;-) ).
>

I was able to send PROBE across the public Internet when I was testing out
implementations a couple of years ago. I am not sure how to test with
middleboxes. Do you have any suggestions?

### 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` ;-)
>

I had a terrible time with aasvg in my node-id document, I spent 2 hours
trying to get aasvg working and had no luck, even after trying 0.4.3,
0.4.2, 0.4.1, 0.4.0 and 0.3.0.  Luckily, it worked for this document.

  Bill