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

[Robert Sparks <[e-mail]>]

On 9/1/18 10:43 PM, Spencer Dawkins at IETF wrote:
> Hi, Michael,
>
> On Fri, Aug 31, 2018, 15:35 Michael Welzl <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Spencer,
>
>     See below:
>
>>     On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF
>>     <[e-mail]
>>     <mailto:[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]
>>     <mailto:[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] <mailto:[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”?
>
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.
>
> 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
>
>