[pim] Intdir telechat review of draft-ietf-pim-igmp-mld-extension-05

Tommy Pauly via Datatracker <noreply@ietf.org> Thu, 20 January 2022 16:31 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 3F4EC3A1812; Thu, 20 Jan 2022 08:31:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tommy Pauly via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-pim-igmp-mld-extension.all@ietf.org, last-call@ietf.org, pim@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.42.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164269629720.6538.7760538444195255480@ietfa.amsl.com>
Reply-To: Tommy Pauly <tpauly@apple.com>
Date: Thu, 20 Jan 2022 08:31:37 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/MbmqVI6Nqwhuy6DeYMx9g3SheZQ>
Subject: [pim] Intdir telechat review of draft-ietf-pim-igmp-mld-extension-05
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jan 2022 16:31:37 -0000

Reviewer: Tommy Pauly
Review result: Ready with Issues

Thanks for writing this concise and clear document. The addition of TLV
extensions seems useful.

I don't see any major issues, but there are a few minor ones.

Like the genart reviewer, I believe this "should" ought to be normative:

"When this extension mechanism is used, the number of Group Records in each
Report message should be kept small enough that the entire message, including
any extension TLVs can fit within the network MTU."

In Section 4, I suggest rewording this and fixing capitalization:

"To check this, one will need to walk through each of The TLVs until there are
less than four octets left in the IP payload."

to:

"To check this, the parser needs to walk through each of the TLVs until there
are less than four octets left in the IP payload."

In Section 5, I suggest rewording this:

"IGMP and MLD implementations, host implementations in particular, rarely
change, and it is expected to take a long time for them to support this
extension mechanism."

to:

"IGMP and MLD implementations (particularly implementations on hosts) rarely
change, and the adoption process of this extension mechanism is expected to be
slow."

I also suggest that you consider giving guidance for preventing this new
extension point from ossifying, given the slow rate of change. Please see the
discussion in RFC 9170. For example, if you cannot guarantee active use and
change, you may want to suggest synthetic use of the extension point
("greasing" by endpoints sending unknown type values every now and then to make
sure receivers correctly handle unknown types).