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

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

Hello Bill

Thanks for your message and your message about the parking tool. I won't use "##" then in my AD reviews 😉

Else, see in-line for EV>

I.e., I am expecting a revised I-D with the agreed changes (and up to you and your co-authors for the other points). Then, let's go through the IETF Last Call

Regards,

-éric

From: Bill Fenner <[e-mail]>
Date: Wednesday, 6 May 2026 at 19:36
To: Eric Vyncke (evyncke) <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Jen Linkova <[e-mail]>; [e-mail] <[e-mail]>; Mohamed Boucadair <[e-mail]>; Tal Mizrahi <[e-mail]>
Subject: Re: AD review of draft-ietf-intarea-rfc8335bis-04

On Mon, May 4, 2026 at 4:39 AM Eric Vyncke (evyncke) <[e-mail]<mailto:[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.

EV> not a surprising statement from a gentleman
EV> OTOH, did you contact the previous authors (see also the return for experience point) about their views ? They MUST
EV> be kept as contributors of course

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

EV> so, please state this clearly (even if semi-obvious)

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

EV> thanks

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?

EV> good point, I will trust your creativity to find the right wording.

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

EV> only INCOMPLETE is 'unreachable', STALE/DELAY/PROBE happen quite often for not to chatty nodes

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

EV> good text, unsure whether "densely" is a requirement for the issue though.


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

EV> Text won't hurt (even if, as you wrote, this is implicit/obvious)


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

EV> What about "This document does not specify any value for the Flow Label field" ? I.e., leave it to the node OS ?

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

EV> This will be useful


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

EV> I will leave it to you, you may also replace with "The authors want to thank all the people acknowledged in RFC 8335" (or something less heavy)

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

EV> This is annoying to say the least if a -bis has no return of experience by the author(s).
EV> Was it ever used in production? Else, what is the point of having a -bis ?

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

EV> EXCELLENT news ! Thanks for your perseverance 😊