Skip to main content

The Protocol Independent Multicast (PIM) Join Attribute Format
draft-ietf-pim-join-attributes-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-10-23
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-10-23
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-10-23
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-10-22
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-10-22
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-10-16
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-10-09
06 (System) IANA Action state changed to In Progress
2008-10-06
06 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2008-10-06
06 Cindy Morgan IESG state changed to Approved-announcement sent
2008-10-06
06 Cindy Morgan IESG has approved the document
2008-10-06
06 Cindy Morgan Closed "Approve" ballot
2008-10-06
06 David Ward State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Ward
2008-10-06
06 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-10-06
06 (System) New version available: draft-ietf-pim-join-attributes-06.txt
2008-08-14
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-08-14
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-07-28
06 Tim Polk
[Ballot discuss]
This is a revised discuss.

Issue #1 raised in Joe Salowey's secdir review needs to be addressed:

    1. The new attributes …
[Ballot discuss]
This is a revised discuss.

Issue #1 raised in Joe Salowey's secdir review needs to be addressed:

    1. The new attributes may be forwarded by a router that does not
    understand them (transitive attributes).  It seems that this behavior is
  different than the link-local assumptions in 4601 security
  considerations. 

Since the security considerations section is mainly a reference to 4601,
some text describing additional security considerations that are created
by this behavior is needed.
2008-07-28
05 (System) New version available: draft-ietf-pim-join-attributes-05.txt
2008-07-01
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-06-30
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-06-30
04 (System) New version available: draft-ietf-pim-join-attributes-04.txt
2008-06-06
06 (System) Removed from agenda for telechat - 2008-06-05
2008-06-05
06 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-06-05
06 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-06-05
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-06-04
06 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-06-04
06 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-06-04
06 Chris Newman
[Ballot comment]
The document contains a number of "TBD" scattered throughout the text
which I presume are supposed to be filled in with values that …
[Ballot comment]
The document contains a number of "TBD" scattered throughout the text
which I presume are supposed to be filled in with values that IANA
registers.  It would be a good idea to tell the RFC editor that is your
intention explicitly so none of them are accidentally missed prior to
publication.
2008-06-04
06 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-06-04
06 Lars Eggert
[Ballot comment]
Section 4., paragraph 1:
>    A new IANA registry is needed for PIM Join Attributes Types.

  Doesn't describe the allocation procedure …
[Ballot comment]
Section 4., paragraph 1:
>    A new IANA registry is needed for PIM Join Attributes Types.

  Doesn't describe the allocation procedure for new values or the
  initial values. (The gen-art review also raises this issue; I'll let
  Russ hold the DISCUSS for that.)
2008-06-04
06 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2008-06-04
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-06-04
06 Tim Polk
[Ballot discuss]
This is a preliminary discuss; I may revise it before the telechat.  However, I wanted to
start the discussion ASAP in hopes that …
[Ballot discuss]
This is a preliminary discuss; I may revise it before the telechat.  However, I wanted to
start the discussion ASAP in hopes that the issues can be resolved before the call.

First, the security considerations only references RFC 4601.  While PIM-SM is the most
widely deployed, I had expected to see references to RFC 5015 and 3973 as well to cover
PIM-DM and bidirectional PIM as well.  (I would say 3569 as well, but those security
considerations aren't too helpful.)  Is there a reason they don't apply?

Secondly, Joe Salowey's security directorate review (see the email from March 28) raised
three specific issues.  To my knowledge there has been no response.  I am still trying to
decide which if any of Joe's issues should be blocking, but all seem to be reasonable
suggestions...
2008-06-04
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Discuss from Undefined by Tim Polk
2008-06-04
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-06-04
06 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-06-04
06 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-06-03
06 Lisa Dusseault
[Ballot comment]
I'm sure the RFC Editor will expand "PIM" to "Protocol Independent Multicast", but if the authors have a chance, please note that the …
[Ballot comment]
I'm sure the RFC Editor will expand "PIM" to "Protocol Independent Multicast", but if the authors have a chance, please note that the Abstract is not going to be informative to all readers as-is.
2008-06-03
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-06-03
06 Ron Bonica [Ballot comment]
Support Jari's DISCUSS
2008-06-03
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-06-03
06 Russ Housley
[Ballot discuss]
The Gen-ART Rewview by Elwyn Davies indicates that the document is not
  ready for publication.  The has not been a response to …
[Ballot discuss]
The Gen-ART Rewview by Elwyn Davies indicates that the document is not
  ready for publication.  The has not been a response to the review.
  Please respond to the Last Call comments in the Gen-ART Review:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-pim-join-attributes-03-davies.txt
2008-06-03
06 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-06-03
06 Jari Arkko
[Ballot discuss]
This document is in good shape, and I only found one error. While
a small issue, I think it needs to be corrected. …
[Ballot discuss]
This document is in good shape, and I only found one error. While
a small issue, I think it needs to be corrected. Please find suggested
edit below. This has been designed to be something that can either
be inserted as an RFC Editor note into the tracker or handled with the
publication of a new draft, if other changes are also necessary.

This figure seems to assume 4 byte addresses:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Addr Family  | Encoding Type | Rsrvd  |S|W|R|  Mask Len    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Source Address (Encoded-Source format)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....

Whereas RFC 4601 clearly describes the address field as being of
variable length due to IPv4/IPv6 differences. See Section 4.9.1.
Please change to:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Addr Family  | Encoding Type | Rsrvd  |S|W|R|  Mask Len    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Source Address (Encoded-Source format) 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
2008-06-03
06 Jari Arkko
[Ballot discuss]
This figure seems to assume 4 byte addresses:

  0                  1          …
[Ballot discuss]
This figure seems to assume 4 byte addresses:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Addr Family  | Encoding Type | Rsrvd  |S|W|R|  Mask Len    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Source Address (Encoded-Source format)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....

Whereas RFC 4601 clearly describes the address field as being of
variable length due to IPv4/IPv6 differences. See Section 4.9.1.
Please change to:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Addr Family  | Encoding Type | Rsrvd  |S|W|R|  Mask Len    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Source Address (Encoded-Source format) 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
2008-06-03
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from No Objection by Jari Arkko
2008-06-03
06 Jari Arkko
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action …
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action taken depends upon the type.
  This may or may not result in the processing of the next attribute.

Does the last sentence imply (a) that an attribute can disable the
processing of any attributes after itself or (b) that an attribute
can disable/control the processing of attributes of the same type
after itself?

I think you mean the latter. A small edit to make this clearer
would be useful in my opinion.
2008-06-03
06 Jari Arkko
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action …
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action taken depends upon the type.
  This may or may not result in the processing of the next attribute.

Does the last sentence imply (a) that an attribute can disable the
processing of any attributes after itself or (b) that an attribute
can disable/control the processing of attributes of the same type
after itself?

I think you mean the latter. A small edit to make this clearer
would be useful in my opinion.

This figure seems to assume 4 byte addresses:

  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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Addr Family  | Encoding Type | Rsrvd  |S|W|R|  Mask Len    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Source Address (Encoded-Source format)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....
  |F|S|  Type    | Length        | Value
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.....

Whereas RFC 4601 clearly describes the address field as being of
variable length due to IPv4/IPv6 differences. See Section 4.9.1.
2008-06-03
06 Jari Arkko
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action …
[Ballot comment]
I am asking for clarification on this:

  For each type, the first attribute of
  that type is processed, and the action taken depends upon the type.
  This may or may not result in the processing of the next attribute.

Does the last sentence imply (a) that an attribute can disable the
processing of any attributes after itself or (b) that an attribute
can disable/control the processing of attributes of the same type
after itself?

I think you mean the latter. A small edit to make this clearer
would be useful in my opinion.
2008-06-03
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-05-09
06 David Ward [Ballot Position Update] New position, Yes, has been recorded for David Ward
2008-05-09
06 David Ward Ballot has been issued by David Ward
2008-05-09
06 David Ward Created "Approve" ballot
2008-05-09
06 David Ward State Changes to IESG Evaluation from Waiting for AD Go-Ahead by David Ward
2008-05-09
06 David Ward Placed on agenda for telechat - 2008-06-05 by David Ward
2008-04-01
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Joseph Salowey.
2008-03-26
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-03-19
06 Amanda Baber
IANA Last Call comments:

IANA has questions:

- What information is required in the new "PIM Join Attribute Types"
registry?

- What are the Registration …
IANA Last Call comments:

IANA has questions:

- What information is required in the new "PIM Join Attribute Types"
registry?

- What are the Registration Procedures for the new registry?

- What is the name of the new PIM-Hello Option?

Action 1:

Upon approval of this document, the IANA will create the following
registry "PIM Join Attribute Types" located at
http://www.iana.org/assignments/TBD

Registration Procedures: Not Defined

Initial contents of this registry will be:

Type Name Reference
----- ----------- -------------------
0-63 Available for assignment [RFC-pim-join-attributes-03]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Protocol Independent Multicast (PIM) Hello
Options" registry located at
http://www.iana.org/assignments/pim-hello-options

Value Length Name Reference
----------- --------- ----------------------------------------- ----------
[tbd(26)] 0 Join [RFC-pim-join-attributes-03]


We understand the above to be the only IANA Actions for this
document.
2008-03-13
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Joseph Salowey
2008-03-13
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Joseph Salowey
2008-03-12
06 Amy Vezza Last call sent
2008-03-12
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-03-11
06 David Ward Last Call was requested by David Ward
2008-03-11
06 David Ward State Changes to Last Call Requested from Publication Requested by David Ward
2008-03-11
06 (System) Ballot writeup text was added
2008-03-11
06 (System) Last call text was added
2008-03-11
06 (System) Ballot approval text was added
2007-09-27
06 Ross Callon Draft Added by Ross Callon in state Publication Requested
2007-05-21
03 (System) New version available: draft-ietf-pim-join-attributes-03.txt
2006-10-25
02 (System) New version available: draft-ietf-pim-join-attributes-02.txt
2006-03-10
01 (System) New version available: draft-ietf-pim-join-attributes-01.txt
2005-10-20
00 (System) New version available: draft-ietf-pim-join-attributes-00.txt