Re: [GROW] Genart LC review: draft-ietf-grow-filtering-threats-06

[Pierre Francois <[e-mail]>]

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 <[e-mail]> 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
>