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]
