Re: [Gen-art] [Taps] Genart last call review of draft-ietf-taps-minset-06

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Michael,

On Fri, Aug 31, 2018, 15:35 Michael Welzl <[e-mail]> wrote:

> Hi Spencer,
>
> See below:
>
> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF <
> [e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>
>
>
>