Standard Communication with Network Elements
charter-ietf-scone-02
Yes
Zaheduzzaman Sarker
No Objection
Francesca Palombini
Jim Guichard
Paul Wouters
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Zaheduzzaman Sarker
Yes
Erik Kline
No Objection
Comment
(2024-10-02 for -00-00)
Not sent
## 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.
Francesca Palombini
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment
(2024-10-02 for -00-00)
Sent
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.
Murray Kucherawy
No Objection
Comment
(2024-10-02 for -00-00)
Sent
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.
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment
(2024-10-02 for -00-00)
Sent
** 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.
Éric Vyncke
No Objection
Comment
(2024-10-02 for -00-00)
Sent
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/