Skip to main content

Telechat Review of draft-ietf-ippm-tcp-throughput-tm-

Request Review of draft-ietf-ippm-tcp-throughput-tm
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2011-05-10
Requested 2011-04-21
Authors Reinhard Schrage , Gilles Forget , Ruediger Geib , Barry Constantine
Draft last updated 2011-04-30
Completed reviews Secdir Telechat review of -?? by Hilarie Orman
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-ippm-tcp-throughput-tm-secdir-telechat-orman-2011-04-30
Completed 2011-04-30
Security review of draft-ietf-ippm-tcp-throughput-tm-12.txt

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors. Document editors and
WG chairs should treat these comments just like any other review

From the document Intro:
   This framework recommends a methodology for measuring TCP
   Throughput in order to provide meaningful results with respect to
   user experience.

I had a little bit of trouble understanding the purpose of the
document, having stumbled across these two statements which when
juxtaposed, seem to contradict one another:

  Note that the primary focus of this methodology is managed business 
  class IP networks; i.e. those Ethernet terminated services for which 
  organizations are provided an SLA from the network provider.  Because 
  of the SLA, the expectation is that the TCP Throughput should achieve
  the guaranteed bandwidth.  


  2. Scope and Goals
     - This methodology is not intended to measure TCP Throughput as part 
     of an SLA

[Remember the New Yorker magazine's "Our Forgetful Authors"?]

It is difficult to frame the security requirements for a measurement
framework, and this document does not try:

  6. Security Considerations

     The security considerations that apply to any active measurement of
     live networks are relevant here as well.  See [RFC4656] and

I am not sure what to infer from this statement.  That the RFCs define
all possible security requirements and considerations?  That their
definitions coincide with what the authors of the current document
recommend?  That the solutions defined by the other RFCs SHOULD be
be part of the framework defined by the current document?  MAY?  It

It's my recommendation that the security considerations be expanded
to explicitly list the security requirements for the framework.