[pim] Orie Steele's No Objection on draft-ietf-pim-3810bis-11: (with COMMENT)

Orie Steele via Datatracker <noreply@ietf.org> Sun, 04 August 2024 20:16 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 7345CC14EB17; Sun, 4 Aug 2024 13:16:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Orie Steele 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: <172280259906.475113.18261774785735816598@dt-datatracker-6dd76c4557-2mkrj>
Date: Sun, 04 Aug 2024 13:16:39 -0700
Message-ID-Hash: MGEISLAUBE5LG3TZUF35P7K72TBNCPB2
X-Message-ID-Hash: MGEISLAUBE5LG3TZUF35P7K72TBNCPB2
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-3810bis@ietf.org, pim-chairs@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Orie Steele <orie@transmute.industries>
Subject: [pim] Orie Steele's No Objection on draft-ietf-pim-3810bis-11: (with COMMENT)
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/M35_u-18hxZaxORCqwio_PFDWjA>
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>

Orie Steele has entered the following ballot position for
draft-ietf-pim-3810bis-11: No Objection

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-3810bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Orie Steele, ART AD, comments for draft-ietf-pim-3810bis-11
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-3810bis-11.txt&submitcheck=True

## Comments

### Why not MUST NOT?

```
1182               multicast address, if it is non-empty.  An SSM-aware host
1183               SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast
1184               addresses that fall within the SSM address range as they will
1185               be ignored by SSM-aware routers [RFC4604].
```

```
1206               the specified multicast address, if it is non-empty.  An SSM-
1207               aware host SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record
1208               type for multicast addresses that fall within the SSM address
1209               range.
```

Is this simply a SHOULD because it won't cause harm, because it is ignored?

Are there cases where an SSM-aware host MUST / MUST NOT send MODE_IS_EXCLUDE or
CHANGE_TO_EXCLUDE_MODE ?

### Why not MUST?

```
1292       Records of the Report message.  From now on, it will treat packets
1293       sent to those multicast addresses according to this new listening
1294       state.  Once a valid link-local address is available, a node SHOULD
1295       generate new MLDv2 Report messages for all multicast addresses joined
1296       on the interface.
```

Under which conditions should a node not generate new new MLDv2 Report messages.

```
2414       SHOULD log an error.  It is RECOMMENDED that implementions provide a
2415       configuration option to disable use of Host Compatibility Mode to
2416       allow networks to operate only in SSM mode.  This configuration
2417       option SHOULD be disabled by default.
```

implementions -> implementations

Under which conditions is it ok to leave this configuration enabled by default?