Skip to main content

Last Call Review of draft-ietf-conex-abstract-mech-12
review-ietf-conex-abstract-mech-12-secdir-lc-eastlake-2014-09-04-00

Request Review of draft-ietf-conex-abstract-mech
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-08-08
Requested 2014-08-01
Authors Matt Mathis , Bob Briscoe
I-D last updated 2014-09-04
Completed reviews Genart Last Call review of -12 by Robert Sparks (diff)
Genart Telechat review of -13 by Robert Sparks
Secdir Last Call review of -12 by Donald E. Eastlake 3rd (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-conex-abstract-mech by Security Area Directorate Assigned
Reviewed revision 12 (document currently at 13)
Result Has nits
Completed 2014-09-04
review-ietf-conex-abstract-mech-12-secdir-lc-eastlake-2014-09-04-00
Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describe an abstract mechanism for senders to inform a
network about congestion encountered by packets over a flow by adding
ConEx (Congestion Exposure) Signals. It is part of a set of documents
for which the entry point is RFC 6789.

Security Considerations (Ready):

>From a security considerations point of view, I think this document is
Ready for publication. It correctly identifies the main security
considerations as the robustness of congestion marking and auditing so
that malefactors cannot gain advantage from cheating. While real
security details are necessarily deferred to specific ConEx
specifications, this abstract specification document in my opinion
does a good job of discussing, in general terms, the threats and a
number of strategies to defend against them.

Comment:

I found some of the wording to be a bit confusing. For example, the
first sentence in the abstract is as follows:
   "This document describes an abstract mechanism by which senders inform
   the network about the congestion encountered by packets earlier in
   the same flow."
and the first sentence of the Introduction is very similar. But, if I
understand Figure 1 correctly, what is abstractly specified is the
addition to data flowing from from A to B of information about
congestion encountered over the entire A to B path, not "earlier in
the same flow". Perhaps my understanding is confused, but that would
also indicate a lack of clarity.

Nits:

Section 2, bottom of page 4: "... to be able apply sufficient ..." ->
"... to be able to apply sufficient ...".

In a number of Sections there are what are, in effect, sub-heading
indicated by a word or two followed by a colon and then text indented
by three spaces. In some cases, this is used with no blank lines,
which is fine. However, in other cases this indented text is has
multiple paragraphs separated by a blank line. In most such instances,
there is also a blank line before each such "sub-heading", for example
Section 5.5. But not in Section 6, which looks odd in some places as a
result. I suggest having a blank line before such sub-headings in
Section 6.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com