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

From: Robert Sparks <[email-masked]>
Date: Wed, 24 Jun 2015 18:19:10 -0500

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: Randy Bush <[email-masked]>
Date: Thu, 25 Jun 2015 08:35:35 +0900

> that look more like statements of fact and less like charging advice.

darn hard as there are no facts there and it is first class lawyer bait.

randy

---

From: Job Snijders <[email-masked]>
Date: Thu, 25 Jun 2015 01:45:12 +0200

> darn hard as there are no facts there and it is first class lawyer

Indeed.

It might be better to remove this part:

"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows opposes the peering agreement.  In this case,
an operator could account the amount of traffic that has been subject to
the unexpected flows, using traffic measurement protocols such as IPFIX,
and charge the peer for that traffic.  That is, the operator can claim
that it has been a provider of that peer for the traffic that transited
between the two ASes."

Instead something like:

"It is possible that the behavior of the neighboring AS causing the
unexpected traffic flows violates a contractual agreement between the
two networks."

And just leave it at that. It is worth noting that, although from a
technical perspective it is not always trivial to proactively prevent
these types of traffic flows, you could try and capture your intentions
in a contract and deal with fallout as said contract prescribed.

Kind regards,

Job

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 24 Jun 2015 16:49:08 -0700

> On Jun 24, 2015, at 4:45 PM, Job Snijders <[email-masked]> wrote:
> 
> And just leave it at that.

I support Job’s proposed improvement wholeheartedly.

                                -Bill

---

From: Pierre Francois <[email-masked]>
Date: Thu, 25 Jun 2015 11:42:53 +0200

Job, 

I agree. We'll do that. 

The objective of this doc is to let operators figure out the issue, have monitoring capable of detecting its occurrence, and show how difficult it is to prevent these from happening in the first place.

The charging thing is from an operator telling me that that's what he would try to do. I'm perfectly fine removing it. 

Regards,

Pierre.

Sent from my iPhone

> On Jun 25, 2015, at 1:45 AM, Job Snijders <[email-masked]> wrote:
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Pierre Francois <[email-masked]>
Date: Thu, 25 Jun 2015 12:23:02 +0200

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-masked]> wrote:
> 
> 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.

[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.

---

From: Randy Bush <[email-masked]>
Date: Thu, 25 Jun 2015 20:45:52 +0900

pierre,

describing is great.  detecting is great.  when one starts to tell what
the operator should do beyond that, the ground gets shakier the further
one goes.

randy

---

From: Pierre Francois <[email-masked]>
Date: Thu, 25 Jun 2015 14:37:38 +0200

Randy,

I have the feeling you represent the general opinion on this. We'll adapt.

Thanks,

Pierre.

Sent from my iPhone

> On Jun 25, 2015, at 1:45 PM, Randy Bush <[email-masked]> wrote:
> 
> pierre,
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 26 Jun 2015 07:22:36 +0900

hi pierre

> I have the feeling you represent the general opinion on this.

in theory, with brownian motion, all the molecules of are can end up in
one corner of the room.  it's just rare.  :)

randy

---

From: <[email-masked]>
Date: Fri, 26 Jun 2015 06:44:41 +0000

> From: GROW [mailto:[email-masked]] On Behalf Of Randy Bush > Sent: Friday, June 26, 2015 12:23 AM
> 
> hi pierre
> 
> in theory, with brownian motion, all the molecules of are can end up in one
> corner of the room.  it's just rare.  :)

And the hotter (the topic), the more rare ;-)

> randy

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.