[pim] Secdir last call review of draft-ietf-pim-jp-extensions-lisp-07

Peter Yee via Datatracker <noreply@ietf.org> Thu, 26 September 2024 01:21 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@ietfa.amsl.com
Received: from [10.244.2.86] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 620EBC1519A4; Wed, 25 Sep 2024 18:21:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Peter Yee via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.25.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172731369497.191742.9419556127381676264@dt-datatracker-6c75f7dfff-hrjh6>
Date: Wed, 25 Sep 2024 18:21:34 -0700
Message-ID-Hash: I4DSDSVLY4ZYG3DU4DVZ6AF3OF2M37PT
X-Message-ID-Hash: I4DSDSVLY4ZYG3DU4DVZ6AF3OF2M37PT
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-jp-extensions-lisp.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Peter Yee <peter@akayla.com>
Subject: [pim] Secdir last call review of draft-ietf-pim-jp-extensions-lisp-07
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Kjimg4x_co7tsiAj-7SwNBK16tk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>

Reviewer: Peter Yee
Review result: Has Nits

I lack sufficient knowledge of PIM and LISP to know if the security
considerations specified in this update to RFC 8059 suffice. That said, based
on my assumptions around the new security considerations, I believe the
mitigations listed are pertinent to the new threats despite leaving the reader
to discern how they are to effected.

For the sake of the RFC Editor and other inexpert readers like me, I do offer
the following nits for consideration:

Page 2, section 1, 2nd paragraph, 3rd sentence: it might be better to point at
RFC 9300 for the definitions rather than RFC 6831. This is what was done on the
very next page, so rather than confusing the reader, just point to one place.

Page 2, section 1, 3rd paragraph: insert “needs to” before “avoid” for easier
reading.

Page 3, section 2: delete “very”.

Page 3, section 2.1, 1st sentence: change “a RLOC” to “an RLOC” matching usage
in some of the references. Please give a reference to such usage as “G-u”,
“G-u1”, etc. I could not easily find matching usage in RFC 8059 or RFC 9300. It
may be that these are well understood in the community.

Page 3, section 2.1, 2nd sentence: bracket “e.g.” in commas.

Page 4, section 3.1, 1st paragraph: drop “RFC8059”. You don’t need both the
name and the reference. If using the name, separate “RFC” from the number, as
is the RFC Editor’s preferred style.

Page 4, section 3.1, 2nd paragraph: drop “RFC 8059” (correctly formatted here!).

Page 5, 1st bullet item: delete a redundant “tree”.

Page 5, section 6, 3rd sentence: please provide a reference to what you
consider to be suitable PIM authentication mechanisms. RFC 4601/RFC 5796?
draft-ietf-pim-3376bis? Something else?