Nevermind the OIF-list comment. My brain wasn’t on, and I typically see this as OIL. I think it still might be worth describing it as terminology, but it’s not specific to 6381.
Joe
From: Joe Clarke via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, September 24, 2024 at 14:09
To: ops-dir@xxxxxxxx <ops-dir@xxxxxxxx>
Cc: draft-ietf-pim-jp-extensions-lisp.all@xxxxxxxx <draft-ietf-pim-jp-extensions-lisp.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, pim@xxxxxxxx <pim@xxxxxxxx>
Subject: [OPS-DIR]Opsdir last call review of draft-ietf-pim-jp-extensions-lisp-07
Reviewer: Joe Clarke
Review result: Has Nits
I have been asked to review this draft on behalf of the OPS directorate. This
draft updates RFC8059 to specify PIM Receiver RLOC Join/Prune attribute to
connect multiple LISP sites when underlay IP multicast is used. Overall, I
thought the document was clear, but I did find a few nitty issues. The biggest
point of confusion for me was the mention of "oif-list" in Section 3.3. This
is defined in RFC6381 (experimental) where they use OIF-list. I think at least
an informative reference is needed for clarity of this term and the form
"OIF-list" should be used.
Other nits:
Section 3.2:
OLD:
This field MUST be used only when the
NEW:
This field MUST only be used when then
I think this form is a bit clearer with the normative MUST.
Section 3.3:
You have a duplicate "tree" there (i.e., "tree tree").
_______________________________________________
OPS-DIR mailing list -- ops-dir@xxxxxxxx
To unsubscribe send an email to ops-dir-leave@xxxxxxxx
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
