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 |