Draft: draft-ietf-pim-sm-v2-new-11.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Monday 9/26/2005 5:04 PM CST LC Date: Sept 06, 2005 Summary: This document is in good shape. Most of my comments are requests for clarifications and expansions. Re: "ready for publication as Proposed Standard" - I am also reviewing draft-ietf-pim-proposed-req-01.txt, and noticed the following - I reported it in the other review, but the authors of this draft probably are interested as well :-) One fairly serious question - I assume that RFC 1264 applies in this case (routing protocol going for proposed standard), which says (in Section 3.0), 5) There must be evidence that all features of the protocol have been tested, running between at least two implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection. I'm not sure the statements in Section 2.5 of draft-ietf-pim-proposed-req-01.txt for Cisco and Procket qualify as "all features of the protocol have been tested". I'm deferring to the ADs on this one, but didn't want the protocol spec authors left in the dark. "Otherwise, no problem" :-( 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? If it wasn't IETF last call time, I wish that the many repetitive parts of this spec, which deals with cases that are "almost identical", could be parsed out as an initial case, plus later cases focused on what was different - but that's not a reasonable IETF last call comment. Maybe next time :-)