Skip to main content

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