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]
