Skip to main content

PIM Message Type Space Extension and Reserved Bits
draft-ietf-pim-reserved-bits-04

Revision differences

Document history

Date Rev. By Action
2020-02-28
04 (System) RFC Editor state changed to AUTH48-DONE from TI
2020-02-18
04 (System) RFC Editor state changed to TI from AUTH48-DONE
2020-02-13
04 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-02-03
04 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-12-17
04 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-10-10
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2019-10-09
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2019-10-09
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2019-10-08
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2019-09-27
04 (System) RFC Editor state changed to EDIT
2019-09-27
04 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-09-27
04 (System) Announcement was received by RFC Editor
2019-09-26
04 (System) IANA Action state changed to In Progress
2019-09-26
04 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2019-09-26
04 Cindy Morgan IESG has approved the document
2019-09-26
04 Cindy Morgan Closed "Approve" ballot
2019-09-26
04 Cindy Morgan Ballot writeup was changed
2019-09-26
04 Deborah Brungard Ballot approval text was changed
2019-09-26
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins.
2019-09-20
04 Barry Leiba
[Ballot comment]
(Thanks for addressing my DISCUSS about the registry format!)

And just a few minor editorial comments:

— Abstract —

  specifies how these …
[Ballot comment]
(Thanks for addressing my DISCUSS about the registry format!)

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”.
2019-09-20
04 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2019-09-19
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-09-19
04 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2019-09-19
04 Alvaro Retana New version available: draft-ietf-pim-reserved-bits-04.txt
2019-09-19
04 (System) New version approved
2019-09-19
04 (System) Request for posting confirmation emailed to previous authors: Stig Venaas , Alvaro Retana
2019-09-19
04 Alvaro Retana Uploaded new revision
2019-09-19
03 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-09-19
03 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2019-09-18
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-09-18
03 Benjamin Kaduk
[Ballot comment]
Thanks for this; after the table edits under discussion, it will be a very useful document.

I just have a few minor comments. …
[Ballot 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.)
2019-09-18
03 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2019-09-18
03 Alissa Cooper
[Ballot comment]
I'm guessing this is unnecessary but just wanted to check: do you need a further extension point in case all 48 subtypes of …
[Ballot comment]
I'm guessing this is unnecessary but just wanted to check: do you need a further extension point in case all 48 subtypes of types 13, 14, and 15 get used up at some point? That is, RFC 6166 had reserved a code point for future extensions of the type space. Is it possible that another future extension will be needed and if so, should a code point be reserved for it?
2019-09-18
03 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-09-18
03 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-09-17
03 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Regards,

-éric

== COMMENTS ==

-- Section 3 --
C.1) Is it "Flags Bits" …
[Ballot comment]
Thank you for the work put into this document.

Regards,

-éric

== COMMENTS ==

-- Section 3 --
C.1) Is it "Flags Bits" (two "s") as in figure 1 or "Flag bits" (one "s") as in the text ?

C.2) Shouldn't PIM Ver and Checksum fields be described?


-- Section 4.2 --
C.2) I am a tad inconfortable to have "bits" of a field named "flag bits" to be used for sub-type. For me, "bits" are completely unstructured and atomic and using 4 of those bits to build a 4-bit field does not seem natural. Rather than naming the field "flags bits" what about "special purpose bits" or something similar ?
2019-09-17
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-09-17
03 Martin Vigoureux
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be …
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
  ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
    15.0-15.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
  ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.
2019-09-17
03 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-09-17
03 Martin Vigoureux
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be …
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
  ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
                0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
                0-3      (Reserved)                    [this document]
    15.0-15.15            Unassigned                  [this document]
                0-3      (Reserved)                    [this document]
  ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.
2019-09-17
03 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-09-17
03 Martin Vigoureux
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be …
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
  ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
              0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
              0-3      (Reserved)                    [this document]
    15.0-15.15            Unassigned                  [this document]
              0-3      (Reserved)                    [this document]
  ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.
2019-09-17
03 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-09-17
03 Martin Vigoureux
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be …
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
  ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
    15.0-15.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
  ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.
2019-09-17
03 Martin Vigoureux Ballot comment text updated for Martin Vigoureux
2019-09-17
03 Martin Vigoureux
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be …
[Ballot comment]
Hi,
I support Barry's DISCUSS on the IANA table and his proposal looks great.
However I wonder if the new entries shouldn't be
  ---------------------------------------------------------------------
    13.0-13.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
    14.0-14.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document] 
    15.0-15.15            Unassigned                  [this document]
                      0-3      (Reserved)                    [this document]
  ---------------------------------------------------------------------

nit in the intro:
"these documents"
It is not fully clear to which docs you refer to. I guess it's all the ones being updated, but still.
2019-09-17
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-09-16
03 Adam Roach
[Ballot comment]
Barry caught *literally* every last comment I had, so I have nothing to add. I support his DISCUSS on the readability of the …
[Ballot comment]
Barry caught *literally* every last comment I had, so I have nothing to add. I support his DISCUSS on the readability of the IANA table.
2019-09-16
03 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-09-16
03 Alvaro Retana [Ballot Position Update] New position, Recuse, has been recorded for Alvaro Retana
2019-09-16
03 Roman Danyliw
[Ballot comment]
I support Barry Leiba’s DISCUSS position on clarifying the structure of the IANA table.  I would add that the convention of using the …
[Ballot comment]
I support Barry Leiba’s DISCUSS position on clarifying the structure of the IANA table.  I would add that the convention of using the decimal point to convey a sub-type number should be explained (i.e., 13.4 is type=13, sub-type=4)

Editorial Nits:
-- Per Page Title.  Typo.  s/Type Extention/Extension/

-- Section 3. Typo.  s/FIgure 1/Figure 1/

-- Section 4.2.  Unlike Section 4.1 and 4.3, this section doesn’t say “The usage of the bit is defined in that document”. 

-- Section 5.  Capitalize. s/pim extension/PIM extensions/
2019-09-16
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-09-16
03 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2019-09-14
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-09-13
03 Barry Leiba
[Ballot discuss]
Thanks for a simple, clear document.  This should be really, really easy to sort out:

— Section 1 —

  Documents defining a …
[Ballot 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
2019-09-13
03 Barry Leiba
[Ballot comment]
And just a few minor editorial comments:

— Abstract —

  specifies how these bits may be used by individual message types, and …
[Ballot 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”.
2019-09-13
03 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2019-09-13
03 Susan Hares Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Susan Hares. Sent review to list.
2019-09-12
03 Cindy Morgan Placed on agenda for telechat - 2019-09-19
2019-09-12
03 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2019-09-12
03 Deborah Brungard Ballot has been issued
2019-09-12
03 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2019-09-12
03 Deborah Brungard Created "Approve" ballot
2019-09-12
03 Deborah Brungard Ballot writeup was changed
2019-09-03
03 Peter Yee Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list.
2019-09-03
03 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-08-30
03 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2019-08-30
03 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pim-reserved-bits-03. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pim-reserved-bits-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

The PIM Message Types on the Protocol Independent Multicast (PIM) Parameters registry page located at:

https://www.iana.org/assignments/pim-parameters/

is to be completely replaced. The reference for the registry will now be [ RFC-to-be ].

The new registry is as follows:

Type Flag Bits Name Reference
----------+-----------+---------------------------+------------------
0 N/A Hello [RFC3973][RFC7761]
0 0-7 Reserved [RFC3973][RFC7761]
1 N/A Register [RFC7761]
1 0-7 Reserved [RFC7761]
2 N/A Register Stop [RFC7761]
2 0-7 Reserved [RFC7761]
3 N/A Join/Prune [RFC3973][RFC7761]
3 0-7 Reserved [RFC3973][RFC7761]
4 N/A Bootstrap [RFC7761]
4 0-6 Reserved [RFC5059][RFC7761]
4 7 No-Forward [RFC5059]
5 N/A Assert [RFC3973][RFC7761]
5 0-7 Reserved [RFC3973][RFC7761]
6 N/A Graft [RFC3973]
6 0-7 Reserved [RFC3973]
7 N/A Graft-Ack [RFC3973]
7 0-7 Reserved [RFC3973]
8 N/A Candidate RP Advertisement [RFC7761]
8 0-7 Reserved [RFC7761]
9 N/A State Refresh [RFC3973]
9 0-7 Reserved [RFC3973]
10 N/A DF Election [RFC5015]
10 0-3 Reserved [RFC5015]
10 4-7 Subtype [RFC5015]
11 N/A ECMP Redirect [RFC6754]
11 0-7 Reserved [RFC6754]
12 N/A PIM Flooding Mechanism [RFC8364]
12 0-6 Reserved [RFC8364]
12 7 No-Forward [RFC8364]
13.0-13.15 N/A Unassigned [ RFC-to-be ]
14.0-14.15 N/A Unassigned [ RFC-to-be ]
15.0-15.15 N/A Unassigned [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-08-22
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-08-22
03 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Susan Hares
2019-08-22
03 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2019-08-22
03 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2019-08-22
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2019-08-22
03 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2019-08-20
03 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-08-20
03 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-09-03):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, draft-ietf-pim-reserved-bits@ietf.org, pim-chairs@ietf.org, mmcbride7@gmail.com, Mike …
The following Last Call announcement was sent out (ends 2019-09-03):

From: The IESG
To: IETF-Announce
CC: db3546@att.com, draft-ietf-pim-reserved-bits@ietf.org, pim-chairs@ietf.org, mmcbride7@gmail.com, Mike McBride , pim@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PIM Message Type Space Extension and Reserved Bits) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'PIM Message Type Space Extension and
Reserved Bits'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-09-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The PIM version 2 messages share a common message header format.  The
  common header definition contains eight reserved bits.  This document
  specifies how these bits may be used by individual message types, and
  creates a registry containing the per message type usage.  This
  document also extends the PIM type space by defining three new
  message types.  For each of the new types, four of the previously
  reserved bits are used to form an extended type range.

  This document Updates RFC7761 and RFC3973 by defining the use of the
  currently Reserved field in the PIM common header.  This document
  further updates RFC7761 and RFC3973, along with RFC5015, RFC5059,
  RFC6754 and RFC8364, by specifying the use of the currently Reserved
  bits for each PIM message.

  This document obsoletes RFC6166.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-reserved-bits/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pim-reserved-bits/ballot/


No IPR declarations have been submitted directly on this I-D.




2019-08-20
03 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-08-20
03 Deborah Brungard Last call was requested
2019-08-20
03 Deborah Brungard Ballot approval text was generated
2019-08-20
03 Deborah Brungard Ballot writeup was generated
2019-08-20
03 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2019-08-20
03 Deborah Brungard Last call announcement was generated
2019-08-15
03 Alvaro Retana Shepherding AD changed to Deborah Brungard
2019-08-15
03 Alvaro Retana New version available: draft-ietf-pim-reserved-bits-03.txt
2019-08-15
03 (System) New version approved
2019-08-15
03 (System) Request for posting confirmation emailed to previous authors: pim-chairs@ietf.org, Stig Venaas , Alvaro Retana
2019-08-15
03 Alvaro Retana Uploaded new revision
2019-08-07
02 Mike McBride
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?

Proposed Standard. Standards Track is indicated on the draft and is appropriate
particularly with the update to the PIM Message Types registry.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The currently defined PIM version 2 messages share a common message
header format. The common header definition contains eight reserved
bits. This document specifies how these bits may be used by
individual message types, and creates a registry containing the per
message type usage. This document also extends the PIM type space by
defining three new message types.

Working Group Summary

There was very thorough review by several WG members. There were a few
comments and all were addressed to the wg's satisfaction.

Document Quality

Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g., one
that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type review, on what date
was the request posted?

Not really applicable here as its updating a registry

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Mike McBride is the documet shepherd and Alvaro Retana is the
responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This version is ready for publication and has been reviewed by the
shepherd and the co-chair.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. Thorough reviews were performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Not applicable.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The document as a whole has been understood and we had many
individuals respond on the list with a show of support from various
vendors and research institutes.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No other formal review other then the PIM WG.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

This document Updates RFC7761 and RFC3973 by defining the use of the
currently Reserved field in the PIM common header. This document
further updates RFC7761 and RFC3973, along with RFC5015, RFC6754 and
RFC8364, by specifying the use of the currently Reserved bits for
each PIM message

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Updates to the referenced IANA registries have been clearly identified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The following changes should be made to the existing PIM Message
Types registry.

For types 4 (Bootstrap) and 8 (Candidate RP Advertisement) a reference to
RFC5059 should be added. For the currently unassigned types 13 and 14,
and the reserved type 15, the name should be changed to "Type Space
Extension", and reference this document. In addition, right underneath each
of the rows for types 13, 14 and 15, there should be a new row where it
says "13.0-13.15 Unassigned", "14.0-14.15 Unassigned" and "15.0-15.15
Unassigned", respectively.

A new registry called "PIM Message Type Flag Bits" should be created
in the pim-paremeters section with registration procedure "IETF
Venaas & Retana Expires December 27, 2019 [Page 5]
Internet-Draft PIM reserved bits and type space extension June 2019
Review" as defined in [RFC8126] with this document as a reference.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-08-07
02 Mike McBride Responsible AD changed to Alvaro Retana
2019-08-07
02 Mike McBride IETF WG state changed to Submitted to IESG for Publication from WG Document
2019-08-07
02 Mike McBride IESG state changed to Publication Requested from I-D Exists
2019-08-07
02 Mike McBride IESG process started in state Publication Requested
2019-08-07
02 Mike McBride Changed consensus to Yes from Unknown
2019-08-07
02 Mike McBride Intended Status changed to Proposed Standard from None
2019-08-07
02 Mike McBride
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?

Proposed Standard. Standards Track is indicated on the draft and is appropriate
particularly with the update to the PIM Message Types registry.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The currently defined PIM version 2 messages share a common message
header format. The common header definition contains eight reserved
bits. This document specifies how these bits may be used by
individual message types, and creates a registry containing the per
message type usage. This document also extends the PIM type space by
defining three new message types.

Working Group Summary

There was very thorough review by several WG members. There were a few
comments and all were addressed to the wg's satisfaction.

Document Quality

Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g., one
that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type review, on what date
was the request posted?

Not really applicable here as its updating a registry

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Mike McBride is the documet shepherd and Alvaro Retana is the
responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This version is ready for publication and has been reviewed by the
shepherd and the co-chair.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No. Thorough reviews were performed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Not applicable.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

The document as a whole has been understood and we had many
individuals respond on the list with a show of support from various
vendors and research institutes.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No other formal review other then the PIM WG.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

This document Updates RFC7761 and RFC3973 by defining the use of the
currently Reserved field in the PIM common header. This document
further updates RFC7761 and RFC3973, along with RFC5015, RFC6754 and
RFC8364, by specifying the use of the currently Reserved bits for
each PIM message

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Updates to the referenced IANA registries have been clearly identified.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

The following changes should be made to the existing PIM Message
Types registry.

For types 4 (Bootstrap) and 8 (Candidate RP Advertisement) a reference to
RFC5059 should be added. For the currently unassigned types 13 and 14,
and the reserved type 15, the name should be changed to "Type Space
Extension", and reference this document. In addition, right underneath each
of the rows for types 13, 14 and 15, there should be a new row where it
says "13.0-13.15 Unassigned", "14.0-14.15 Unassigned" and "15.0-15.15
Unassigned", respectively.

A new registry called "PIM Message Type Flag Bits" should be created
in the pim-paremeters section with registration procedure "IETF
Venaas & Retana Expires December 27, 2019 [Page 5]
Internet-Draft PIM reserved bits and type space extension June 2019
Review" as defined in [RFC8126] with this document as a reference.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A
2019-07-24
02 Mike McBride Notification list changed to Mike McBride <mmcbride7@gmail.com>
2019-07-24
02 Mike McBride Document shepherd changed to Mike McBride
2019-06-25
02 Stig Venaas New version available: draft-ietf-pim-reserved-bits-02.txt
2019-06-25
02 (System) New version approved
2019-06-25
02 (System) Request for posting confirmation emailed to previous authors: Stig Venaas , pim-chairs@ietf.org, Alvaro Retana
2019-06-25
02 Stig Venaas Uploaded new revision
2019-05-28
01 Stig Venaas New version available: draft-ietf-pim-reserved-bits-01.txt
2019-05-28
01 (System) New version approved
2019-05-28
01 (System) Request for posting confirmation emailed to previous authors: Stig Venaas , Alvaro Retana
2019-05-28
01 Stig Venaas Uploaded new revision
2019-04-21
00 (System) Document has expired
2019-03-25
00 Stig Venaas Added to session: IETF-104: pim  Thu-1350
2018-10-18
00 Mike McBride This document now replaces draft-venaas-pim-reserved-bits instead of None
2018-10-18
00 Stig Venaas New version available: draft-ietf-pim-reserved-bits-00.txt
2018-10-18
00 (System) WG -00 approved
2018-10-12
00 Stig Venaas Set submitter to "Stig Venaas ", replaces to draft-venaas-pim-reserved-bits and sent approval email to group chairs: pim-chairs@ietf.org
2018-10-12
00 Stig Venaas Uploaded new revision