Eddie Kohler wrote:
Gorry Fairhurst wrote:Eddie Kohler wrote:
<snip>
"Applications intended for deployment in the Internet are encouraged to use an IANA-defined Service Code. If no specific Service Code exists, they SHOULD request a new assignment for their protocols from the IANA."?If the application requires a new Service Code, one may either be chosen a value from the private range (Section 2.3), or a new Service Code may be requested from the IANA."Private Use range is intended for interim uses, before app gets a real SC from IANA. I wouldn't specifically recommend it. Last P: "Deployed applications requiring new Service Codes should request specific Service Code assignments for their protocols from the IANA."
I do not think we should make that judgment quite yet - at the moment it's helpful to me to know anything that clarifies/updates the operation (... we also may yet get more inputs, and debate?)."MUST" or "MUST NOT" doesn't make sense to me. I do not think this draft should revise RFC4340.I still think that "updating RFC4340" is not really what this doc is doing, so would cut the "This document updates", but am OK
I'm not sure. Let me think, and consult some people using perf tests for DCCP. I'll also note your comment in the draft.If you have several benchmarks in mind with incompatible headers, then add multiple registrations for them to this draft. Those registrations will act as guides for other developers. A catchall SC for "other undefined benchmarking programs", with a note about "Any particular benchmarking program that sends specifically formatted SHOULD allocate its own Service Code; this Service Code is intended for use by benchmarking programs where (1) the contents of any Data packet is meaningless,Seems good to me, updated text.But why this constraint No. (2)? - this seems odd: we could have a tool in which only the server sends data... one in which the client responds to each data packet with some response... They are all benchmarking.and (2) only the client generates data", would be OK.SC defines protocol; protocol constrains messages in both directions. If a benchmarking program generates one-way data, and the data has no meaningful format, that seems like a "protocol" description to me, and I can't imagine a middlebox meaningfully differentiating. If a benchmarking program DOES expect server replies, well, that is meaningfully different, and I can imagine a middlebox wanting to differentiate -- for example, by allowing one kind of perftest and not the other
EE
Gorry
It seems to me that we're now at the point where a new revision would be useful to capture all these edits, unless here more, I'll submit a new revision at the start of next week.
Gorry
