Subject: [Gen-art] Gen-Art review of draft-ietf-pim-sm-v2-new-11.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 27 Sep 2005 06:03:39 +0800

Background for those on the CC list, who may be unaware of GenART:
GenART is the Area Review Team for the General Area of the IETF.  We
advise the General Area Director (i.e. the IETF/IESG chair) by providing
more in depth reviews than he could do himself of documents that come up
for final decision in IESG telechat.  I was selected as the GenART
member to review this document.  Below is my review, which was written
specifically with an eye to the GenART process, but since I believe that
it will be useful to have these comments more widely distributed, others
outside the GenART group are being copied.

My apologies for a late last-call review - I hope this is still helpful
(before the document hits the telechat calendar).

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 :-) 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art