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'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
