Re: Feedback on your serv codes draft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux