Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)
draft-ietf-pim-sm-v2-new-12
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck |
2012-08-22
|
12 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2006-09-08
|
12 | (System) | This was part of a ballot set with: draft-ietf-pim-proposed-req |
2006-07-24
|
12 | Bill Fenner | State Change Notice email list have been change to pim-chairs@tools.ietf.org from pusateri@juniper.net, mcbride@cisco.com |
2006-03-28
|
12 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2006-03-21
|
12 | Amy Vezza | IESG state changed to Approved-announcement sent |
2006-03-21
|
12 | Amy Vezza | IESG has approved the document |
2006-03-21
|
12 | Amy Vezza | Closed "Approve" ballot |
2006-03-21
|
12 | Alex Zinin | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Alex Zinin |
2006-03-21
|
12 | Scott Hollenbeck | [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck |
2006-03-21
|
12 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2006-03-21
|
12 | (System) | New version available: draft-ietf-pim-sm-v2-new-12.txt |
2006-03-21
|
12 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2006-01-17
|
12 | Alex Zinin | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Alex Zinin |
2005-10-28
|
12 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2005-10-28
|
12 | (System) | Removed from agenda for telechat - 2005-10-27 |
2005-10-27
|
12 | Sam Hartman | [Ballot comment] This comment is not a discuss, but I am certainly not thrilled with the current situation. This document does not define a mandatory … [Ballot comment] This comment is not a discuss, but I am certainly not thrilled with the current situation. This document does not define a mandatory to implement security mechanism. It does tell network administrators how to use IPsec to secure PIM. That's not really enough for several reasons. First, it does not require the necessary features of IPsec be implemented along side PIM. Second, it provides a reasonably bad user experience: the user has to use a general mechanism that doesn't know about PIM not one that knows about PIM. So the user has to encode all the information about PIM and its traffic flows for the general mechanism. Unfortunately it is probably not as simple as having vendors provide easy configuration tools. While a vendor could do that for their own products, the user has enough flexibility in how they configure things that such a vendor would not be guaranteed to work with other products or arbitrary sites. So I'm not going to block this document. However we must do better in the future. The primary purpose of this comment is to say that I'm not happy with this direction and that the fact that this document passes IESG review may not be used as a justification that future work should be allowed through. I would certainly hold work started today to a higher standard. This document would also get a discuss because it has no mandatory automated key management if it were new work. We will have to work on what scale is appropriate for work already in progress. On a more positive note, I'd like to thank the authors for a really well written document. I wish all the specs I had to review were of this quality. |
2005-10-27
|
12 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman |
2005-10-27
|
12 | Allison Mankin | [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin by Allison Mankin |
2005-10-27
|
12 | Margaret Cullen | [Ballot comment] In draft-ietf-pim-sm-v2-new-11.txt: Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to … [Ballot comment] In draft-ietf-pim-sm-v2-new-11.txt: Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random character inserted at the beginning of the first line of each table, many of the horizontal lines are indented two or three characters which prevents proper vertical alignment, and the some of the vertical lines are too long and/or missing characters. Given the consistency of the problems, it seems likely that this is a document generation problem, rather than a set of typographical errors. draft-ietf-pim-proposed-req-01.txt This document is largely an implementation report. What is the lasting value of publishing this as an RFC? |
2005-10-27
|
12 | Margaret Cullen | [Ballot comment] In draft-ietf-pim-sm-v2-new-11.txt: Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to … [Ballot comment] In draft-ietf-pim-sm-v2-new-11.txt: Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random character inserted at the beginning of the first line of each table, many of the horizontal lines are indented two or three characters which prevents proper vertical alignment, and the some of the vertical lines are too long and/or missing characters. Given the consistency of the problems, it seems likely that this is a document generation problem, rather than a set of typographical errors. |
2005-10-27
|
12 | Margaret Cullen | [Ballot comment] Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random … [Ballot comment] Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random character inserted at the beginning of the first line of each table, many of the horizontal lines are indented two or three characters which prevents proper vertical alignment, and the some of the vertical lines are too long and/or missing characters. Given the consistency of the problems, it seems likely that this is a document generation problem, rather than a set of typographical errors. |
2005-10-27
|
12 | Margaret Cullen | [Ballot comment] Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random … [Ballot comment] Something is amiss with the ASCII art for most (or all) of the tables in this document. There appears to be a random character inserted at the beginning of the first line of each table, many of the horizontal lines are indented two or three characters which prevents proper vertical alignment, and the some of the horizontal lines are too long and/or missing characters. Given the consistency of the problems, it seems likely that this is a document generation problem, rather than a set of typographical errors. |
2005-10-27
|
12 | Margaret Cullen | [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman |
2005-10-27
|
12 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2005-10-26
|
12 | Bill Fenner | [Ballot Position Update] New position, Recuse, has been recorded for Bill Fenner by Bill Fenner |
2005-10-26
|
12 | Jon Peterson | [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Undefined by Jon Peterson |
2005-10-26
|
12 | Jon Peterson | [Ballot comment] For a document the size of draft-ietf-pim-sm-v2-new-11, it might be nice to have a concise "changes from RFC2362" section to describe … [Ballot comment] For a document the size of draft-ietf-pim-sm-v2-new-11, it might be nice to have a concise "changes from RFC2362" section to describe the changes to normative behavior. |
2005-10-26
|
12 | Jon Peterson | [Ballot Position Update] New position, Undefined, has been recorded for Jon Peterson by Jon Peterson |
2005-10-25
|
12 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2005-10-25
|
12 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to Undefined from No Objection by Bert Wijnen |
2005-10-25
|
12 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Undefined by Bert Wijnen |
2005-10-25
|
12 | Bert Wijnen | [Ballot comment] $ idnits draft-ietf-pim-proposed-req-01.txt idnits 1.77 (21 Aug 2005) draft-ietf-pim-proposed-req-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack … [Ballot comment] $ idnits draft-ietf-pim-proposed-req-01.txt idnits 1.77 (21 Aug 2005) draft-ietf-pim-proposed-req-01.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an Abstract section. * The document seems to lack a Security Considerations section. * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3978 Section 5.5 Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? * The document seems to lack an RFC 3979 Section 5, para 1 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3979 Section 5, para 2 IPR Disclosure Acknowledgement. * The document seems to lack an RFC 3979 Section 5, para 3 IPR Disclosure Invitation. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) * There is 1 instance of lines with control characters in the document. |
2005-10-25
|
12 | Bert Wijnen | [Ballot Position Update] New position, Undefined, has been recorded for Bert Wijnen by Bert Wijnen |
2005-10-24
|
12 | Russ Housley | [Ballot comment] draft-ietf-pim-sm-v2-new-11: There is an extra "|" character in the right margin in section 6.3, 3rd paragraph. s/IPSec/IPsec/ -- It … [Ballot comment] draft-ietf-pim-sm-v2-new-11: There is an extra "|" character in the right margin in section 6.3, 3rd paragraph. s/IPSec/IPsec/ -- It is correct most places, but not all places. draft-ietf-pim-proposed-req-01: In section 2.7: Please change "IP security authentication header" to "IP security (IPsec) authentication header (AH)" |
2005-10-24
|
12 | Russ Housley | [Ballot discuss] draft-ietf-pim-sm-v2-new-11: This document obsoletes RFC 2362. This needs to be indicated in the Title Page Header and in … [Ballot discuss] draft-ietf-pim-sm-v2-new-11: This document obsoletes RFC 2362. This needs to be indicated in the Title Page Header and in the Abstract. It might also be useful to tell the reader in the Introduction that RFC 2362 was Experimental, but this document is on the Standards-Track. Please reference draft-ietf-ipsec-rfc2401bis-06 instead of [7]. This document is in the RFC Editor queue. Section 6.3 is out of date. Many of these issues have been resolved, and they are documented in the IPsec WG documents that are in the RFC Editor queue. draft-ietf-pim-proposed-req-01: The document does not have a Security Considerations section. There are several sections that discuss security, so a simple section with pointers to them ought to be sufficient. |
2005-10-24
|
12 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
2005-10-24
|
12 | Scott Hollenbeck | [Ballot discuss] draft-ietf-pim-sm-v2-new-11, Section 2: please add a normative reference to RFC 2119 and include a citation here. |
2005-10-24
|
12 | Scott Hollenbeck | [Ballot Position Update] New position, Discuss, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2005-10-24
|
12 | Brian Carpenter | [Ballot comment] Gen-ART comments from Spencer Dawkins -sm-v2-new-11 Minor nits from automated scanning (I can't believe a 148-page document was so clean!): * There are … [Ballot comment] Gen-ART comments from Spencer Dawkins -sm-v2-new-11 Minor nits from automated scanning (I can't believe a 148-page document was so clean!): * There are 580 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Thanks, Spencer My notes from reading: In the second paragraph of the introduction: is the "will be able to successfully interoperate" text saying that RFC 2362 routers didn't follow the incorrect text in RFC 2362, or that the corrections in this specification are backward-compatible with RFC 2362? In Section 3, s/NOT definitive/NOT normative/ In Section 4.1.1, GenID has not been defined when it is introduced. In Section 4.1.2 or somewhere, it would be nice to say "periodic JOINs don't actually join anything, they just maintain "soft state" " - if this is correct. In Section 4.1.4 and a bunch of other places - PMBR is used without being defined until Appendix A. In Section 4.2, I would have thought you see whether the packet should be accepted based on TIB before resetting Keepalive Timers and checking the SPTbit. I'm not questioning the correctness, I'm saying that it might be nice to say *why* the validation can wait (since it wasn't obvious to me). At the end of 4.2 - can you give any guidance on the range of implementation-dependent rate-limiting values, either here or elsewhere? In Section 4.3.1, bottom of page 31 - this paragraph seems to envision a multicast router with one interface - is this correct? (I didn't think "one-armed routers" would apply here, but I'm asking a question, not trying to correct anything). In Section 4.3.1, last paragraph - is it necessary to wait the randomized interval when a primary address changes? Might be nice to say one way or another. In Section 4.3.2, last paragraph - could you say in one sentence what the damage of this non-compliant behavior is? In Section 4.3.3, could you point to default values for the delay and interval neighbor information? In Section 4.3.4, bottom of page 37 - could you say a word about the design choice to limit address types within a single Hello? In Section 4.4.1, Figure 1 and subsequent - could you say what '-' means in this table? In Section 4.4.2, middle paragraph on page 42 - the previous sentence points out that the behavior of Register-Stop(*,G) from an RP is ambiguous or incorrect in some circumstances, but then the spec says "should be able to accept". This seems underspecified? In Section 4.5.1, "Join" - s/except if/unless/ In Section 4.5.1, Receive Join, last paragraph - when we get a Join(*,*,RP) for an RP we don't know about, do we also store the RP? In Section 4.5.1, Receive Prune, it would be nice to have a sentence explaining why the Prune-Pending Timer expires immediately when there's only one neighbor (I think I understand why, but have to draw a picture, and you guys understand this better than I do, so I might misunderstand it). In Section 4.5.2, paragraph following Figure 3 - does "If the destination address is not correct" really mean "is not targeted to this router's primary address"? It might be better to use these words, if I'm getting the picture. In Section 4.5.5, second paragraph - "almost immediately"? Is this "immediately", or "after a randomized delay", or something else? While looking over Section 4.5.5, I happened to notice that we use the term "override" for a long time before we define it in 4.3.3 (usually we're talking about a Override Timer or something similar, with no indication of what it's used for). In Section 4.5.9 - s/implosions/response implosions/ (this phrasing is used later in the document, and is clearer to me here). In Section 4.6.2 - s/state machines where/state machines were/ In Section 4.6.5 - thank you for the Summary of Assert Rules and Rationale! In Section 4.8.2 - PIM-SSM-Only hasn't been mentioned at all in this specification until page 106. It would be really nice to at least mention it in the Introduction, or in Section 3, or SOMEwhere - it feels like it's landing from outer space, at this point! In Section 4.9.5.2, last paragraph - what does the router do with the N+1 .. M Prunes that didn't fit in the maximum-sized Join / Prune message? Just put them in another Join / Prune message, or something else? In Section 5.2 - is 65000 really the maximum, or was this shorthand for 64K? In Section 6.4 - I'm guessing that there aren't any possible mitigations for DOS attacks, but it might be good to say so, one way or the other. And I'm not sure what "false traffic" means - "traffic with forged source addresses", or something else? -proposed-req-01 Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an Abstract section. * The document seems to lack a Security Considerations section. * The document seems to lack an IANA Considerations section. But the Abstract could easily be the first sentence or two from the Introduction, and the Security and IANA Considerations are almost certainly "No considerations apply to a requirements analysis about a routing protocol, only to a specification for that routing protocol", or some such. The IPR statements are outdated, but that's easily corrected (if necessary, again, I defer to the ADs). I was surprised that there was no formal reference, normative or informative, to exactly WHAT the "(new) PIM Sparse-Mode protocol specification" actually is - was this an oversight? But, if so, again it is easily corrected. |
2005-10-24
|
12 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter |
2005-10-18
|
12 | Alex Zinin | State Changes to IESG Evaluation from Waiting for Writeup by Alex Zinin |
2005-10-18
|
12 | Alex Zinin | Placed on agenda for telechat - 2005-10-27 by Alex Zinin |
2005-10-18
|
12 | Alex Zinin | [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin |
2005-10-18
|
12 | Alex Zinin | Ballot has been issued by Alex Zinin |
2005-10-18
|
12 | Alex Zinin | Created "Approve" ballot |
2005-09-08
|
12 | Michelle Cotton | IANA Comments: This document appears to repeat the same registration rules as described in other documents. There appears not to be any new registrations for … IANA Comments: This document appears to repeat the same registration rules as described in other documents. There appears not to be any new registrations for this document. The IANA will confirm with the Authors/WG Chairs/ADs. |
2005-09-05
|
12 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2005-08-22
|
12 | Amy Vezza | Last call sent |
2005-08-22
|
12 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2005-08-19
|
12 | Alex Zinin | State Changes to Last Call Requested from AD Evaluation by Alex Zinin |
2005-08-19
|
12 | Alex Zinin | Last Call was requested by Alex Zinin |
2005-08-19
|
12 | (System) | Ballot writeup text was added |
2005-08-19
|
12 | (System) | Last call text was added |
2005-08-19
|
12 | (System) | Ballot approval text was added |
2005-03-09
|
12 | Alex Zinin | State Changes to AD Evaluation from AD Evaluation::External Party by Alex Zinin |
2005-03-09
|
12 | Alex Zinin | Note field has been cleared by Alex Zinin |
2004-11-02
|
12 | Alex Zinin | State Changes to AD Evaluation::External Party from AD Evaluation by Alex Zinin |
2004-11-02
|
12 | Alex Zinin | [Note]: 'Waiting for supporting docs' added by Alex Zinin |
2004-10-27
|
11 | (System) | New version available: draft-ietf-pim-sm-v2-new-11.txt |
2004-10-14
|
12 | Alex Zinin | State Changes to AD Evaluation from Publication Requested by Alex Zinin |
2004-09-07
|
12 | Bill Fenner | State Changes to Publication Requested from AD is watching by Bill Fenner |
2004-09-07
|
12 | Bill Fenner | Mike requested publication. Since I am a co-author, I need to reassign this to Alex. |
2004-09-07
|
12 | Bill Fenner | Shepherding AD has been changed to Alex Zinin from Bill Fenner |
2004-08-03
|
12 | Bill Fenner | Just putting this into the tracker a little early; the WG is nearly ready to ask for publication. |
2004-08-03
|
12 | Bill Fenner | Draft Added by Bill Fenner in state AD is watching |
2004-07-20
|
10 | (System) | New version available: draft-ietf-pim-sm-v2-new-10.txt |
2004-02-17
|
09 | (System) | New version available: draft-ietf-pim-sm-v2-new-09.txt |
2003-10-02
|
08 | (System) | New version available: draft-ietf-pim-sm-v2-new-08.txt |
2003-03-06
|
07 | (System) | New version available: draft-ietf-pim-sm-v2-new-07.txt |
2002-12-11
|
06 | (System) | New version available: draft-ietf-pim-sm-v2-new-06.txt |
2002-03-07
|
05 | (System) | New version available: draft-ietf-pim-sm-v2-new-05.txt |
2001-11-29
|
04 | (System) | New version available: draft-ietf-pim-sm-v2-new-04.txt |
2001-07-26
|
03 | (System) | New version available: draft-ietf-pim-sm-v2-new-03.txt |
2001-03-07
|
02 | (System) | New version available: draft-ietf-pim-sm-v2-new-02.txt |
2000-11-30
|
01 | (System) | New version available: draft-ietf-pim-sm-v2-new-01.txt |
2000-07-17
|
00 | (System) | New version available: draft-ietf-pim-sm-v2-new-00.txt |