Eddie Kohler wrote:
Gorry Fairhurst wrote:
Eddie Kohler wrote:
<snip>
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."
"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."?
"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 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?).
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.
and (2) only the client generates data", would be OK.
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.
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
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.
E
E
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
