[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”.