Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements
RFC 7713

Note: This ballot was opened for revision 13 and is now closed.

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Alissa Cooper) No Objection

Comment (2014-12-03)
No email
send info
= Section 2 =
"This document extends the capabilities of the Internet protocol suite
   with the addition of a new Congestion Exposure signal."

This document doesn't do that, right? Maybe one of the standards-track conex documents will, but this document does not directly affect the Internet protocol suite.

"ConEx represents a recognition that the
   IETF cannot regulate this space directly because it concerns the
   behaviour of users and applications, not individual transport

I'm not sure what "ConEx represents" means here, but no matter which way I interpret it I have a hard time getting to the conclusion that this sentence makes. I would recommend that this sentence and the one that follows it focus on the implications of the abstract mechanism described in this document, rather than on what the IETF does or does not do.

= Section 4.4 =
"As long as the packets in a flow have uniform sizes, it does not
   matter whether the units of congestion are packets or bytes.
   However, if an application sends very irregular packet sizes, it may
   be necessary for the sender to mark multiple packets to avoid being
   in technical violation of an audit function measuring in bytes (see
   Section 4.6)."

This makes me wonder how the sender is supposed to know whether an audit function at any given point on the network is counting in bytes or in packets, or what happens if the same packet/sender encounters audit functions on two different networks (in a single path, or in a multi-homed sender scenario) that count using different units. The requirement in Section 4.6 that the encoding scheme specify its assumption about units isn't sufficient, because packets that use the scheme could encounter an audit function that makes the opposite assumption. Is this addressed somewhere?

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-12-04)
No email
send info
I am glad for the existence of this document. Thanks for taking the time
to write it.

Alissa's first comment needs to be addressed.

(Stephen Farrell) No Objection

Comment (2014-12-04)
No email
send info
(Apologies, I only had time to skim this one, so
my comments might be a bit off the mark - feel
free to tell me I'm being dumb if so:-)

- The IPR declaration says licensing is to be provided
"later" though a note in fact does seem to contain a
(nice) set of terms. Might be good to fix?

- Could conex signals be used as part of an oracle
attack? I'm not sure they could but has someone
thought about that? If not, and if there were a way in
which to abuse conex along those lines then it could
be that stating a requirement that specific protocols
consider this would be a good idea. Note that I'm not
sure if a feasible way to use conex in such an attack
exists. If it did, a simple countermeasure might be to
just not allow for very fine-grained signals.

- It'd be good if the security considerations here
considered how more and more use of ciphertext might
affect conex, in particular for the proxy or audit
functionality. For example, is there any interplay
with what tcpinc is likely to produce?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

Comment (2014-11-22)
No email
send info
I submit that a good number of the references really are normative, in that understanding them is necessary in order to understand this document.  I'd like to see the authors sort that out, and make an appropriate split in the references, so readers can know which ones truly do just add extra detail (informative), and which provide necessary background (normative).  That said, I don't consider that important enough to this document to block on it, so this is a non-blocking comment.  Please consider doing this, but there is no need to respond to me about it.  Thanks.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-12-03)
No email
send info
Thanks for your response and agreed changes per the SecDir review.

The draft looks good, thanks for your work on it and the detail level for security requirements like the specific requirements to protect against several attacks that may lead to a DoS in section 3.2 Audit.  

I found the first paragraph of 5.4 helpful to better understand what was intended by the term audit and think it would have been good to have that understanding a little earlier in the draft.  I was looking for possible security concerns that don't apply once I read this definition.