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? Thanks for chasing this nit with me, by the way. Spencer > I'd find that a bit odd, unless I add empty lines all over the place. > E.g., consider the following block: > > *** > o Indicate (and/or obtain upon completion) an Adaptation Layer via > an adaptation code point > Protocols: SCTP > Functional because it allows to send extra data for the sake of > identifying an adaptation layer, which by itself is application- > specific. > Implementation: via a parameter in CONNECT.SCTP. > Implementation over TCP: not possible (TCP does not offer this > functionality). > Implementation over UDP: not possible (UDP does not offer this > functionality). > *** > > If I add an empty line above "Implementation over UDP", then I should > probably also add one above "Implementation over TCP", above > "Implementation", above the line beginning with "Functional" and above > "Protocols: SCTP", right? But then this gets huge... > > My tendency would be to remove the extra lines. > > HOWEVER: it seems that the diff you're pointing at is misleading :( I > just checked against my local .txt file: in one case, the extra line was > added in the diff because, in fact, there was a new page (new pages with > headers are not shown in the diff), and in another, I don't understand > where the extra line in the diff comes from - my .txt doesn't have it. > > Either way, my proposal would be to go for the style of the text block I > copied above. Is that ok? > > > > I'll let the shepherds/chairs decide when to submit a revision that > fixes these nits, but if you folks wanted to do that at the beginning of > Last Call, I'd be fine with that, so review teams won't all make that > suggestion. :-) > > I'll do it as soon as I know what to do with line feeds! > > Cheers, > Michael > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
