[pim] Paul Wouters' Discuss on draft-ietf-pim-3228bis-06: (with DISCUSS)

Paul Wouters via Datatracker <noreply@ietf.org> Wed, 07 August 2024 19:19 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@ietfa.amsl.com
Received: from [10.244.2.66] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id CF6B9C14F5EB; Wed, 7 Aug 2024 12:19:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172305835951.1013121.1666113825012029615@dt-datatracker-6dd76c4557-2mkrj>
Date: Wed, 07 Aug 2024 12:19:19 -0700
Message-ID-Hash: S7JP5X3PBWLS6RETXWSC5KZ4VIFMMB4N
X-Message-ID-Hash: S7JP5X3PBWLS6RETXWSC5KZ4VIFMMB4N
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@ietf.org, pim-chairs@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Subject: [pim] Paul Wouters' Discuss on draft-ietf-pim-3228bis-06: (with DISCUSS)
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/LD2oiwKD5h0vvf0W_-5WJENgW0I>
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>

Paul Wouters has entered the following ballot position for
draft-ietf-pim-3228bis-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-3228bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I find it a bit odd that the reason for why the IANA registration policies are
changed to Standards Track is only listed in the Security Considerations. I
think this belongs in the Abstract and / or Introduction.

In the Security Considerations it lists that the justification is more or less
that middleware screws up unknown values, so by making it harder to make
registrations, this will reduce the bad impact of this misbehaving middleware.
I guess my question is if this is really the appropriate action for the IETF to
take in response to badly engineered middleware boxes. I am assuming the old
registration policy had a justification that is still valid but now thrown
under the bus. Has there been any discussion of this on an IETF list? For
example have known middlware vendors been approached to try and get their
implementations updated?

It might be that this document is a "last resort" kind of action, but neither
the document nor the Shepherds Writeup give any indication of this.