[pim] Benjamin Kaduk's No Objection on draft-ietf-pim-reserved-bits-03: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Wed, 18 September 2019 22:53 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pim-reserved-bits@ietf.org, Mike McBride <mmcbride7@gmail.com>, pim-chairs@ietf.org, mmcbride7@gmail.com, pim@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156884721924.4499.4683079303770512605.idtracker@ietfa.amsl.com>
Date: Wed, 18 Sep 2019 15:53:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/iFiad5ZTLd-QwV1RjcosTs1gQOk>
Subject: [pim] Benjamin Kaduk's No Objection on draft-ietf-pim-reserved-bits-03: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pim-reserved-bits-03: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

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

Thanks for this; after the table edits under discussion, it will be a very useful document.

I just have a few minor comments.

It is perhaps slightly unusual to have an Updates: relationship but only
an informative reference relationship to the documents being updated,
but in this case it seems appropriate.

Section 1

type usage. Documents defining a new message type MUST define the
usage of the corresponding Flag Bits.

Is "leave some of them Reserved for Future Use" an acceptable
definition? (Section 4 implies "yes".) Pedagogically, it seems
redundant to say "MUST define" and also have text in Section 4 that
gives a default behavior if the "MUST define" is ignored.

Section 3

It looks like 7761 specifies that the flag bits are included in the
Checksum (in the common header); we may want to call that out in case
some implementation had been short-circuiting the actual flags value for
checksum verification.

Section 5

to be used by each extended type. Documents defining a new extended
message type MUST define the usage of the corresponding Flag Bits.

(Same comment as for Section 1.)

[pim] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker