Hi Micheal, this is only a personal opinion and I do not object to work on this doc.
Mija > Am 28.10.2015 um 09:05 schrieb Michael Welzl <mich...@ifi.uio.no>: > > Hi Mirja, > > I’m not sure where this discussion is leading us: twice you just say you > disagree without giving a reason; then you seem to get kind of hung up on the > “no congestion control” bit immediately after quoting my statement: > > ** > Thus, “no congestion control” becomes a part of the services. Because “lack > of XY” is a bit strange as a service, it’d be obvious to write “congestion > control” as a service for the other protocols instead. > ** > i.e. the service would be "congestion control”, not “no congestion control”. > The latter is just what you'd get in the first iteration when working through > the UDP usage guidelines. > > > I’ll cut most of the text here to try to wrap this up, then answer a > particular point, and then get to your conclusion: > > >> Further, back to your example above. To call „no congestion control“ a >> service you have to analyze the protocol itself. „no congestion control“ is >> not exposed in any interface!!! And analyzing the protocol is what we do in >> the taps-transport doc! > > No, you do *not* have to analyze the protocol, as this is not only about > interfaces, it’s based on any text in the RFCs that describes what a protocol > provides to the upper layer and how it is used. RFC 5405, as an obvious > source of text on how to use UDP and what it provides to the layer above, > tells us: > "It is important to stress > that an application SHOULD perform congestion control over all UDP > traffic it sends to a destination, independently from how it > generates this traffic." > > So, once we include UDP, we get congestion control as a service for TCP and > SCTP, from this text. > > >> When I was reading draft-well-taps-transports I’d had the feeding you’ve >> started with the interfaces but then detected that obvious things are >> missing, so you basically also started analyzing the protocols itself but >> very selectively and from my point of view even more arbitrary. > > That’s not what I did. I strictly used only text that talks about what a > protocol provides to the upper layer and how it is used. > > >> From my point of view, let's keep in mind all the discussion we had and what >> we learned to far, and let’s move on! > > Noting your statement from a previous email: "Again, I’m okay to have two > docs here. I don’t think a second doc is absolutely necessary. An alternative > would be to merge both docs… just as a side note. But I’m okay with both, two > or one docs.”, I agree and think we should just move on. > > Cheers, > Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
