See in-line, Gorry
> Hi Gorry, > > Thank you very much for your feedback. > We will add what you point out that we have missed in Section 3. > > Some more comments in-line. > > On 26 Jun 2015, at 11:21, [email protected] wrote: > >> >> Thanks for submitting this. I like the idea of trying to get a handle on >> the minimal transport services that TAPS can support. >> >> Detailed comments on: >> https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >> >> In Section 1: >> >> I think the word "non-functional" is a little awkward, since it suggests >> "dysfunctional" and we probably should seek a different word for >> clarity. > > You are the english speaking person her, so you are probably right. > However “non-functional” has a technical meaning in software design, and > that is what I > meant here. See e.g.. > https://en.wikipedia.org/wiki/Functional_requirement > Yes I see this use, but still wonder if this is the best word. >> >> In Section 3: >> >> My initial comments are on the list of features (this may have to be fed >> back to the 1st TAPS ID, but it is more clear here at the moment, so >> I'll >> comment here and see what people think: >> >> o unicast: TCP SCTP UDP-Lite DCCP NORM >> - Add UDP-Lite >> >> o IPv6 multicast and anycast: UDP >> - Add UDP-Lite >> >> o multicast: NORM >> - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as >> non-reliable) > > I am not sure what you mean here. Does not NORM implement multicast? > There is no statement about it being reliable or not (but may be it > should?) > What I intended to say was: The set of transports supporting multicast IPv4 or IPv6 is {UDP, UDP-Lite, NORM} And hence NORM supports this over UDP, and adds reliability (in various forms). >> >> o unidirectional: UDP >> - Add UDP-Lite >> >> o bidirectional: TCP >> - Add DCCP, SCTP >> >> o IPv6 jumbograms: UDP >> - Add UDP-Lite >> >> o 2-tuple endpoints: UDP >> - Add UDP-Lite >> >> o error detection (checksum): TCP UDP >> - Add UDP-Lite, DCCP >> >> o error detection (UDP checksum): NORM >> -??? I see this is via UDP, but is it a real difference, NORM is only >> specified over UDP > > Yes, so if we want to include NORM (or may be we should not in the initial > minimal version?) > then we must include that it supports error detection as in UDP (?). > Yes - NORM is over UDP, and hence I think its error *detection* model is the same as UDP. >> >> o strong error detection (CRC32C): SCTP >> - Possible with TCP option, or AUTH or TLS (and possible with >> UDP/UDP-Lite/DCCP using DTLS >> >> o congestion control: TCP SCTP NORM >> - Add DCCP >> >> o no congestion control: UDP >> - Add UDP-Lite >> >> On section 4 >> >> I can offer more comments later, but initially I just note that I think >> the Service Code in DCCP *IS* specified by the Application in the same >> way >> that the port is chosen. > > OK, so we have to include this. > > Cheers, > Stein > >> >> Gorry >> >> >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
