Draft:  draft-ietf-sigtran-rfc3332bis-04.txt
Reviewer: Black_David@emc.com
Review Date: Wednesday 7/27/2005 6:20 PM CST
LC Date: 28 July 2005

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Review:
-------
The draft is clearly written for an expert audience - significant
knowledge of SS7 is required to understand what is going on.  I
don't have that knowledge, but since this is a -bis draft of
an existing RFC with only minor changes, the basic protocol clearly
works.  Here's what I noticed in reading the draft.

Section 1.3.2.1's discussion of SS7's 272 octet limit not always
being applicable to this protocol raises the question of how to
determine whether it's applicable and what to do about it.  I
suspect the answer is roughly "anyone configuring SS7 needs
to know what they're doing, amateurs need not apply", but
something like that should be stated.

The SEP and STP acronyms are used (1.3.2, 1.4.1) before they're
defined (1.4.3.1).  They should be added to the terminology section.

Section 1.4.6 discusses "Congestion Management" without defining
what "congestion" is.  I suspect the default assumption that it's
similar to the SCTP and TCP notions of congestion is probably
wrong, as Section 3.4.4 points off to references 7 and 8 to define
congestion levels.  A brief discussion of what "congestion" means
in an SS7 context should be added to Section 1.4.6 .

The diagram in Section 1.5.3 (and a few others elsewhere) was split
by a page boundary.

Section 1.6 could really use a diagram showing where the boundaries
are before diving into the detailed definitions of what happens at
the boundaries.

Section 3 does not provide for experimental or private use codepoints.
If this is a deliberate decision, the reason for that should be stated.

Section 3.2 - how is definition of additional parameters handled?
A sentence saying that an RFC is required would suffice.