Thanks Fernando,
I'll respond at the end of week,
Gorry
Fernando Gont wrote:
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.
* 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).
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/)
Page 2, bottom:
" Copyright Statement....................Error! Bookmark not defined. "
Looks like an error produced by the tool you used to create the draft.
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)
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)
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/
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?
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. "
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?
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)
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).
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/
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".
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?
Hope they are useful.
Kindest regards,
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
