Subject: [pim] Barry Leiba's Discuss on draft-ietf-pim-reserved-bits-03: (with DISCUSS and COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Fri, 13 Sep 2019 13:14:11 -0700

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

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 16 Sep 2019 17:05:23 +0000

On September 13, 2019 at 4:14:15 PM, Barry Leiba via Datatracker ([email-masked]<mailto:[email-masked]>) wrote:

[Author hat on.]

Barry:

Hi!  Thanks for the review!

…

We’re ok with the suggested format for the Registry.  I think it will in fact clarify.

Before changing the document, I sent a message to IANA to get their opinion.  Once we settle that conversation I’ll update the document.

I’ve made changes in my working copy.

Thanks!

Alvaro.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 16 Sep 2019 10:14:15 -0700

Thanks, Álvaro!

b

On Mon, Sep 16, 2019 at 10:05 AM Alvaro Retana
<[email-masked]> wrote:
>
> On September 13, 2019 at 4:14:15 PM, Barry Leiba via Datatracker ([email-masked]) wrote:
>
> [Author hat on.]
>
> Barry:
>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 19 Sep 2019 21:17:06 +0000

Barry:

Hi!

I just posted an update with the new registry format.   It does look a lot better. :-)

Please take a look.

Alvaro.

On September 16, 2019 at 1:05:39 PM, Alvaro Retana ([email-masked]<mailto:[email-masked]>) wrote:

…

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Sep 2019 08:20:00 -0700

Hi, Álvaro.

> I just posted an update with the new registry format.   It does look a lot better. :-)

Looked, and cleared; thanks very much for dealing with this.

Barry