I'm reading parts of draft-fairhurst-taps-transports-usage-udp-01
because it was presented in the Dispatch session of the meeting, so I
don't have all the context for this draft. But a couple of comments
struck me:
The description seems to be connection-oriented, in that it only
describes usages involving two endpoints establishing a connection and
then using it. Indeed, even the process of establishing a listening
port based on which connections will be created is not described. E.g.,
the description of the CONNECT primitive says "The CONNECT primitive
allows the association of source and port sets to a socket ...", but
doesn't describe where the socket comes from, or that packets can arrive
on a socket before the receiver has done a CONNECT.
Perhaps these concepts are discussed in the document that establishes
the framework for this draft. At the least, the use of listening ports
needs to be formalized.
In section 3.1 is:
SET_IPV6_UNICAST_HOPS: The SET_IPV6_UNICAST_HOPS function sets the
hop limit field to be used in the field of an IPv4 header of a
packet that carries an UDP datagram. For IPv6 unicast datagrams,
this is functionally equivalent to the SET_TTL IPv4 function.
GET_IPV6_UNICAST_HOPS: The GET_IPV6_UNICAST_HOPS function reads the
value from the hop count field in the IPv6 header of a received
UDP datagram. For IPv6 unicast datagrams, this is functionally
equivalent to GET_TTL IPv4 function.
I might be wrong, but it looks like "IPv4" and "IPv6" are mistaken for
each other in three places in these items.
How does the application get notified that a packet has arrived? The
only event that is defined is ERROR_REPORT. The RECEIVE primitive is
called by the application, but application has to first know that there
is a packet to receive.
Dale
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
