Hi,
> On Sep 4, 2018, at 7:57 PM, Robert Sparks <rjspa...@nostrum.com> wrote: > > > > On 9/1/18 10:43 PM, Spencer Dawkins at IETF wrote: >> Hi, Michael, >> >> On Fri, Aug 31, 2018, 15:35 Michael Welzl <mich...@ifi.uio.no >> <mailto:mich...@ifi.uio.no>> wrote: >> Hi Spencer, >> >> See below: >> >>> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF >>> <spencerdawkins.i...@gmail.com <mailto:spencerdawkins.i...@gmail.com>> >>> wrote: >>> >>> Thanks, Robert, for the careful read, and thanks, Michael, for the quick >>> response. I have one thought, on Robert's last question. >>> >>> On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl <mich...@ifi.uio.no >>> <mailto:mich...@ifi.uio.no>> wrote: >>> Hi, >>> >>> Thank you very much for this careful review! We just posted a revision ( >>> -07 ) that, we believe, addresses these comments. >>> >>> A few answers in line below: >>> >>> > On 28 Aug 2018, at 23:38, Robert Sparks <rjspa...@nostrum.com >>> > <mailto:rjspa...@nostrum.com>> wrote: >>> > >>> > Reviewer: Robert Sparks >>> > Review result: Ready with Nits >>> >>> ... >>> >>> > In Appendix A.1, this document had to "slightly change" the >>> > characterization of features from those in RFC8303, introducing this >>> > "ADDED" construct. That feels out of balance. Is this a warning sign >>> > that RFC8303 needs adjusting? >>> >>> It isn't: different from this document, RFC 8303 does not make any changes >>> or derive anything from the services that protocols offer - it just >>> reflects what the protocol specifications say. >>> >>> In the minset document, there are only 3 items using the "ADDED" construct, >>> and this is only meant to streamline the derivation a little. Take >>> "Unreliably transfer a message", for example. >>> This is based on (from RFC 8303) "Unreliably transfer a message, with >>> congestion control" for SCTP, and "Unreliably transfer a message, without >>> congestion control" for UDP(-Lite). The added "Unreliably transfer a >>> message" leaves the choice of congestion control open, such that an >>> application CAN simply say "Unreliably transfer a message" without having >>> to care about the choice of congestion control (unless it wants to care, >>> which comes at the cost of binding itself to either UDP(-Lite) or SCTP). >>> >>> Michael, this explanation helps a lot, but since I happen to know that >>> Robert is out of town for the three-day weekend in the US, I'll guess on >>> his behalf that "ADDED" may not be the word you're looking for - at a >>> minimum, "transfer unreliably" in RFC 8303 being divided into "transfer >>> unreliably with congestion control" and "transfer unreliably without >>> congestion control" in this draft doesn't look like addition to me. >>> >>> Is this more about "refactoring the protocol-independent definition in RFC >>> 8303”? >> >> Yes, “refactoring” is exactly right - it’s not adding anything new. We could >> just as well have left this without the “ADDED” cases and then had more >> explanations in the “discussions” section (appendix A.3), but these are so >> minor that they don’t really merit a “discussion”, hence we felt that this >> way it’s shorter and clearer. >> >> If that helps, I can rename “ADDED” into “REFACTORED”? > With that explanation, the single word without the explanation above feels > like insider knowledge. > Maybe adding a sentence explaining exactly what you say above at the point > you introduce the term would be enough, then the term-name itself wouldn't > matter as much. Agreed - done (I just submitted an update to -08), thanks! I kept “ADDED”, but explain it where the term is introduced. Cheers, Michael
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
