Thanks Tom,
See in-line for responses to your review comments. I have prepared a new
draft that incorporates these chnages, and those previously suggested in
Eddie's emails. If you are happy with these changes, I'll post the new
draft to the archive.
Are there any more comments from the WG?
Gorry
Phelan, Tom wrote:
Hi Gorry,
Here are some comments, some editorial and some technical, in the order
that I encountered them.
Tom P.
Abstract (editorial):
"It motivates the setting of a Service Code by applications." I don't
understand this sentence -- does it mean "It describes the motivations
for setting..."? At any rate, I think the abstract is better is that
sentence is just eliminated.
I have removed this.
Also the last sentence "It updates...", what "it" refers to is a little
ambiguous -- how about "This document updates...".
See below.
NEW:
This specification updates RFC 4340.
Section 2.1, last paragraph (editorial):
"providing that both client and server agree the port value to be used."
How about "providing that both client and server agree *on* the port
value to be used."?
Your change seems good to me.
NEW:
and server agree on the port value to be used
Section 2.5 (technical):
Implementations MUST NOT accept a DCCP-Request with" as the
service code -- do we need to specify what "not accept" means -- silent
discard, send a reset (with what reason code)? I'll accept leaving this
as it is, but think we should at least discuss it first :-).
I'd suggest reset is the correct response in RFC4340, and leave 43040 to
specify code?
NEW:
Implementations MUST NOT accept a DCCP-Request with this value and MUST
respond with a DCCP-Reset message [RFC4340]. Implementations SHOULD NOT
allow applications to bind to this Service Code value [RFC4340].
Section 3.2 (technical):
We need to be careful that the requirements in the bullets are
compatible with Remi's behave draft. I see you mention that in your
response to Eddie's comments...
I've added the reference at appropriate points. I did not find a
contradiction in section 8.2 that deals with SC usage.
I added a ref in 3.2:
NEW:
Network address and port translators, known collectively as NATs
[RFC2663], may interpret DCCP ports [RFC2993] [ID.Behave-DCCP].
I also updated bullet 2 to explicitly refer to this:
NEW:
o A middlebox that does not modify the intended application (e.g. NATs
[ID.Behave-DCCP] and Firewalls), MUST NOT change the Service Code.
I have currently made this a normative reference - since this is a PS
that speaks of a specific mechanism that is important for SC use and
dedicated to DCCP, but I could make it informative if you think this
better reflects the citation.
Section 3.3.1 (mostly editorial, but maybe technical):
"If the receiving host is listening on a server port and the
DCCP-Request uses a Service Code previously associated with the port" --
Would "uses a Service Code *currently* associated with the port" be
clearer? The current wording seems to suggest that any SC that was ever
associated with a port is OK.
Aha, I now suggest:
OLD:
uses a Service Code currently associated
NEW:
uses a Service Code that has been associated
Section 3.3.2 (technical):
Does this section actually say anything beside what RFC 4340 says? And
by doing this does it conflict with section 3.2 (and implementation
SHOULD allow multiple SCs on a port)? It seems to me that this section
could be eliminated, but if kept it should re-mention the change to
SHOULD.
It was meant to describe the action of the application, so this really
should not have been a keyword. It is not intended to update RFC4340.
Well spotted. I propose:
NEW:
RFC4340 states that a single passively opened (listening) port can be
associated with multiple Service Codes, although an active (open)
connection can only be associated with a single Service Code.
Section 3.3.3 (technical):
So what should be the identifier in dccp-inetd? Just a port or just an
SC or a port and an SC (the last, for my thinking)? I think that should
be specified here. I think you try to specify this in the last
paragraph, but it seems unclear to me.
OK, well spotted - this is vague, but intentional. I hedged away from
detail on the inetd discussion (after various iterations with Eddie and
Mark). I do not have much to say from the OS point of view - I guess I
was thinking of driving this from some of file/database with SC and port.
Security considerations (editorial):
The summary of the section should include an item 5 on the benchmarking
services.
I added this.
-----Original Message-----
From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
Of
Phelan, Tom
Sent: Monday, August 25, 2008 9:44 AM
To: dccp >> 'dccp' working group
Subject: Working group last call for service codes
Hi All,
This is to announce the beginning of working group last call for "The
DCCP Service Code", draft-ietf-dccp-serv-codes-06.txt (see
http://www.ietf.org/internet-drafts/draft-ietf-dccp-serv-codes-06.txt).
Last call will run for two weeks, ending Monday, 8-Sep.
Please send detailed comments to the list. Also, bare "I support" or
"I
don't support" e-mails are quite useful.
Tom P.
