Awesome, thank you very much. W
On Wed, Nov 26, 2025 at 7:38 AM, Luigi Iannone <[email protected]> wrote: > Thanks > > WriteUp submitted as well. > > L. > > On 25 Nov 2025, at 16:40, Warren Kumari <[email protected]> wrote: > > > > > > On Tue, Nov 25, 2025 at 7:27 AM, Luigi Iannone <[email protected]> wrote: > > Hi Warren, > all good to me. > Once you submit the new revision I’ll submit the shepherd writeup. > > > Done. > > Here is the output from IDNITS along with explanations: https:// > author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/ > draft-ietf-intarea-v4-via-v6-05.xml > > https://trustee.ietf.org/license-info): > ---------------------------------------------------------------------------- > > No issues found here. > > Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: > ---------------------------------------------------------------------------- > > == There are 4 instances of lines with non-ascii characters in the document. > > > Yes. These are in proper names: T. Høiland-Jørgensen and Éric Vyncke > > Checking nits according to https://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses > in the document. If these are example addresses, they should be changed. > > == There are 6 instances of lines with private range IPv4 addresses in the > document. If these are generic example addresses, they should be changed > to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, > 198.51.100.x or 203.0.113.x. > > == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses > in the document. If these are example addresses, they should be changed. > > > Yup, these are all in the "Implementation Status ( This section to be > removed before publication. )", except for 192.0.0.8 (which clearly should > remain): > "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 > ([RFC7600], Section 4.8, Requirement R-22)." > > Miscellaneous warnings: > ---------------------------------------------------------------------------- > > -- Found something which looks like a code comment -- if you have code > sections in the document, please surround them with '<CODE BEGINS>' and > '<CODE ENDS>' lines. > > > Yup, this is: > "draft-ietf-intarea-v4-via-v6-04.txt(443): Possible code comment in > line: # DST-ADDRESS GATEWAY > DISTANCE. " > This is in the "Implementation Status ( This section to be removed before > publication. )" section. > > Checking references for intended status: Proposed Standard > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative references > to lower-maturity documents in RFCs) > > ** Downref: Normative reference to an Experimental RFC: RFC 7600 > > Yup. That is correct — RFC7600 - "IPv4 Residual Deployment via IPv6 - A > Stateless Solution (4rd)" <https://datatracker.ietf.org/doc/rfc7600/> > > W > > > Ciao > > L. > > On 24 Nov 2025, at 21:39, Warren Kumari <[email protected]> wrote: > > > > > > On Fri, Nov 21, 2025 at 10:11 AM, Luigi Iannone <[email protected]> wrote: > > P.S. > You may consider as well to take care of the idnits: https://author-tools. > ietf.org/api/idnits?url=https://www.ietf.org/archive/id/ > draft-ietf-intarea-v4-via-v6-04.txt > > > > Thank you — I have addressed most of these in the editor copy. > > The ones which I did not are related to: > > == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses > in the document. If these are example addresses, they should be changed. > > I did not address these, as they are only in the "# Implementation Status > ( This section to be removed before publication. )" section. > > > > L. > > On 21 Nov 2025, at 14:43, Luigi Iannone <[email protected]> wrote: > > Hi Juliusz, > > Thanks for the update. > > On 20 Nov 2025, at 13:56, Juliusz Chroboczek <[email protected]> wrote: > > I did read this document as part of my shepherding. > > Very well written and to the point. Thank you. > > > Thanks, Luigi. > > I have a couple of nits that I put hereafter, marked with [LI]. > > > I've just published -04, which includes your changes except the following > one: > > Resolution may be recursive: the next-hop may itself be a prefix that > requires further resolution to map to the outgoing interface and L2 > address. V4-via-v6 routing does not prevent recursive resolution. > > > [LI] Does this include any form of recursion or just v4 -> v6 -> v6 ….. > etc ? > Can you clarify? > > > Actually my point was about clearly stating that once you are in the ipv6 > domain you stay in ipv6. > But at the end of the day since this document is about v4-via-v6 it should > be ok the way it is stated now. > > > > Thank you. > > > > Since we only define v4-via-v6, once you're in v6 land you stay there. If > we were to ever define v6-via-v4 (which I'm not advocating), then you > could in principle alternate between the two domains, which would likely > lead to an increase in nervous breakdowns among network administrators. > > I'm not too keen on expanding on this statement, since I have no > operational experience with recursive v4-via-v6, and I'm afraid I'll say > something wrong. So please let me take the low-risk path of not saying > anything more about recursion, at least until we get some operational > experience with recursion together with v4-via-v6. > > Thanks again, > > -- Juliusz > > > > The following comment in section 4 has not been addressed. > > > Routers implementing the mechanism described in this document do not > need to have any IPv4 addresses assigned to any of their interfaces, > and RFC 1812 does not specify what happens if no router-id has been > > > [LI] Any reason why “RFC 1812” is not in brackets? > Any reason not evident to me? > > > Nope, just an oversight; thank you for catching it. > > W > > > Thanks > > L. > >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
