Subject: Re: [Dots] Consolidation of all draft charter feedback

From: Scott Barvick <[email-masked]>
Date: Tue, 19 May 2015 20:28:33 +0000

Because it seems perhaps too informal and therefore not much value over
the official document with use cases and enough wiggle room with ‘as the
WG sees fit’ to let us do what we think we need to do?    If so, I could
agree with that.  

Scott 

On 5/19/15, 10:13 AM, "Daniel Migault" <[email-masked]> wrote:

>Hi, 
>
>I suggest to remove the first milestone item:
>
>OLD
>> * Use case document to ensure commonality of the work among the
>> participants in the Working Group.  This document may be determined by
>> the working group to remain informal and not be published.
>> * Document or Documents describing the problem space, use cases,
>> protocol requirements and other qualifying information as the WG sees
>>fit.
>> * Document or Documents specifying a protocol and associated data
>> models to address the WG stated goal.
>
>NEW
>> * Document or Documents describing the problem space, use cases,
>> protocol requirements and other qualifying information as the WG sees
>>fit.
>> * Document or Documents specifying a protocol and associated data
>> models to address the WG stated goal.
>
>BR, 
>Daniel
>-----Original Message-----
>From: Dots [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
>Sent: Saturday, May 16, 2015 10:26 PM
>To: [email-masked]
>Subject: [Dots] Consolidation of all draft charter feedback
>
>Hello!
>
>There has been robust discussion on the draft charter text
>(http://www.ietf.org/mail-archive/web/dots/current/msg00077.html).  To
>make it easier to review the draft charter with the benefit of previous
>feedback, below you can find a summary of all comments to date aggregated
>inline with corresponding links.
>
>Per Kathleen Moriarty's request
>(http://www.ietf.org/mail-archive/web/dots/current/msg00074.html), please
>provide further commentary or statements of support.
>
>Roman
>
>----[ Aggregated comments on the draft charter ]----
>
>> The aim of DDoS Open Threat Signaling (DOTS) is to develop a standards
>> based approach to the real time signaling of DDoS related telemetry
>> and
>
>[Andrew Mortensen] suggested that "real time" signaling is expected under
>attack conditions, and that this detail should be noted explicitly in
>http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> threat handling data between elements concerned with attack mitigation.
>> 
>> The elements may be described as:
>> * On-premise DDoS mitigation platforms
>> * Service provider DDoS mitigation platforms
>> * Other network devices/platforms that are able to sense DDoS and
>> respond
>
>[Adam Montville] suggested to tighten up the language of this third
>bullet in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>--
>[Nik Teague] proposed to the following text in response to Adam:
>
>"While the resulting standards should be designed so that there¹s a
>possibility of applying them to network security applications beyond DDoS
>mitigation, this working group will focus on just DDoS mitigation.²
>
>in http://www.ietf.org/mail-archive/web/dots/current/msg00083.html
>
>--
>[Xialiang (Frank)] Recommended leaving the third bullet vague pending a
>review of the use cases in
>http://www.ietf.org/mail-archive/web/dots/current/msg00085.html
>
>--
>[Andrew Mortensen] suggested "Other devices with network perspective
>performing traffic analysis"  or ".engaged in traffic analysis"
>
>> * Chained instances of the above
>> 
>> These elements may be communicating inter-domain or intra-domain over
>> links that may be congested by attack traffic resulting in hostile
>> conditions for traditional connection oriented approaches and more
>> generalized signaling
>
>[Andrew Mortensen] suggested removing "traditional" in
>http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> and telemetry solutions.  Robustness under these conditions is
>> paramount while ensuring appropriate regard for authentication,
>> authorization, privacy and data integrity.  Elements may be deployed
>> as part of a wider strategy incorporating multiple points of detection
>> and mitigation, both on premise or service provider based.
>> Should mitigation need to move between elements in the chain then
>
>[Adam Montville] suggested a comma between "chain" and "then" resulting
>in: "Should mitigation need to move between elements in the chain, then."
>in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>--
>[Linda Dunbar] sought clarity on whether the following items were in
>scope:
>* determining the optimal path between DDOS elements determined in
>concert with the Network Management system
>* ensuring the secure channels and congestion status for paths between
>the mitigating devices
>
>In http://www.ietf.org/mail-archive/web/dots/current/msg00081.html
>
>--
>[Scott Barvick] replied to [Linda Dunbar] on this scope in
>http://www.ietf.org/mail-archive/web/dots/current/msg00082.html
>
>--
>[Andrew Mo ] sought clarity on whether "... an on-premise device may
>signal laterally intentional? Or is the expectation that each subsequent
>element in the chain will be upstream from the previous?" in
>http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>--
>[Linda Dunbar] suggested updated text that reads as "These elements may
>be communicating over congested links/paths, with possibility of packets
>loss.  Therefore, mechanisms have be considered to compensate packets
>loss to ensure appropriate regard for authentication, authorization,
>privacy and data integrity." In
>http://www.ietf.org/mail-archive/web/dots/current/msg00102.html
>
>--
>[Scott Barvick] in
>http://www.ietf.org/mail-archive/web/dots/current/msg00104.html and
>[Kathleen Moriarty] in
>http://www.ietf.org/mail-archive/web/dots/current/msg00103.html believe
>the existing language covers [Linda Dunbar]'s proposal.
>
>> effective signaling of telemetry and current threat handling is
>>essential.
>>  Feedback between participating elements is required for increased
>> awareness for effective decision making.
>
>[Adam Montville] suggested  ".required for increased awareness supporting
>effective decision making" in
>http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>--
>[Xialiang (Frank)] suggested "Feedback and initial capability negotiation
>mechanisms between participating elements is required for increased
>awareness for effective decision making." in
>http://www.ietf.org/mail-archive/web/dots/current/msg00085.html
>
>> The WG will, where appropriate, reuse existing standard protocols and
>> mechanisms, for instance IPFIX and its templating mechanism.
>
>[Adam Montville] suggested mentioning other working groups in
>http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>--
>[Andrew ] highlighted the inherent conflict between reusing IPFIX (stated
>here) and the limitation of "traditional connection oriented protocols"
>(stated above in the chart) in
>http://www.ietf.org/mail-archive/web/dots/current/msg00098.html
>
>> The charter of the working group is to produce one or more standards
>> track specification to provide for this open signaling in the DDoS
>>problem space.
>
>[Adam Montville] suggested making "specification" plural, so that the
>sentence reads: ".to produce one or more standards track specifications."
>in http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>> While the resulting standards should be designed so that there¹s a
>> possibility of applying them to network security applications beyond
>> DDoS mitigation,
>
>[Andrew Mortensen] suggested using ".designed so they may apply to
>network security applications." in
>http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> this working group will focus on just DDoS mitigation.  This
>> streamlined focus
>
>[Andrew Mortensen] suggested removing "just" in
>http://www.ietf.org/mail-archive/web/dots/current/msg00086.html
>
>> of the charter is intended to lead to an earlier result due to
>> community interests in having such capability in a short timeframe.
>>  The specification(s) produced by the WG will include a standard
>> mechanism for authentication and authorization, for data integrity,
>> and for providing for privacy in operation.
>> 
>> The WG will produce the following deliverables:
>> 
>> * Use case document to ensure commonality of the work among the
>> participants in the Working Group.  This document may be determined by
>> the working group to remain informal and not be published.
>> * Document or Documents describing the problem space, use cases,
>> protocol requirements and other qualifying information as the WG sees
>>fit.
>> * Document or Documents specifying a protocol and associated data
>> models to address the WG stated goal.
>
>[Adam Montville] suggested adding a milestone to review milestones and
>specific dates for these in
>http://www.ietf.org/mail-archive/web/dots/current/msg00080.html
>
>
>> _______________________________________________
>> Dots mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dots
>
>_______________________________________________
>Dots mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dots
>
>_______________________________________________
>Dots mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dots