|
On 9/1/18 10:43 PM, Spencer Dawkins at
IETF wrote:
Hi, Michael,
Hi Spencer,
See below:
Thanks, Robert, for the careful
read, and thanks, Michael, for the quick
response. I have one thought, on Robert's last
question.
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 <rjsparks@xxxxxxxxxxx>
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
|
