Subject: [Gen-art] GenART review of draft-ietf-sigtran-rfc3332bis-05.txt

From: [email-masked]
Date: Mon, 28 Nov 2005 14:26:30 -0500

This draft is ready for publication as a Proposed Standard RFC

The -04 version of this draft was GenART reviewed for IETF Last Call.
That review is forwarded below.  With the exception of splitting of
figures across pages (which the RFC Editor can readily deal with),
the concerns raised by that review have been adequately addressed
in the -05 version.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Black, David 
> Sent: Wednesday, July 27, 2005 7:20 PM
> To: [email-masked]'; [email-masked]'; 
> [email-masked]
> Cc: Black, David; [email-masked]
> Subject: GenART review of draft-ietf-sigtran-rfc3332bis-04.txt
> 
> Background for those 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 included.
> 
> This review was done as part of IETF Last Call.
> 
> Review criteria for WG submissions: "Is this document a reasonable
> contribution to the area of Internet engineering which it covers? If
> not, what changes would make it so?"
> 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> 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.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 

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