Hi, Michael, On Fri, Aug 31, 2018, 15:35 Michael Welzl <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> 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> 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> 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”? > I'll let you and Robert resynchronize on this, now that I think you'll be talking about the same thing. I'll watch, if I'm needed, of course. Spencer Cheers, > Michael > > But, whatever it is, if you two can figure out how to describe what's > happening, that will probably help figure you and Robert agree on an > understanding about how to handle his comment. > > Spencer > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
