Subject: [GROW] Genart Telechat review: draft-ietf-grow-filtering-threats-07

From: Robert Sparks <[email-masked]>
Date: Mon, 17 Aug 2015 12:48:06 -0500

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
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Aug 2015 16:50:39 +0300

Robert, Pierre:

Many thanks for your detailed review and re-review, Robert. And thanks for Pierre and
others for taking into account the comments; I can see that the document has improved.

As for the remaining issue of authors speaking vs. IETF speaking. I agree with the
principle that Robert lays out. But I have also reviewed the document and given the
specific text and the nature of the document (Informational RFC), I do not see
a big problem with the current text. At least not something that would be Discuss-worthy
from my end.

FWIW, more generally, a document provides information, and there may or may not be
IETF opinion backing that opinion. Standards track documents and BCP are
true IETF recommendations. In my view, in those documents, even if they might say
“the authors recommend XYZ” that really carries the weight of the IETF opinion.
For the informational document, there is no requirement that it carries the weight
of an IETF recommendation. But of course, where it is clear that there is an IETF opinion,
it might still say that explicitly.

Jari

On 17 Aug 2015, at 20:48, Robert Sparks <[email-masked]> wrote:

> IETF agrees that's what the authors recommend? Or is the IETF recommending this.
> 
>> 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.
>> 
>> 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
>> 
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Aug 2015 09:09:24 -0500

Jari -

It's your call to let this slide, but I would be a lot happier with what 
you say below
if the document were not going to end up with this on its front page 
when published
as an Informational RFC with IETF consensus (and it will, as it is 
currently being processed):

"   This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  "

How can something represent the consensus of the IETF community if there 
is not an 'IETF opinion backing that opinion'?

RjS

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Aug 2015 17:34:06 +0300

After some more staring of the data tracker settings, you are of course completely correct,
Robert :-) The document is marked as having IETF consensus setting, so the text that you
quoted will get inserted into the RFC.

Pardon my mistake in assuming it wasn’t.

On the IESG call we had a discussion about this issue. We saw two separate questions:

1) Substance: Is there a consensus behind the document’s recommendations? The sponsoring AD
and the IESG believes so.

2) Editorial: Is it appropriate to use the “the authors recommend…” form for IETF-level
consensus statements? The sponsoring AD took your comment about the formulation
(also recommended by other ADs) and will work with the author to revise the document.
However, this matter is indeed editorial, i.e., a Comment rather than a Discuss level
requirement from the IESG.

So the document will be approved, after some editorial modifications, and will become
an RFC.

Jari

---

From: Robert Sparks <[email-masked]>
Date: Thu, 20 Aug 2015 09:37:57 -0500

> So the document will be approved, after some editorial modifications, and will become
That plan works for me. Thanks!

---

From: Peter Schoenmaker <[email-masked]>
Date: Thu, 20 Aug 2015 20:24:49 +0100

Hi,

Jari the points you have made are supported by the work done in GROW on this draft.  Specifically, #1 there is consensus behind the draft, time was spent making sure it covered the right points which had consensus.  On #2 it does seem that the confusion comes from the use of the first person in the draft.  By changing the grammar to definitive statements makes the document stronger, and continues to accurately represent the consensus reached during the work on the text.

An example of the changes would be:

Change:
"The authors note that due to the distributed nature and restricted visibility of the steering of BGP policies, this second step is deemed to not identify the origin of the problem with guaranteed accuracy.”

To:
"Due to the distributed nature and restricted visibility of the steering of BGP policies, this second step does not identify the origin of the problem with guaranteed accuracy."

Peter

On 8/20/15, 3:34 PM, "GROW on behalf of Jari Arkko" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>GROW mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/grow