I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document:
draft-ietf-grow-filtering-threats-07
Reviewer:
Robert Sparks
Review Date:
17 Aug 2015
IETF LC End Date: 2 Jul 2015
IESG Telechat date: 20 Aug 2015
Summary:
Ready with nits (but these nits may be discuss worthy)
Nits/editorial comments:
Thanks for removing the text suggesting when operators might charge
each other.
I still find the document ambiguous about what it's stating as the
consensus of the IETF. In the places you changed how you used
"we", you did the very thing I asked to to resist - you say things
now
like "The authors recommend". What is the IETF saying? Is it that
the
IETF agrees that's what the authors recommend? Or is the IETF
recommending this.
This needs to be edited to speak _only_ in terms of what the IETF
recommends. I'm classifying this as a NIT since it's editorial, but
I'm
worried it's more than that. I encourage the IESG to consider
whether
this is a bigger issue.
You still draw this conclusion:
"The authors observe that proactive approaches can be
complex to implement and can lead to undesired effects, and thus
conclude that the reactive approach is the more reasonable
recommendation to deal with unexpected flows."
What is the IETF consensus position on what is more reasonable, and
is it
even necessary for the IETF to recommend one approach over the
other.
Why is it not sufficient to simply document the considerations with
each
approach and stop there?
Not much was done with my last suggestion. I still think the
document needs
a strong editorial revision along the lines suggested below.
On 6/24/15 6:19 PM, Robert Sparks
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.
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.
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.
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.
RjS
|