Re: [Taps] Drive-by comments on draft-fairhurst-taps-transports-usage-udp-01

Thanks - appreciated.

> 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.
>
I agree - the current format from the text comes from the existing text 
for TCP and SCTP in another draft. and I think we  may need to work out
how to handle

> 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.
>
I probably need help - I think there are different many ways in which UDP
uses ports. Offers from anyone on how to get started would be great.

> 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.
>
Indeed. We will fix this.

> 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.
>
One contribution in the parallel TAPS meeting suggested the WG could use a
call-back API - that may be worth exploring.

> Dale
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>
Thanks Dale,

Gorry