[RTG-DIR]Rtgdir last call review of draft-ietf-pim-3376bis-10

Adrian Farrel via Datatracker <noreply@ietf.org> Thu, 23 May 2024 15:58 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE0AC1CAF4C; Thu, 23 May 2024 08:58:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adrian Farrel via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171647991903.5462.16194298731921404795@ietfa.amsl.com>
Date: Thu, 23 May 2024 08:58:39 -0700
Message-ID-Hash: N5TIYEXCYMWESNHRYF4FMIB3DEVOQK4K
X-Message-ID-Hash: N5TIYEXCYMWESNHRYF4FMIB3DEVOQK4K
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-3376bis.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
Subject: [RTG-DIR]Rtgdir last call review of draft-ietf-pim-3376bis-10
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Reviewer: Adrian Farrel
Review result: Has Nits

Hi,

I have reviewed this document during IETF last call as part of the
Routing Directorate. The comments are principally for the benefit of the
Routing ADs, but it may be sensible to take them as IETF last call 
comments and apply fixes or discuss them with me.

The document is a simple update to RFC 3376 to include some fixes, 
mainly arising from Errata Reports. The changes have been clearly 
applied (with the exception of 1501 and 7339 as mentioned below).

The applicability of this work to routing are clear and need no
further work.

My comments are all editorial in nature, although the first one applies
to the metadata and so has slightly more weight.

Cheers,
Adrian

===

Per Errata Reports 1501 and 7339, shouldn't the document header say
"Updates: 2236 (if approved)"

And the Abstract and Introduction explain why/how this is an update?

---

The Abstract is a little confusing about whether this is a revision to
IGMPv3 (which would not be IGMPv3) or just a revised version of the
specification.
I think that this document specifies IGMPv3, so you need to say:
- This document specifies IGMPv3
- It is a revised version of the specificaltion to include
  clarifications and fixes for errata in RFC 3376
- It obsoletes RFC 3376
- It backward compatible with the specification included in RFC 3376

I would begin the Abstract with the three sentences that describe IGMP
and IGMPv3. Then I would have a second para to describe this document.

---

1. 

A much better approach than the Abstract. No mention of a revision of
3376, just a specification of IGMPv3.

However:

a. The statement of obsoleting 3376 is too terse. You need to:
   - Give a brief statement of why/how
   - Point to Appendix C for the details

b. The BCP 14 boilerplate is very out of date. You need to use the
   most recent version. It is also customary to put this in its own
   section (such as 1.1).

---

13.

I-D.ietf-pim-3228bis should be a normative reference.

---

Appendix C

No mention of Errata Report 7339?