You've specified this as if it were an individual property. You need to deal with sets of properties, perhaps including choices (A and B) or (A and C) but not (A and B and D)...
This is widely known as "constraint satisfaction", unsurprisingly. Joe On 7/23/2019 8:59 AM, Tommy Pauly wrote: > Hi Joe, > > Yes, I completely agree. The current text in -arch expresses this as: > > 2. Both stacks MUST offer the same transport services, as required > by the application. For example, if an application specifies > that it requires reliable transmission of data, then a Protocol > Stack using UDP without any reliability layer on top would not be > allowed to replace a Protocol Stack using TCP. However, if the > application does not require reliability, then a Protocol Stack > that adds unnecessary reliability might be allowed as an > equivalent Protocol Stack as long as it does not conflict with > any other application-requested properties. > > If you think we can clarify this any further, let me know! > > Thanks, > Tommy > >> On Jul 23, 2019, at 11:55 AM, Joe Touch <to...@strayalpha.com >> <mailto:to...@strayalpha.com>> wrote: >> >> >> >>> On Jul 23, 2019, at 8:19 AM, Theresa Enghardt >>> <ther...@inet.tu-berlin.de <mailto:ther...@inet.tu-berlin.de>> wrote: >>> >>> Another important difference between TCP and UDP are Message Boundaries. >>> So in some cases, TCP + Framer may be equivalent to UDP. >> >> FWIW, they might provide *similar* capabilities, even only those that >> the app is concerned about, but there are a LOT of other differences >> that can’t be glossed over. In some cases, it is TCP that is lacking >> (as above); in others, UDP). >> >> It’s only important whether the user does or doesn’t care about those >> properties. When they match what they care about, they can be >> considered equivalent. >> >> I.e., there’s not likely going to be a strict and absolute >> equivalence between transports. >> >> Equivalence is TO THE USER, relative to their constraints. >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org <mailto:Taps@ietf.org> >> https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
