Thanks Fernando,
I'll respond at the end of week (together with any other
comments I
receive).
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,
>
|
