Subject: [I2nsf] FW: Merged I2NSF problem statement and Use Case - draft-hares

From: "Susan Hares" <[email-masked]>
Date: Sat, 19 Dec 2015 20:17:05 -0500

Sending this just to list. 

Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Saturday, December 19, 2015 8:11 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]'; [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; [email-masked]';
[email-masked]'; 'Kathleen Moriarty'
Subject: Merged I2NSF problem statement and Use Case - draft-hares

I2NSF folks and my co-authors: 

I have merged all the changes you suggested into Linda's problem statement
and combined this with the use cases.  Please let me know if you have any
concerns or changes to the resulting document.   

If anyone was left off the Contributors section, would you please let me
know.  This document is the combination of lots of people's hard work.  I
will upload it as  draft-hares-merged-i2nsf-problem-use-cases-00.txt along
with the XML on Sunday evening (12/20/2015) and then ask for WG adoption.
I'll watch for comments in the next few weeks and revise the text. 

Does I2NSF have a github repository?  If so, we can put the XML there to
change it. 

Sue Hares

---

From: "Zarny, Myo" <[email-masked]>
Date: Mon, 21 Dec 2015 10:59:55 -0500

Hi Sue,

Thanks very much for putting this together. It's quite challenging to put various threads together in a sensible order, which you've successfully done. And far easier to nitpick, which I'll do here.

A few comments:

·         Section 3.1.9 can be better worded.

o   Right now, it's describing not just the requirements for DOTS controller interfaces but also what to do about them. The text should describe why we need standard interfaces for:

§  DOTS controllers to which external entities (such as NSFs or users) can signal the need for DDOS mitigation, revoke mitigation policies, etc.

§  Network entities that will execute (implement/withdraw/get stats, etc.) DDOS mitigation functions

o   It describes the mysterious "I2NSF Controller" which I think the original author meant some network security controller. IMHO, I2NSF covers the interfaces for DOTS controllers and NSFs (and anything in between.) This draft shouldn't prescribe how mitigation policies may be carried out. (Policies may be executed through an intermediary like a "network security controller" or by calling the NSFs themselves.)

·         A similar issue with Section 3.1.10. It speaks of a controller distributing keys in the very first sentence. The need, as it does describe later in the paragraph, is a standard interface to provision and distribute the keys. Let's not muddy waters by declaring who may invoke the said interfaces. We should at least add "for example, a controller" or something like that.

·         Section 3.3 describes the general need for standard interfaces that could interpret [security] policies. Now, my understanding is that the current I2NSF charter doesn't really deal with policy interpretation beyond the most basic. But it can probably stand as is now since it's describing the requirements.

·         Overall, we need to do a sweep of copy-editing (for typos, grammar, etc.)

My two cents...

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 19 December 2015 8:17 PM
To: [email-masked]
Cc: [email-masked]; 'Linda Dunbar'
Subject: [I2nsf] FW: Merged I2NSF problem statement and Use Case - draft-hares

Sue
From: Susan Hares [mailto:[email-masked]]
Sent: Saturday, December 19, 2015 8:11 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; [email-masked]'; 'Kathleen Moriarty'
Subject: Merged I2NSF problem statement and Use Case - draft-hares

I have merged all the changes you suggested into Linda's problem statement and combined this with the use cases.  Please let me know if you have any concerns or changes to the resulting document.

If anyone was left off the Contributors section, would you please let me know.  This document is the combination of lots of people's hard work.  I will upload it as  draft-hares-merged-i2nsf-problem-use-cases-00.txt along with the XML on Sunday evening (12/20/2015) and then ask for WG adoption.   I'll watch for comments in the next few weeks and revise the text.

Does I2NSF have a github repository?  If so, we can put the XML there to change it.

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 21 Dec 2015 11:16:21 -0500

Myo:

Thank you for the comments.  I will work on a revision for sections 3.1.9
and 3.1.10 plus copy editing.  I’ll send a revision of 3.1.9 and 3.1.10 to
the list later today.  I’ll also read through the text again looking for
copy editing errors. 

Sue 

From: I2nsf [mailto:[email-masked]] On Behalf Of Zarny, Myo
Sent: Monday, December 21, 2015 11:00 AM
To: 'Susan Hares'; [email-masked]'
Cc: [email-masked]'; 'Linda Dunbar'
Subject: Re: [I2nsf] FW: Merged I2NSF problem statement and Use Case -
draft-hares

Hi Sue,

Thanks very much for putting this together. It’s quite challenging to put
various threads together in a sensible order, which you’ve successfully
done. And far easier to nitpick, which I’ll do here.

A few comments:

o   Right now, it’s describing not just the requirements for DOTS controller
interfaces but also what to do about them. The text should describe why we
need standard interfaces for:

§  DOTS controllers to which external entities (such as NSFs or users) can
signal the need for DDOS mitigation, revoke mitigation policies, etc.

§  Network entities that will execute (implement/withdraw/get stats, etc.)
DDOS mitigation functions

o   It describes the mysterious “I2NSF Controller” which I think the
original author meant some network security controller. IMHO, I2NSF covers
the interfaces for DOTS controllers and NSFs (and anything in between.) This
draft shouldn’t prescribe how mitigation policies may be carried out.
(Policies may be executed through an intermediary like a “network security
controller” or by calling the NSFs themselves.)

·         A similar issue with Section 3.1.10. It speaks of a controller
distributing keys in the very first sentence. The need, as it does describe
later in the paragraph, is a standard interface to provision and distribute
the keys. Let’s not muddy waters by declaring who may invoke the said
interfaces. We should at least add “for example, a controller” or something
like that.

·         Section 3.3 describes the general need for standard interfaces
that could interpret [security] policies. Now, my understanding is that the
current I2NSF charter doesn’t really deal with policy interpretation beyond
the most basic. But it can probably stand as is now since it’s describing
the requirements.

·         Overall, we need to do a sweep of copy-editing (for typos,
grammar, etc.)

My two cents…

From: I2nsf [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 19 December 2015 8:17 PM
To: [email-masked]
Cc: [email-masked]; 'Linda Dunbar'
Subject: [I2nsf] FW: Merged I2NSF problem statement and Use Case -
draft-hares

Sue 

I have merged all the changes you suggested into Linda’s problem statement
and combined this with the use cases.  Please let me know if you have any
concerns or changes to the resulting document.   

If anyone was left off the Contributors section, would you please let me
know.  This document is the combination of lots of people’s hard work.  I
will upload it as  draft-hares-merged-i2nsf-problem-use-cases-00.txt along
with the XML on Sunday evening (12/20/2015) and then ask for WG adoption.
I’ll watch for comments in the next few weeks and revise the text. 

Sue Hares