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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 1 Sep 2018 22:43:21 -0500

Hi, Michael,

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

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

---

From: Robert Sparks <[email-masked]>
Date: Tue, 4 Sep 2018 12:57:43 -0500

On 9/1/18 10:43 PM, Spencer Dawkins at IETF wrote:
> Hi, Michael,
>
> On Fri, Aug 31, 2018, 15:35 Michael Welzl <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Spencer,
>
>     See below:
>
>>     On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF
>>     <[email-masked]
>>     <mailto:[email-masked]>> 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 <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         Hi,
>>
>>         Thank you very much for this careful review!  We just posted
>>         a revision ( -07 ) that, we believe, addresses these comments.
>>
>>         > On 28 Aug 2018, at 23:38, Robert Sparks
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>         >
>>         > Reviewer: Robert Sparks
>>         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.
>
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.

>
> I'll let you and Robert resynchronize on this, now that I think you'll 
> be talking about the same thing.
>
>>     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
>
>

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Sep 2018 16:15:04 +0200

Hi,

> On Sep 4, 2018, at 7:57 PM, Robert Sparks <[email-masked]> wrote:
> 
> 
> 
>> On Fri, Aug 31, 2018, 15:35 Michael Welzl <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Spencer,
>> 
>> See below:
>> 
>>> On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>> Hi,
>>> 
>>> Thank you very much for this careful review!  We just posted a revision ( -07 ) that, we believe, addresses these comments.
>>> 
>>> > On 28 Aug 2018, at 23:38, Robert Sparks <[email-masked] <mailto:[email-masked]>> wrote:
>>> > 
>>> > Reviewer: Robert Sparks
>>> 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.
>> 
> 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