A Registry for PIM Message Types
RFC 6166
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
04 | (System) | Received changes through RFC Editor sync (changed abstract to 'This document provides instructions to IANA for the creation of a registry for PIM message types. … Received changes through RFC Editor sync (changed abstract to 'This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types. It also specifies a procedure for registering new types. In addition to this, one message type is reserved, and may be used for a future extension of the message type space. [STANDARDS-TRACK]') |
|
2015-10-14
|
04 | (System) | Notify list changed from pim-chairs@ietf.org, draft-ietf-pim-registry@ietf.org to (None) |
|
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for Robert Sparks |
|
2012-08-22
|
04 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2011-04-26
|
04 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-04-26
|
04 | Cindy Morgan | [Note]: changed to 'RFC 6166' |
|
2011-04-25
|
04 | (System) | RFC published |
|
2011-03-10
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-03-09
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2011-03-02
|
04 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2011-03-02
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-02-25
|
04 | (System) | IANA Action state changed to In Progress |
|
2011-02-23
|
04 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-02-23
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2011-02-23
|
04 | Amy Vezza | IESG has approved the document |
|
2011-02-23
|
04 | Amy Vezza | Closed "Approve" ballot |
|
2011-02-23
|
04 | Adrian Farrel | Approval announcement text changed |
|
2011-02-23
|
04 | Adrian Farrel | Approval announcement text changed |
|
2011-02-23
|
04 | Adrian Farrel | Approval announcement text regenerated |
|
2011-02-23
|
04 | Adrian Farrel | Ballot writeup text changed |
|
2011-02-17
|
04 | Cindy Morgan | Removed from agenda for telechat |
|
2011-02-17
|
04 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation. |
|
2011-02-17
|
04 | (System) | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by IESG Secretary |
|
2011-02-17
|
04 | Dan Romascanu | [Ballot comment] > 3.2. Assignment of new message types > Assignment of new message types is done according to the "IETF Review" model, … [Ballot comment] > 3.2. Assignment of new message types > Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]. Adding new message types is quite a radical action. It seems that "IETF Review" policy is not enough, as IETF Review does not mandate a standards track document, but just WG or AD-sponsored documents that go through IETF Lasc Call (but still could be Informational or Experimental). ":Standards Action" policy seems to be needed in order to update this document. In any case, if the policy stays as it is I would prefer that the text is edited more clearly to indicate that the message-type registry in this document is the initial state of the document that may be modified according to the procedure descrobed in this document. |
|
2011-02-17
|
04 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss |
|
2011-02-17
|
04 | Dan Romascanu | [Ballot discuss] > 3.2. Assignment of new message types > Assignment of new message types is done according to the "IETF Review" model, … [Ballot discuss] > 3.2. Assignment of new message types > Assignment of new message types is done according to the "IETF Review" model, see [RFC5226]. Adding new message types would update this document whose intended status is PS. It looks like "IETF Review" policy is not enough, as IETF Review does not mandate a standards track document, but just WG or AD-sponsored documents that go through IETF Lasc Call (but still could be Informational or Experimental). ":Standards Action" policy seems to be needed in order to update this document. Note that if Robert's DISCUSS is resolved by donwngrading the intended status of this document to Informational, than "IETF Review" would be sufficient. |
|
2011-02-17
|
04 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-02-17
|
04 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-17
|
04 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-17
|
04 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
|
2011-02-16
|
04 | Tim Polk | [Ballot comment] I can't remember if there is a precedent for registry documents achieving PS. The decision to reserve the value 15 to support extensibility … [Ballot comment] I can't remember if there is a precedent for registry documents achieving PS. The decision to reserve the value 15 to support extensibility might be justification, but that seems relatively weak. So, I support discussing Robert's issue, but do not have a particularly strong position either way. If anyone can point out precedent justifying going PS that would be enough for me... |
|
2011-02-16
|
04 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-16
|
04 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-15
|
04 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-15
|
04 | Robert Sparks | [Ballot discuss] Why is the intended status PS? This isn't a candidate for progression on the standards ladder (an interop report will never make sense). |
|
2011-02-15
|
04 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-02-15
|
04 | Lars Eggert | [Ballot comment] Section 3.2., paragraph 1: > Assignment of new message types is done according to the "IETF > Review" model, see [ … [Ballot comment] Section 3.2., paragraph 1: > Assignment of new message types is done according to the "IETF > Review" model, see [RFC5226]. It'd be good to add "or IESG Approval" here - there are sometimes cases where that shortcut is needed. |
|
2011-02-15
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-14
|
04 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-14
|
04 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded |
|
2011-02-13
|
04 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-02-11
|
04 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-02-11
|
04 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-01-31
|
04 | Adrian Farrel | Placed on agenda for telechat - 2011-02-17 |
|
2011-01-31
|
04 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
|
2011-01-31
|
04 | Adrian Farrel | Ballot has been issued |
|
2011-01-31
|
04 | Adrian Farrel | Created "Approve" ballot |
|
2011-01-31
|
04 | (System) | New version available: draft-ietf-pim-registry-04.txt |
|
2011-01-25
|
04 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Catherine Meadows. |
|
2011-01-25
|
04 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-01-24
|
04 | Amanda Baber | Upon approval of this document, IANA understands that a new registry is to be created using the following specifications. The new registry will be the … Upon approval of this document, IANA understands that a new registry is to be created using the following specifications. The new registry will be the PIM message type registry. It will be placed in the "Protocol Independent Multicast (PIM)" part of the IANA Matrix. Each entry in the registry consists of message type, message name and references to the documents defining the type. New registrations in this registry are done through IETF Review. There are initial registrations in this registry, as follows: Type Name Reference ---- ---------------------------------------- --------------------- 0 Hello [RFC3973] [RFC4601] 1 Register [RFC4601] 2 Register Stop [RFC4601] 3 Join/Prune [RFC3973] [RFC4601] 4 Bootstrap [RFC4601] 5 Assert [RFC3973] [RFC4601] 6 Graft [RFC3973] 7 Graft-Ack [RFC3973] 8 Candidate RP Advertisement [RFC4601] 9 State Refresh [RFC3973] 10 DF Election [RFC5015] 15 Reserved (for extension of type space) [RFC-to-be] IANA understands that establishing this registry is the only IANA action that needs to be completed upon approval of this document. |
|
2011-01-18
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
|
2011-01-18
|
04 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
|
2011-01-11
|
04 | Amy Vezza | Last call sent |
|
2011-01-11
|
04 | Amy Vezza | State changed to In Last Call from In Last Call. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from In Last Call. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pim@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pim-registry-03.txt> (A Registry for PIM Message Types) to Proposed Standard The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Registry for PIM Message Types' <draft-ietf-pim-registry-03.txt> as a 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 2011-01-25. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-registry/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-registry/ |
|
2011-01-11
|
04 | Adrian Farrel | Last Call text changed |
|
2011-01-11
|
04 | Adrian Farrel | Intended Status has been changed to Proposed Standard from Informational |
|
2011-01-11
|
04 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <pim@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-pim-registry-03.txt> (A Registry for PIM Message Types) to Informational RFC The IESG has received a request from the Protocol Independent Multicast WG (pim) to consider the following document: - 'A Registry for PIM Message Types' <draft-ietf-pim-registry-03.txt> as an Informational RFC 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 2011-01-25. 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pim-registry/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pim-registry/ |
|
2011-01-11
|
04 | Adrian Farrel | Last Call was requested |
|
2011-01-11
|
04 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup. |
|
2011-01-11
|
04 | Adrian Farrel | Last Call text changed |
|
2011-01-11
|
04 | (System) | Ballot writeup text was added |
|
2011-01-11
|
04 | (System) | Last call text was added |
|
2011-01-11
|
04 | (System) | Ballot approval text was added |
|
2011-01-11
|
04 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
|
2011-01-11
|
03 | (System) | New version available: draft-ietf-pim-registry-03.txt |
|
2011-01-10
|
04 | Adrian Farrel | Ballot writeup text changed |
|
2011-01-10
|
04 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD Review === Hi, Don't panic! I have performed my AD review of your draft. The … State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD Review === Hi, Don't panic! I have performed my AD review of your draft. The purpose of the review is to catch any nits or issues before the document goes forward to IETF last call and IESG review. By getting these issues out at this stage we can hope for a higher quality review and a smoother passage through the process. Cracking draft, thank you. I have only one observation: this I-D needs to be on the Standards Track in order to create a registry (I think!). Can you tweak that and resubmit? Then I'll issue IETF last call. Cheers, Adrian |
|
2011-01-10
|
04 | Adrian Farrel | State changed to AD Evaluation from Publication Requested. |
|
2011-01-10
|
02 | (System) | New version available: draft-ietf-pim-registry-02.txt |
|
2011-01-07
|
04 | Cindy Morgan | > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the document > and, in … > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the document > and, in particular, does he or she believe this version is ready > for forwarding to the IESG for publication? > > Mike McBride is the document shepherd. I have personally reviewed the > document, and believe it is ready for publication as an Informational > RFC. > > (1.b) Has the document had adequate review both from key members of > the interested community and others? Does the Document Shepherd > have any concerns about the depth or breadth of the reviews that > have been performed? > > The document has undergone thorough review within IETF's Multicast > community. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, e.g., > security, operational complexity, someone familiar with AAA, > internationalization or XML? > > No > > (1.d) Does the Document Shepherd have any specific concerns or > issues 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 interested community has discussed those issues and has > indicated that it still wishes to advance the document, detail > those concerns here. > > I have no concerns. > > (1.e) How solid is the consensus of the interested community behind > this document? Does it represent the strong concurrence of a few > individuals, with others being silent, or does the interested > community as a whole understand and agree with it? > > There is consensus within the PIM WG to publish the document. The > document > has been actively discussed on the wg list and in wg meetings. > > > (1.f) 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 > entered into the ID Tracker.) > > No. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See > http://www.ietf.org/ID-Checklist.html and > http://tools.ietf.org/tools/idnits/). Boilerplate checks are not > enough; this check needs to be thorough. Has the document met all > formal review criteria it needs to, such as the MIB Doctor, media > type and URI type reviews? > > Yes. > > > (1.h) Has the document split its references into normative and > informative? 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 strategy for their > completion? Are there normative references that are downward > references, as described in [RFC3967]? If so, list these downward > references to support the Area Director in the Last Call procedure > for them [RFC3967]. > > Yes. Normative references are all stable documents published as RFCs. > > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body of > the document? If the document specifies protocol extensions, are > reservations requested in appropriate IANA registries? Are the > IANA registries clearly identified? If the document creates a new > registry, does it define the proposed initial contents of the > registry and an allocation procedure for future registrations? > Does it suggested a reasonable name for the new registry? See > [I-D.narten-iana-considerations-rfc2434bis]. If the document > describes an Expert Review process has Shepherd conferred with the > Responsible Area Director so that the IESG can appoint the needed > Expert during the IESG Evaluation? > > > The IANA Considerations section exists. It requests IANA to create a PIM > > message type registry. > > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML code, > BNF rules, MIB definitions, etc., validate correctly in an > automated checker? > > > Not applicable. > > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Writeup. Recent examples can be found in the > "Action" announcements for approved documents. > > > Apart from this document, there is no existing document specifying a > registry for PIM message types. There are currently several RFCs > > specifying new PIM version 2 message types that should be in this new > > registry. > > This document specifies the initial content of the new PIM message > type registry based on those existing RFCs. This document also > specifies a procedure for registering new PIM message types. > > Additionally, this document reserves one message type. |
|
2011-01-07
|
04 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
|
2011-01-07
|
04 | Cindy Morgan | [Note]: 'Mike McBride (mmcbride@cisco.com) is the document shepherd.' added by Cindy Morgan |
|
2010-10-25
|
01 | (System) | New version available: draft-ietf-pim-registry-01.txt |
|
2010-05-04
|
00 | (System) | New version available: draft-ietf-pim-registry-00.txt |