Hello Juliusz, Thanks for your quick response.
Indeed, the intended status is very important in the publication process. First, please note that it is perfectly acceptable for a Proposed Standard to have a normative reference to an informational / experimental document, it is called a "down ref" and is quite common. It needs to be explicitly listed in the IETF Last Call and the IESG has to approve the downref (this is really routine) if not already in https://datatracker.ietf.org/doc/downref As written in my AD review, I am unsure that the section about intermediate routers sending ICMP errors belongs to this I-D, a simple reference to RFC 7404 would suffice. If this section is kept, then the title & abstract should be updated accordingly as the I-D would be broader than simply next hop routing. Regards -éric From: Juliusz Chroboczek <[email protected]> Date: Thursday, 4 December 2025 at 13:13 To: Eric Vyncke (evyncke) <[email protected]> Cc: [email protected] <[email protected]>, Warren Kumari <[email protected]>, [email protected] <[email protected]>, Luigi Iannone <[email protected]> Subject: Re: AD review of draft-ietf-intarea-v4-via-v6-05 Hello Éric, and thanks for your review. We'll address the rest of your review promptly, for now please let me answer your point about the intended status. > ### Intended publication status > > It seems to me that it is rather an informational document than a proposed > standard as this I-D does not specify anything but merely describe how > existing > implementations can be used. The very reason this draft exists is that we need a document describing v4-via-v6 that can be normatively cited in Standards Track documents. The lack of such a document is the reason why we had to downgrade RFC 9229 to Experimental, even though the protocol extension described therein has been deployed in production for years. This leaves us with either Standards Track or BCP. The reason we have chosen Standards Track is this sentence in Section 4: If a router does not have any IPv4 addresses assigned, the router MUST use the dummy address 192.0.0.8 as the source address of outgoing ICMP packets This behaviour has been discussed in the Babel working group, and the WG came to the following conclusions: 1. the source address of the ICMP packets cannot depend on the routing protocol: when a router needs to send a destination unreachable error, then it has no way to determine whether it's an OSPF or an IS-IS route that's missing; 2. it is best to agree early on a single dummy address that is used across implementations, since it simplifies both operations and the implementation of ICMP tools. Hence, we have chosen to normatively mandate a single dummy address. For this reason, we request publication of this document as Standards Track. I hope you find this argument convincing. If you do not, then please suggest a way to proceed that will not prevent this document from being normatively cited in Standards Track RFCs. Thanks, -- Juliusz
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
