Thanks for your comments.
Please see comments and questions in-line, all thoughts welcome. When we
conclude these issues, I'll post a revised I-D.
Best wishes,
Gorry
Gorry,
* General comment:
The draft argues that services codes allow the decoupling of service
identification from demultiplexing. However, skimming through section
8.1.2 of the DCCP spec, I get the impression that service codes
provide sort of a second-level demultiplexing mechanism. That is,
packets are first demultiplexed based on the port number. If there is
an app listening on that port, *then* the request is demultiplexed
based on the service code. If I am right, then I'm not sure I'd say
that the service identification and demultiplex functions are
actually decoupled.
That is a key point of debate, and one that I'd welcome feedabck. Note
that when the Spec was made, this was simply a proposal. I believe it's
now up to the group to figure out how this will be realised.
In the intervening time, there been some thinking on demultiplexing, this
creates some new opportunities, related thinking is e.g.
Joe Touch's I-D on TCP (cited) which has suggested an alternate approaach.
So, I'd be open to updating DCCP on this, especially if we can a
transition mechanism that allows both an "old-style" ports and
a "new-style" more flexible approach.
I'm really interested in other thoughts on this!
* Editorial
Page 1, Abstract:
" This document describes the usage of Service Codes by the Datagram
Congestion Control Protocol, RFC 4340."
IIRC, you should not provide references in the Abstract. So I'd
probably delete "RFC 4340" (even when it's not linked to the
References section).
My understanding was that it's ok to mention an RFC by number, but not by
citation.
Page 1, Abstract:
"The DCCP
Service Code can also enable more explicit coordination of services
behind NATs and firewalls."
s/enable/enables/ (or s/Code/Codes/)
Changed:
The use of a DCCP Service Code can also enable more explicit coordination
of services behind NATs and firewalls.
Page 2, bottom:
" Copyright Statement....................Error! Bookmark not defined. "
Looks like an error produced by the tool you used to create the draft.
Now Fixed.
Page 3:
" The use of Service Codes can assist in identifying the correct
intended service when the server is located behind a NAT that
modifies the port numbers associated with a flow. "
You may want to provide a reference for the term NAT (not sure what
the appropriate RFC number should be)
OK, I suggest:
a NAT [RFC2663], [RFC2766]
Page 5, Section 2:
"Section 3 describes the use of Service Codes by end hosts and
network middleboxes. "
s/end hosts/hosts" (or s/end hosts/end systems/) (there are other
instances of this)
Looking at other RFCs, the term "end host" is not uncommon, but I am
happy to move to "host" if that eases readability. Done.
Page 5, Section 2.1:
" Like DCCP, most Internet Transport Protocols (e.g. TCP [RFC793], UDP
[RFC768]) also define publicly-known ports for most services, whether "
s/Transport Protocols/transport protocols/
Fixed!
Page 5, Section 2.1:
Like DCCP, most Internet Transport Protocols (e.g. TCP [RFC793], UDP
[RFC768]) also define publicly-known ports for most services, whether
intended for public access (e.g., telnet, DNS) or for services
typically used between pre-arranged pairs (e.g., X11, SSL).
Did you mean SSH instead of SSL?
Yes, fixed.
Page 6, first para:
"Such methods
may also be applicable to IETF-defined transport protocols, including
DCCP. "
Maybe re-phrase it as: > "Such methods
may also be applicable to other IETF-defined transport protocols,
including
DCCP. "
Changed to:
/It has been suggested that a randomized choice of port number value can
help defend against "blind" attacks [ID.TSVWG.RAND] in TCP. Such methods
may be applicable to other IETF-defined transport protocols, including
DCCP./
Page 6, Section 2.2:
" DCCP specifies a 4 byte Service Code [RFC4340]. Service codes may be
represented in one of three forms: as a decimal number (the canonical
method), as a 4 character ASCII string, or as a hexadecimal number. "
Should it be "an hexadecimal number" (i.e., s/a/an/) instead?
"an hex..." reads odd, I think it's wider to avoid this.
I suggest:
/in one of three forms as: a decimal number (the canonical method), a four
character ASCII string, or an eight digit hexadecimal number. /
Page 7, Section 2.7:
" The set of Service Codes currently specified for use within the
general Internet are defined in an IANA-controlled name space."
I'd s/general Internet/Internet/ (or s/general/global/). (there is
another instance of this in Section 6)
I haven't changed this, the term "general Internet" is a subtle difference
to "global Internet", and has been used before in RFCs.
Page 9, Section 3.4:
"This operation could resemble that of "portmapper" or "inetd". "
I'd just mention inetd. Portmapper is directory service. It resolves
"service names" into "port numbers" (IIRC).
Yes, exactly, I was imaging something more like portmapper that had a
database of "service names" (aka codes) that could operate as a daemon.
Are there better words for this?
Page 11, Section 4.2:
"Such a system needs
however also MUST provide a way to allow a sending and/or receiving
application to bind to a none-default Service Code (specified by the
application)."
s/none-default/non-default/
Done:
/bind to a non-default Service Code/
Page 12, Section 5:
" o Extend the existing port number indicator command (e.g., Unix
bind() or connect() calls) to select a specific port number where
desired. "
The last instance of the term "port number" should be replaced with
"service code".
True! Corrected!
/ to also select a specific Service Code where desired./
Page 16, Section 9.2:
|0x50455246| PERF |5001| Performance tests (e.g. | * |
| | | | iperf, ttcp, ...) | |
Maybe a port could be assigned to performance tests, and the service
code could identify the specific tool/service for actually assessing
performance?
Not sure I understand this, please say more.
In the "4.2. Standard Support" case receivers demux based only on port,
so these simplest receivers would have no way of associating these sessions with the app
except by using the service code.
However this is permitted in the method in 4.3.
-----
As an aside on this point it would be good to define a specific service
code that could be used to diagnose the demux/association problem, and
identify if a remote server may determine application based on service
code (even when another service is listening on the same port),
i.e. perhaps we could define a set of two service codes specifically
allocated to the same port, but designed to contact different servers,
e.g.
ECHS on port 7 - e.g. which could return a non RFC862 repsonse?
Is this cool, stupod, helpful or silly?
Hope they are useful.
Kindest regards,
--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
