Hi Mahesh, thanks for your help in improving the document.
I’ve just updated the writeup to highlight the dependency to draft-ietf-pim-rfc8059-9798bis. Ciao L. > On 22 Oct 2026, at 19:12, Mahesh Jethanandani <[email protected]> wrote: > > Hi Prasad, Ketan and Luigi, > > Thanks for the updates. I've checked -13 against my comments: > > - The orphaned Informative entry for draft-ietf-pim-rfc8059-9798bis is > gone, and Section 8.3.2 now makes both address checks MUST with an > explicit discard rule. Both COMMENTs are resolved. > > - On the DISCUSS, I'm fine with keeping the normative reference to > draft-ietf-pim-rfc8059-9798bis and letting this document wait in the > RFC Editor queue in MISREF until the PIM document is approved, as > Ketan has suggested. > > The one thing still outstanding is the shepherd write-up. Question 18 > still says "No normative references are in unclear state or not > ready." That was true when it was written against -06, but it isn't > now: the document has a normative reference to a PIM WG draft that > hasn't been through WGLC yet. Luigi, could you update the answer to > Q18 to list draft-ietf-pim-rfc8059-9798bis and note the plan (the > document will be held in MISREF until the PIM draft is approved)? > Once that's done, I’ll be happy to clear my DISCUSS. > > Thanks > >> On Oct 11, 2026, at 8:44 AM, Vengada Prasad Govindan (venggovi) >> <[email protected]> wrote: >> >> Hello Mahesh, >> Thanks for your notes, please see inline with GVP1> All comments accepted >> are incorporated in ver-12 >> Thanks >> Prasad >> >> -----Original Message----- >> From: Mahesh Jethanandani via Datatracker <[email protected]> >> Sent: Wednesday, September 16, 2026 12:16 AM >> To: The IESG <[email protected]> >> Cc: [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: Mahesh Jethanandani's Discuss on draft-ietf-lisp-rfc6831bis-08: >> (with DISCUSS and COMMENT) >> >> Mahesh Jethanandani has entered the following ballot position for >> draft-ietf-lisp-rfc6831bis-08: Discuss >> >> When responding, please keep the subject line intact and reply to all email >> addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6831bis/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Section 16, Normative References: >> >> 1234 > [I-D.ietf-pim-rfc8059-9798bis] >> 1235 > Govindan, V. P. and S. Venaas, "PIM Join Attributes for >> 1236 > Locator/ID Separation Protocol (LISP) Environments", >> Work >> 1237 > in Progress, Internet-Draft, draft-ietf-pim-rfc8059- >> 1238 > 9798bis-01, 14 March 2026, >> >> This is a normative reference to draft-ietf-pim-rfc8059-9798bis-01, >> which is the specification this document actually depends on for the >> PIM Join/Prune attributes it uses: >> >> 414 > [I-D.ietf-pim-rfc8059-9798bis]; this document specifies no >> 415 > additional state machinery. >> >> 653 > specified in [I-D.ietf-pim-rfc8059-9798bis]. >> >> draft-ietf-pim-rfc8059-9798bis-01 expired in March 2026. There's >> currently no path to publication for it. >> >> The history here is worth spelling out, because I think it points to >> an easy fix. Through -06, this document cited RFC 8059 and RFC 9798 >> directly for these attributes. Darren Dukes' RTGDIR review asked >> whether those two should be normative or informative references. The >> author's reply on the list was, in effect, that the question was moot >> because both were being folded into a single reference to >> draft-ietf-pim-rfc8059-9798bis, and that's what shipped in -08. Having >> now read that bis draft, I don't think the trade was a good one: it's >> a pure consolidation of RFC 8059 and RFC 9798 (it just moves the >> Transport Attribute and Receiver RLOC Attribute registrations into one >> document) and doesn't define anything new that this document actually >> relies on. So the change that answered Darren's question left the >> document with an unresolved dependency in its place. >> >> I'd ask the authors to revert Section 4 item 8 and Section 7.1 to >> citing RFC 8059 and RFC 9798 directly, and drop the reference to the >> bis draft. That does bring Darren's original question back: RFC 8059 >> and RFC 9798 are Experimental, and this document targets Proposed >> Standard, so citing them normatively is a downref. But that's a >> well-understood problem with a known process. >> >> I'd also note the shepherd write-up (answering as of -06) states there >> are no normative references in an unclear state. That was accurate >> when written; the -07/-08 revision changed that, and it's worth a >> fresh look before this goes further. >> GVP1> draft-ietf-pim-rfc8059-9798-bis is a normative reference. This >> document will be progressed. >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 17, Informative References, still carries a second, uncited >> entry for the same draft: >> >> 1314 > [draft-ietf-pim-rfc8059-9798bis] >> 1315 > Govindan, V. and S. Venaas, "PIM Join Attributes for >> 1316 > Locator/ID Separation Protocol (LISP) Environments", >> Work >> 1317 > in Progress, Internet-Draft, draft-ietf-pim-rfc8059- >> 1318 > 9798bis-01, 14 March 2026, >> >> Nothing in the body cites this anchor - both in-text uses I found >> (Section 4 item 8 and Section 7.1) use [I-D.ietf-pim-rfc8059-9798bis], >> which is the normative entry. This looks like debris from the same >> edit that produced my DISCUSS. >> GVP1> Not Informative anymore. >> --- >> >> Building on Ketan's DISCUSS-2 about the unicast receiving procedure, >> the normative text in Section 8.3.2 has a scope problem: >> >> 811 > When using a unicast underlay, an ETR MUST accept a unicast LISP- >> 812 > encapsulated multicast packet only where the outer destination >> 813 > address is one of its own RLOCs. Additionally, it MAY check whether >> 814 > the outer source address is the ITR RLOC it selected for the >> 815 > (S-EID,G) in question. It MUST discard the packet otherwise. >> >> "Otherwise" is ambiguous between the two preceding sentences. If it >> only refers back to the destination-address MUST, the optional source >> check in the middle sentence is pointless - there's no discard >> obligation tied to failing it. If it's meant to cover a failed source >> check too, that needs to be MUST-level for a conforming implementation >> to know what to do when it chooses to perform the check at all. >> GVP1> Fixed this. Both the conditions are made MUST, removed otherwise. >> >> ---------------------------------------------------------------------- >> NIT >> ---------------------------------------------------------------------- >> >> All comments below are about very minor potential issues that you may >> choose to address in some way - or ignore - as you see fit. Some were >> flagged by automated tools (via >> https://github.com/larseggert/ietf-reviewtool), so there will likely >> be some false positives. There is no need to let me know what you did >> with these suggestions. >> >> 195 > [I-D.ietf-lisp-multicast-deploy]. Deployments have successfuly >> s/successfuly/successfully/ >> GVP1> Fixed >> 203 > This document obsolotes [RFC6831], please see Appendix A for >> changes. >> s/obsolotes/obsoletes/ >> GVP1> Fixed >> 660 > There is no D -->ata-Probe logic for ETRs as there can be in the >> s/D -->ata-Probe/Data-Probe/ >> GVP1> Fixed >> 1016 > defined in Sec 5.4 of [RFC9301] When the M Priority is set to >> 255, >> s/[RFC9301] When/[RFC9301]. When/ >> GVP1> Fixed >> 1368 > important changes incude: >> s/incude/include/ >> GVP1> Fixed >> >> > > > Mahesh Jethanandani > [email protected] > > > > > >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
