Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis
RFC 4602

$ 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.

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.

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.

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?

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.

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.