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 > [email protected] > https://www.ietf.org/mailman/listinfo/taps > Thanks Dale, Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
