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. Also the last sentence "It updates...", what "it" refers to is a little ambiguous -- how about "This document updates...". 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."? Section 2.5 (technical): Implementations MUST NOT accept a DCCP-Request with" 0xffffffff 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 :-). 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... 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. 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. 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. Security considerations (editorial): The summary of the section should include an item 5 on the benchmarking services. > -----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.
