[pim] Barry Leiba's Discuss on draft-ietf-pim-reserved-bits-03: (with DISCUSS and COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Fri, 13 September 2019 20:14 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 7B30B120123; Fri, 13 Sep 2019 13:14:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba 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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156840565149.31866.6948305667396220479.idtracker@ietfa.amsl.com>
Date: Fri, 13 Sep 2019 13:14:11 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/tJOPkLFUgvk-drMY-t3N7AGAoeU>
Subject: [pim] Barry Leiba's Discuss on draft-ietf-pim-reserved-bits-03: (with DISCUSS and COMMENT)
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: Fri, 13 Sep 2019 20:14:12 -0000
Barry Leiba has entered the following ballot position for draft-ietf-pim-reserved-bits-03: 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/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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for a simple, clear document. This should be really, really easy to sort out: — Section 1 — Documents defining a new message type MUST define the usage of the corresponding Flag Bits. Indeed, and we do this frequently in the IETF. How do we make sure that future documents comply with this? I think we need to put this sentence in the registry of PIM Message Types, by adding something to Section 7, in addition to just changing the reference pointer to point here. I’ve incorporated that into my suggestion for the registry table, below. — Section 7 — Wow. Table 1 looks very confusing to me. I did get what you’re doing, but I had to stare at it for a while, and it’s better not to make people work that hard. Might this work better?: NEW Assignments into this registry MUST define the usage of the Flag Bits in addition to defining the Type. Type Flag Bits Name Reference --------------------------------------------------------------------- 0 Hello [RFC3973][RFC7761] 0-7 (Reserved) [RFC3973][RFC7761] --------------------------------------------------------------------- 1 Register [RFC7761] 0-7 (Reserved) [RFC7761] --------------------------------------------------------------------- 2 Register Stop [RFC7761] 0-7 (Reserved) [RFC7761] --------------------------------------------------------------------- 3 Join/Prune [RFC3973][RFC7761] 0-7 (Reserved) [RFC3973][RFC7761] --------------------------------------------------------------------- 4 Bootstrap [RFC7761] 0-6 (Reserved) [RFC5059][RFC7761] 7 No-Forward [RFC5059] --------------------------------------------------------------------- 5 Assert [RFC3973][RFC7761] 0-7 (Reserved) [RFC3973][RFC7761] --------------------------------------------------------------------- 6 Graft [RFC3973] 0-7 (Reserved) [RFC3973] --------------------------------------------------------------------- 7 Graft-Ack [RFC3973] 0-7 (Reserved) [RFC3973] --------------------------------------------------------------------- 8 Candidate RP Advertisement [RFC7761] 0-7 (Reserved) [RFC7761] --------------------------------------------------------------------- 9 State Refresh [RFC3973] 0-7 (Reserved) [RFC3973] --------------------------------------------------------------------- 10 DF Election [RFC5015] 0-3 (Reserved) [RFC5015] 4-7 Subtype [RFC5015] --------------------------------------------------------------------- 11 ECMP Redirect [RFC6754] 0-7 (Reserved) [RFC6754] --------------------------------------------------------------------- 12 PIM Flooding Mechanism [RFC8364] 0-6 (Reserved) [RFC8364] 7 No-Forward [RFC8364] --------------------------------------------------------------------- 13.0-13.15 Unassigned [this document] 14.0-14.15 Unassigned [this document] 15.0-15.15 Unassigned [this document] --------------------------------------------------------------------- Table 1: Updated PIM Message Types Registry END ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- And just a few minor editorial comments: — Abstract — specifies how these bits may be used by individual message types, and creates a registry containing the per message type usage. There needs to be hyphens in “per-message-type”, as it’s a compound modifier (and similarly in the second paragraph of the Introduction (but not in the first paragraph, where it isn’t a modifier)). — Section 3 — 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PIM Ver| Type | Flags Bits | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FIgure 1: New Common Header The Flags Bits field is defined in Section 4. All other fields remain unchanged. The rest of the document calls these “Flag Bits”, without the “s” on “Flags”. Can we change these two instances to be consistent with that? — Section 4 — The specification of a new PIM type, MUST indicate whether the bits should be treated differently. Remove the comma, please. When defining Flag Bits it is helpful to have a well defined way of referring to a particular bit. Hyphenate “well-defined”.
- [pim] Barry Leiba's Discuss on draft-ietf-pim-res… Barry Leiba via Datatracker
- Re: [pim] Barry Leiba's Discuss on draft-ietf-pim… Alvaro Retana
- Re: [pim] Barry Leiba's Discuss on draft-ietf-pim… Barry Leiba
- Re: [pim] Barry Leiba's Discuss on draft-ietf-pim… Alvaro Retana
- Re: [pim] Barry Leiba's Discuss on draft-ietf-pim… Barry Leiba