Telechat Review of draft-ietf-taps-transports-usage-udp-06
review-ietf-taps-transports-usage-udp-06-genart-telechat-dupont-2017-09-14-01

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-taps-transports-usage-udp-06.txt
Reviewer: Francis Dupont
Review Date: 2017-09-14
IETF LC End Date: done
IESG Telechat date: 2017-09-14

Summary: In the Right Track

Major issues: None

Minor issues:
 - SO_REUSEADDR and SO_REUSEPORT descriptionss are incorrect (see below).
   BTW they are in the introduction so it is very minor but incorrect
   (or misinterpreted to stay polite) definition of SO_REUSEADDR made
   enough damage to want to stop it.

Nits/editorial comments:
 - TOC page 2 and 4 page 12: Acknowledgements -> Acknowledgements???
  (according to ispell with the US dict. I tried the GB one too
   and it gave less errors so now I assume you'd like to keep the
   spelling from this side of the ocean :-).

 - 1 page 2: The de facto standard: usually IEEE acts by delegation
  of the ISO so it can be in fact "de jure". I suggest to remove the
  "de facto" which can only bring useless (and unrelated) arguments...

 - 1 page 3: The SO_REUSEADDR description is fully wrong:
   this socket option is about conflicts (formal definition
   a conflict happens when a received packet matches more than one
   socket, in practice as CONNECT does an implicit (and conflict free)
   BIND it is only for BIND so local address *and* port with the same
   port, and equal addresses or an address being any/wildcard).
   Only the SO_REUSEADDR set to 0/no is really defined: the call
   to BIND by the second socket fails. The behavior on 1/yes is
   to fail if the conflict can't be solved (same addresses) in BSDs
   and derived system, and to never fail (i.e., the conflict detection
   is disabled) on Linux.
   I propose to change:
   o  SO_REUSEADDR specifies the rules for validating addresses supplied
      to bind() should allow reuse of local addresses.

   into

   o  SO_REUSEADDR specifies the rules for validating addresses supplied
      to bind() should allow conflicts on reuse of local addresses and
      ports.

  - 1 page 3: SO_REUSEPORT is a very different beast which unfortunately
    got a (far too) close name. I know at least 4 cases:
     * no defined in system headers
     * defined as being an alias of SO_REUSEADDR
     * defined but not supported (silly isn't it? but there is a popular
       system doing exactly this!)
     * defined using the original/BSD behavior: this socket option
    is for multicast applications and means received packets must be
    duplicated and delivered to all "matching" applications which
    must set to 1 the option (another difference with SO_REUSEADDR where
    the first application is not required to set it).

    I have no good proposal, perhaps the best is to move it to the
    multicast annex. BTW if you need a good reference (and a source
    of good text about SO_REUSE*) I highly recommend the Stevens book
    (not the API one by the "TCP/IP Illustrated volue 2", in my copy
    it is in PCB chapter page 720.

  - 1 page 3: I disagree about raw sockets: you must insist on
    the fact a raw socket bound to the known UDP protocol is able
    to *only* send packets, *never* to receive packets which are
    demultiplexed to the UDP protocol handler.

  - 1 page 3: insert a space in "in[I-D.ietf-taps-t...]"

  - 2 pages 3 and 4: I have a concern with the wording about
    the use of RFC 2119 words. In fact this document never uses
    directly these words but cites fragments of reference(d) RFCs
    which use them. So IMHO the "but does not itself define new terms."
    should be improved.

  - 3 page 4: "datagram services that preserve message boundaries."
    IMHO it is a pleonasm. I'd prefer to get connectionless in place
    of "preserve message boundaries" even it can be considered as
    a (common :-) pleonasm too. BTW the author of the "datagram" term
    is still on the Internet so you can ask him...

  - 3 page 4: summarizes -> summarises

  - 3.1 pages 5 and 8 (SET_DF, GET_MMS_S): packetization -> packetisation
    (and Packetization -> Packetisation)

  - 3.1 page 6: the LISTEN primitive is not defined for UDP. IMHO
    it is more a wording issue than a defect, i.e., you know (and state?)
    that the CONNECT primitive must be used instead (note I wrote must,
    not should, cf the question mark).

  - 3.1.1 page 9 (GET_TTL, SET_MIN_TTL) and A page 17 (IP_MULTICAST_TTL):
    Generalized -> Generalised

  - 3.1.1 page 11: I believe the GET_SRCADDR is excluded because it is
    available in the RECEIVE (recvfrom()/recvmsg()) primitive so
    no longer a primitive, isn't it?  

  - A page 19: you have twice MCAST_LEAVE_GROUP: this looks like
    a bad cut & paste, i.e., there is a missing SOURCE.

Two other points: I'll send your draft to my ISC colleagues as
the bind DNS server could be a significant source of UDP traffic over
the Internet. And if you have no Microsoft/Winsock person in
reviewers I recommend to contact one as if it is POSIX API it can have
interesting/to-notice difference.

Regards

Francis.Dupont@fdupont.fr