> On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF
> <[email protected]> wrote:
>
> Hi, Michael,
> On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl <[email protected]> wrote:
> Hi,
>
>
> > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF
> > <[email protected]> wrote:
> >
> > Hi, Aaron,
> >
> > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk <[email protected]> wrote:
> > Glad to see rapid convergence on these comments. My turn for a nit:
> >
> > On 21 Aug 2018, at 2:48, Michael Welzl wrote:
> >
> > I'm not sure if you saw my suggestion about qualifying the reference to
> > [I-D.ietf-taps-transport-security] as "Section 5 of
> > [I-D.ietf-taps-transport-security]", but assuming that we're good on that
> > one ....
> >
> >
> > I saw it and agree. I thought that it's not necessary for the specific
> > sentence that you ended up proposing, but now I agree that even in this
> > sentence it's better. I'll update it to include "Section 5 of" just ahead
> > of this reference.
> >
> > The likelihood of an ID having it's sections renumbered is high enough that
> > I don't think we should embed the section number in an RFC. I'd suggest
> > using the section name as well in case one or both changes the reader is
> > likely to make the connection: "Section 5 on Security Features and
> > Transport Dependencies of ..."
> >
> >
> > I totally agree on this one. I only suggested adding the section number
> > because I couldn't find any mention of the minimum set in the abstract or
> > Introduction for [I-D.ietf-taps-transport-security], so a reader would have
> > to scroll through the Table of Contents to notice it. I had a nagging
> > feeling when I made the suggestion - thanks for fixing it.
>
> Done (in my local copy). Actually I thought of the same thing but wasn't sure
> for one reason or another... I should have just gone for it!
>
>
> > If I might make one other observation, there are a few places visible in
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for
> > Section A (I think A.1) where there seems to be a missing newline between
> > "Implementation over TCP:" and "Implementation over UDP:" - I saw more than
> > one occurrence, but I think the first one to check is under "Specify
> > checksum coverage used by the sender" for "Protocols: UDP-Lite". I had
> > thought to make that observation as a response to the Last Call
> > announcement, but Aaron sent his suggested change before I did that.
>
> I don't see this; "Implementation over UDP" seems to start on a new line
> everywhere. What I do see is that an extra empty line has unintentionally
> ended up in there in a few places. Do you mean that there SHOULD be an extra
> empty line?
>
> I'm not sure what I'm seeing is what you're seeing. Let's talk before asking
> you to type :-)
>
> I'm looking at the bottom of page 29, top of page 30, in the HTML version.
> That's for
>
> o Specify checksum coverage used by the sender
> Protocols: UDP-Lite
>
> What I'm seeing in HTML for this section, is
>
> o Specify checksum coverage used by the sender
> Protocols: UDP-Lite
> Functional because application-specific knowledge is necessary to
> decide for which parts of the data it can be acceptable to lose
> data integrity.
>
>
>
> Welzl & Gjessing Expires February 21, 2019 [Page 29]
>
> Internet-Draft Minimal Transport Services August 2018
>
>
> Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
> Implementation over TCP: do nothing (TCP does not offer to limit
> the checksum length, but transmitting data with an intact checksum
> will not yield a semantically wrong result). Implementation over
>
> So, I'm not seeing a newline before "Implementation" here.
>
> UDP: if checksum coverage is set to cover payload data, do
> nothing. Else, either do nothing (transmitting data with an
> intact checksum will not yield a semantically wrong result), or
> use the transport feature "Disable checksum when sending".
>
> But since I always use the HTML version, and that's not even the canonical
> version, I checked the same thing in the TXT version, but it also looks like
>
> o Specify checksum coverage used by the sender
> Protocols: UDP-Lite
> Functional because application-specific knowledge is necessary to
> decide for which parts of the data it can be acceptable to lose
> data integrity.
>
>
>
> Welzl & Gjessing Expires February 21, 2019 [Page 29]
> Internet-Draft Minimal Transport Services August 2018
>
>
> Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
> Implementation over TCP: do nothing (TCP does not offer to limit
> the checksum length, but transmitting data with an intact checksum
> will not yield a semantically wrong result). Implementation over
>
> and I'm not seeing a newline before "Implementation" here, either.
>
> UDP: if checksum coverage is set to cover payload data, do
> nothing. Else, either do nothing (transmitting data with an
> intact checksum will not yield a semantically wrong result), or
> use the transport feature "Disable checksum when sending".
>
> So I should probably ask what format you're looking at, if you're not seeing
> what I'm seeing?
When I talked about extra empty lines, I was looking at exactly what my browser
gives me when following the URL that you included:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt
.... which is a side-by-side diff.
But now I found it! The problem was that I did a text search for
"implementation over UDP", which failed to show me these cases due to the line
break *within* the phrase :-)
Oh my :)
Now I did a search for "UDP:" instead, and with that, I only find precisely the
two cases that you quote above. So I think that's it - I'll fix and submit.
> Thanks for chasing this nit with me, by the way.
No, thanks to *you* for finding and telling !
Cheers,
Michael
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
