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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Fri, 31 August 2018 17:42 UTC

MIME-Version: 1.0
References: <153549231960.6181.5129820855641929896@ietfa.amsl.com> <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no>
In-Reply-To: <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Fri, 31 Aug 2018 12:41:57 -0500
Message-ID: <CAKKJt-f3ZBL83mHiWjknyT4s+Vfa5HoCS+wkA-=v3JAWK1didw@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: Robert Sparks <rjsparks@nostrum.com>, gen-art <gen-art@ietf.org>, draft-ietf-taps-minset.all@ietf.org, IETF list <ietf@ietf.org>, taps WG <taps@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000026b70574beb689"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/4OkLF7gC3qtsMabaPuyU9uMa-j0>
Subject: Re: [Gen-art] [Taps] Genart last call review of draft-ietf-taps-minset-06
Precedence: list

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 <michawe@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 <rjsparks@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"?

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] Genart last call review of draft-ietf-t… Robert Sparks
Re: [Gen-art] [Taps] Genart last call review of d… Michael Welzl
Re: [Gen-art] [Taps] Genart last call review of d… Spencer Dawkins at IETF
Re: [Gen-art] [Taps] Genart last call review of d… Michael Welzl
Re: [Gen-art] [Taps] Genart last call review of d… Spencer Dawkins at IETF
Re: [Gen-art] [Taps] Genart last call review of d… Robert Sparks
Re: [Gen-art] [Taps] Genart last call review of d… Michael Welzl