Robert, Thanks a lot for your contribution to this work.
Comments inline [pfr] Pierre. Sent from my iPhone > On Jun 25, 2015, at 1:19 AM, Robert Sparks <[email protected]> wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-grow-filtering-threats-06 > Reviewer: Robert Sparks > Review Date: 24-Jun-2015 > IETF LC End Date: 2-Jul-2015 > IESG Telechat date: not yet scheduled for a telechat > > Summary: Ready with nits > > From looking at the document history and list archives, this document's been > around for some time, and has had some editorial push already. > The unintended consequences it highlights are interesting, and it will be > useful to operators to know these possible causes of unexpected behavior. > > I encourage another strong editing pass before publication. > > This is being published as an IETF-stream document. When published it > reflects IETF consensus. > There are places in the text that I think are problematic given that status. > The issues are editorial, and I expect they will be easy to address. > > The document uses "we" frequently. Originally, that meant the authors. It's > ambiguous what it means in an IETF-stream document. I suggest editing out all > occurrences. Try to avoid simply changing "we" to "the authors" - find a way > to reflect what the IETF is saying here. [pfr] I agree. We'll do that. > > Is the last paragraph of 4.1 an IETF consensus position on how operators > might charge one another? It would be good to find a way to word this that > look more like statements of fact and less like charging advice. [pfr] This sentence dates from the time we were interviewing ops and peering managers, asking them what they'd do. We got this as an answer a couple of times. I think Job's proposal to remove it is the right approach. > > The document draws some conclusions that I think are unnecessary. For > instance, "Therefore, we conclude that the reactive approach is the more > reasonable recommendation to deal with unexpected flows." Why does the IETF > need to say that (and is it an IETF consensus statement)? It would be enough, > I think, to reduce the discussion in these sections to calling out the issues > with each approach. [pfr] Can I use the IETF vs authors trick here? > > Please simplify the sentences, and avoid passive construction. For instance, > "It can be considered problematic to be causing unexpected traffic flows in > other ASes." can be much shorter. After you do that, I think you'll find it > easier to identify and collapse sections of redundant text. [pfr] Thanks a lot for the feedback. Pierre. > > RjS > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
