[pim] Artart last call review of draft-ietf-pim-3228bis-05

Martin Dürst via Datatracker <noreply@ietf.org> Tue, 04 June 2024 08:47 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECA5C151531; Tue, 4 Jun 2024 01:47:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Martin Dürst via Datatracker <noreply@ietf.org>
To: art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171749084536.37257.3498399355231855483@ietfa.amsl.com>
Date: Tue, 04 Jun 2024 01:47:25 -0700
Message-ID-Hash: 2HBFCRR64Y4DLVHKLIGWSBT7FOQURS52
X-Message-ID-Hash: 2HBFCRR64Y4DLVHKLIGWSBT7FOQURS52
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-3228bis.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Martin Dürst <duerst@it.aoyama.ac.jp>
Subject: [pim] Artart last call review of draft-ietf-pim-3228bis-05
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Tjs0FlHBR1wnYm24KuezC-bM3aA>
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: Martin Dürst
Review result: Ready with Issues

This document obsoletes RFC 3228. I have read both RFC 3228 and this document,
they were both very short.

The new document changes registry policy for Type and Code fields in the IPv4
IGMP header from IESG Approval or Standards Action to Standards Action
exclusively. It also creates new registries for Query Message Flags (in the
Multicast Listener Query Message and the IGMPv3 Query Message) and Report
Message Flags (in the Multicast Listener Report Message and the IGMPv3 Report
Message). Each of them is populated with one entry, with Standards Action for
future entries.

This is mostly a document about registry bookkeeping. I did not find any
application related issues.

The main issue and only issue that I found is that the detailed (10 lines)
security section was replaced with a one-liner in the new document, without
references elsewhere. As a result, there are some registries, but other than
"Standards Action", there is no advice at all for what should be considered
when planning additional registrations.

Regards,    Martin.