Hi Mahesh, Just one clarification. Since the reference changed from informative to normative (to address my DISCUSS), this document will stay in MISREF at the RFC Editor until the PIM document is approved by the IESG. IMHO, this is a better way to ensure the PIM WG document progresses in a timely manner. This is also, IMHO, a better way to ensure the development of parallel/dependent documents across different WGs, which I've seen happen frequently at the IETF. If your concern is that the PIM WG document is not yet mature, then I might be missing something since it is a bis document and you were OK with referencing the base experimental RFCs that it is obsoleting.
I agree that this is up to Jim and Gunter since it pertains to coordination between the LISP and PIM WGs. Thanks, Ketan On Thu, Sep 17, 2026 at 9:56 AM Mahesh Jethanandani <[email protected]> wrote: > Hi Ketan, > > Thanks for the context - and Prasad didn't waste any time getting -02 out. > > I'm fine keeping the reference to draft-ietf-pim-rfc8059-9798bis rather > than reverting to RFC 8059/RFC 9798 directly. > > What I would like is some assurance that draft-ietf-pim-rfc8059-9798bis > reaches WGLC before rfc6831bis moves forward. It sat expired > with no activity from March until yesterday, so a same-day revival on > its own isn't quite enough for me to treat the dependency as live > rather than aspirational. WGLC is a fair, visible signal that the PIM > WG intends to carry it forward on a real timeline, without requiring > the rest of the process to be done. > > It would also help to see this tracked as an actual milestone on the > PIM charter. The existing "advance jp-extensions-lisp to RFC" > milestone was for the predecessor draft and is already done - that > shipped as RFC 9798 - so nothing on the charter currently covers this > consolidation document. > > Jim - since you're the responsible AD on rfc6831bis, this is really > your call to make. My ask is just that the document be held in > your queue until pim-rfc8059-9798bis reaches WGLC before sending > it to the RFC Editor. > > Thanks. > > On Sep 15, 2026, at 9:40 PM, Ketan Talaulikar <[email protected]> > wrote: > > Hi Mahesh, > > On your DISCUSS point on draft-ietf-pim-rfc8059-9798bis, the suggestion > to reference this document that is aimed at PS as a normative reference was > recommended by me as part of my DISCUSS. I believe this is the best way > forward to avoid a downref to two experimental RFCs that the PIM WG is > obsoleting, which we are well aware of. If this means the document waits in > the RFC-Editor Q due to a MISREF, so be it. This, to me, is the right thing > to do. > > Thanks, > Ketan > > > On Wed, Sep 16, 2026 at 12:16 AM Mahesh Jethanandani via Datatracker < > [email protected]> wrote: > >> 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. >> >> >> ---------------------------------------------------------------------- >> 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. >> >> --- >> >> 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. >> >> ---------------------------------------------------------------------- >> 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/ >> >> 203 > This document obsolotes [RFC6831], please see Appendix A for >> changes. >> s/obsolotes/obsoletes/ >> >> 660 > There is no D -->ata-Probe logic for ETRs as there can be in the >> s/D -->ata-Probe/Data-Probe/ >> >> 1016 > defined in Sec 5.4 of [RFC9301] When the M Priority is set >> to 255, >> s/[RFC9301] When/[RFC9301]. When/ >> >> 1368 > important changes incude: >> s/incude/include/ >> >> >> >> _______________________________________________ >> iesg mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > > Mahesh Jethanandani > [email protected] > > > > > > >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
