Hi, Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline).
I’ll try to address them all - but there are a two technical questions in this email that made me stop, so I’ll cut all the editorial stuff away and discuss them here - in line below: > - Why do this??? - Isn't it better to set flow labels per interface or for > the whole stack, how can any specific transport or application pick unique > labels? > TEXT: > > o Specify IPv6 flow label field > > Protocols: SCTP > > (i.e., Is this automatable by the host and a host wide > configuration?) Somehow the question seems irrelevant in the context of this draft, which is a list of transport features of protocols. These features are defined in the RFCs spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here. We can discuss this for the proposed services that a system should offer, which we try to write up in the minset draft: I do think that an application should be allowed to assign a label to a TAPS flow (as we call them), which could then map to this function. I mean, isn’t a flow label supposed to identify a transport flow? Then a system-wide configuration wouldn't seem right to me. > ------------------- > Get Interface MTU is missing from pass 2 and 3: > > ADD to pass 2: > > GET_INTERFACE_MTU.UDP: > Pass 1 primitive: GET_INTERFACE_MTU > Returns: Maximum datagram size (bytes) But this doesn’t exist! It’s strictly an IP function and I couldn’t find it described for UDP anywhere. I think we agreed on how a TAPS system should handle this, and this is reflected in https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1 … which may require a system to implement new local functionality, maybe based on this MTU function - but to my understanding it’s just not something that UDP offers. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
