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] > <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> >>> >>> On Fri, Nov 21, 2025 at 10:11 AM, Luigi Iannone <[email protected] >>> <mailto:[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] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Hi Juliusz, >>>>> >>>>> Thanks for the update. >>>>> >>>>>> On 20 Nov 2025, at 13:56, Juliusz Chroboczek <[email protected] >>>>>> <mailto:[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]
