[Ballot comment]
Initially, I put a DISCUSS-DISCUSS because I was missing some information to correctly review the draft (This was advised by Ron Bonica). Discussing with Wes Eddy off line, maybe I should have put "Defer". Anyway, sorry for the confusion. Now that I had a 1:1 with Eddy, many points are clarified, and here is my feedback.

- One of my confusion reading the draft was that I was missing the link with RFC3168. After a conf. call with Wes Eddy, I understand that your plan is to use an IPv6 destination option, and that RFC3168 is a very not required (but might be used, if I read http://tools.ietf.org/html/draft-ietf-conex-abstract-mech-03#section-3 correctly). It would be nice to say a few words about this in the draft.

- From the charter:

The purpose of the CONEX working group is to develop a mechanism
by which senders inform the network about the congestion encountered
by previous packets on the same flow.

Question about how to do define the notion of flow inside the IP layer?
I see an IPv6 destination option in http://tools.ietf.org/html/draft-ietf-conex-destopt-02, but I don't see any encoding for a flow in there?

- Section 1, Introduction
As described in Figure 1, congestion control currently relies on the transport receiver detecting these 'Congestion Signals' and informing the transport sender in 'Congestion Feedback Signals.'

Do you always assume that, because you receive a congestion signals for a specific TCP session, the congestion is for this entire session? I see more and more cases for which a router does a Deep Packet Inspection, and treat applications differently, as opposed to the 5 tuple. Is this a use case for CONEX? Without a DPI engine on the sender, I don't see how this could work...

- What is happening in case of ECMP? One router is congested, and not the other one. Is the CONEX enabled sender clever enough to mark only the affected flow (based on the 5 tuple)?

- Following on the two previous points, I would like to see the issues/limitations documented.
Issue 1: one round trip late
Issue 2: the congested device MUST support CONEX. The Sender MUST support CONEX
Issue 3: DPI engine must be supported on the sender, if we want to differentiate per application
Issue 4: ECMP (if this is one)
Issue 5: not UDP
etc..
From there, the use cases are limited. I see one though: managed services, bought by an enterprise customer, out of a single service provider

- Section 2.3

"rest-of-path
congestion" (also known as "downstream congestion") is the level of
congestion that a traffic flow is expected to experience between the
measurement point and its final destination.

What is a flow? The draft doesn't tell if the congestion is at layer 3, layer 4 or layer 7.

In contrast,
the ConEx signals inserted into IP headers as shown in Figure 1
indicate the congestion along a whole path from source to
destination.

source and destination what? IP addresses, or IP address/protocol/ports, or maybe IP address/protocol/ports/session id.
That's a key question in my mind.

Same remark in section 2.4, what is user's traffic

Congestion: In general, congestion occurs when any user's traffic
suffers loss, ECN marking, or increased delay as a result of one
or more network resources becoming overloaded.

- Section 2.4 definitions
You define congestion here, while section 2.1 already defines congestion

The definition used for the purposes of ConEx is expressed as the
probability of packet loss (or the probability of packet marking if
ECN is in use). This definition focuses on how congestion is
measured, rather than describing congestion as a condition or state.

- Section 3.1

By
deploying a congestion policer at the BRAS location, the network
operator can measure the congestion-volume created by users within
the access nodes and police misbehaving users before their traffic
affects others on the access network.

My issue (again) with this use case, is if the BRAS sees a high congestion-volume ratio, it will police all traffic from that users.
However, that users might at the same time be part of a webex call (voice + video), doing a backup, and downloading with P2P.
And the flow/session/application (to be clarified) you want to slowdown are the P2P, then then backup, and not the webex.

- 6. Security.
Am I able to send a message (from my own IP address) with an IPv6 destination option containing the IP address of my neighbor, so that his packets are slowed down, and I can benefit from the full cable infrastructure? Seems like an important question...