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