## Comments

### List of coordinating groups

* I wonder if it's possible to include soliciting feedback or review from
  some IRTF RGs, particularly HRPC RG.  The proposed mechanism(s) should
  not become the basis for any broader Internet censorship framework.

I suspect you may want to reword your non-goals a bit?

> Non-Goals
> This working group will not produce a solution that:
> 1. Looks inside a QUIC or TLS encryption envelope

That seems right. I expect that you genuinely want to exclude looking inside the encryption envelope.

> 2. Is appropriate for use as input to a congestion control algorithm

A literal reading of the above (the expansion being, “the working group will not produce a solution that is appropriate for use as input to a congestion control algorithm”) implies that if some clever soul figures out a way to use an otherwise acceptable solution as input to a congestion control algorithm, that solution MUST be discarded. I bet that’s not your intent.

> 3. Provides information other than the throughput advice

I’m not sure which category this one falls into. Maybe it’s an intentional hard prohibition on leaking information, for privacy reasons. Maybe it’s an accident like I describe in my preceding critique. In any case, please evaluate it.

In addition to John's and Roman's remarks (with which I agree), I think there are a few spots that could use some copy editing.  These aren't blockers at this phase but I think it will be important to tidy all this up before it gets approved for WG creation.  For instance:

OLD:
This WG aims to establish a mechanism for network elements capable of
rate-limiting a UDP 4-tuple to communicate an upper bound on achievable
bitrate termed "throughput advice" to the sender of packets matching
the UDP 4-tuple.

As I read this the first time, I thought you wanted to establish an upper bound on the throughput advice, but I think what you want is to establish an upper bound which you call throughput advice.  This can be clarified like so:

NEW #1:
This WG aims to establish a mechanism, called "throughput advice", for network elements
capable of rate-limiting a UDP 4-tuple in order to communicate an upper bound on achievable
bitrate to the sender of packets matching the UDP 4-tuple.

...or even more simply:

NEW #2:
This WG aims to establish a mechanism for network elements capable of
rate-limiting a UDP 4-tuple to communicate an upper bound on achievable
bitrate, termed "throughput advice", to the sender of packets matching
the UDP 4-tuple.

** For readability, can the forced line wrapping and line feeds producing a “double spaced” effect be removed from the charter text.

** Per “The working group will analyze the privacy and security implications of the mechanism”, what is this texting committing the WG to do?  Are there particular security guarantees or properties that can be stated now?

** Per “Develop standard protocol …”, what’s a _standard_ protocol?  Is this intending to say “specify a proposed standard …” (as in the status of the document in IETF process)?

** Per “Develop an Informational Applicability and Manageability specification”, what is an “informational applicability … specification”.  Is that an “informational” status document or something else?

** What topics would an “applicability specification” cover?  Is this document scoping the use of the protocol in some way”?

** Per “The WG will coordinate its work with owners of any APIs that use the ‘throughput advice’ to ensure that browser applications will be able to use SCONE protocol effectively”:

-- what does this coordination mean beyond trying to include the owners of the APIs in the standards process?  

-- not fully understanding the intent of this intended coordination, if browser applications are not able to use the SCONE protocol effectively, is the proposed design fit to purpose? 

** Please add milestones.

s/a mechanism for network elements *capable of rate-limiting a* UDP 4-tuple/a mechanism for network elements *enforcing a rate-limit for packets in a flow identified by* a UDP 4-tuple/