Eddie Kohler wrote:
<snip>
SC=0 allows Unix-like implementations to associate a valid Service Code
with every socket, without changing the procedure used for opening
sockets (i.e., without adding extra setsockopt calls or adding members
to struct sockaddr). Linux for a time used SC=0 this way; it may still
do. Linux could use a Private Use service code, such as SC=?LNX, to get
the same effect; an explicit service code for "no information about the
application" seems cleaner.
>
I am happy for the draft to say "SHOULD NOT use SC=0".
>
OK, I'm suggesting:
"A Service Code of zero is "permanently reserved (it represents the
absence of a meaningful Service Code)" [RFC 4340]. This indicates that
no application information was provided. RFC 4340 stated that
applications MAY be associated with this Service Code in the same way as
other Service Code values. This use is permitted for any server port.
This document updates section 19.8 of RFC 4340:
"Applications SHOULD NOT use a Service Code of zero.
Application writers that need a temporary Service Code value SHOULD
choose a value from the private range (Section 2.3).
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."
"MUST" or "MUST NOT" doesn't make sense to me.
I do not think this draft should revise RFC4340.
5.1
<snip>
That would seem to suggest to me, that knowing traffic was being used
for benchmarking would be better than using a private SC. Clearly one
separate SC for each performance tool/technique would also be
possible, although in this case, I wonder if there is anything "more"
in benchmarking headers that it would be worthwhile to parse.
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.
E
Gorry
