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] >
_______________________________________________ lisp mailing list -- [email protected] To unsubscribe send an email to [email protected]
