Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis
Note: This ballot was opened for revision 02 and is now closed.
Alex Zinin Former IESG member
Yes () Unknown
Allison Mankin Former IESG member
Yes () Unknown
Bert Wijnen Former IESG member
(was No Record, No Objection) No Objection
No Objection (2005-10-25) Unknown
$ 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.
Brian Carpenter Former IESG member
No Objection (2005-10-24) Unknown
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 188.8.131.52, 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.
David Kessens Former IESG member
No Objection () Unknown
Jon Peterson Former IESG member
No Objection (2005-10-26) Unknown
Margaret Cullen Former IESG member
No Objection (2005-10-27) Unknown
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?
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2006-03-09) Unknown
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.
Sam Hartman Former IESG member
No Objection (2005-10-27) Unknown
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.
Scott Hollenbeck Former IESG member
(was Discuss) No Objection
No Objection () Unknown
Bill Fenner Former IESG member
Recuse () Unknown