Hi, Michael, On Wed, Aug 22, 2018 at 8:50 AM Michael Welzl <[email protected]> wrote:
> > > > 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. > Excellent. We're already in Last Call, so no action needed from me, I think. > > Thanks for chasing this nit with me, by the way. > > No, thanks to *you* for finding and telling ! > I'm glad I could help. Spencer > Cheers, > Michael > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
