DDoS Open Threat Signaling
charter-ietf-dots-01

The text says that the WG will reuse or extend existing standard protocols and mechanisms, which is great!  However, is the intent for dots to standardize those extensions (if needed)?  IOW, if an existing protocol (for signaling, for example) is extended, I think that the WG responsible for that protocol should be the one driving the standardization based on the requirements from dots.  The text mentions ipfix as an example; I know the ipfix WG is closed, so it can't take ownership of the extensions, but the OPS area should at  least be consulted.

After saying all that, I would suggest adding something explicit about consulting, coordinating, etc. with other WGs that may be responsible for any protocols being extended.  Maybe something like this:

"Any modification of or extension to existing protocols must be carried out in the working groups responsible for the protocol being modified and in co-ordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible Area Directors."

There is likely significant overlap here with deployed stuff , and M3AAWG would know about that.  I will talk with people about that during the upcoming week  at M3AAWG in Dublin, and I will make sure that the external review message is posted to the M3AAWG Technical Committee.  But I would appreciate it if the charter explicitly called out collaboration with M3AAWG.

I concur with Stephen's comment about privacy-friendly defaults.

Based one the fact that DDOS systems within different ISPs already discuss together today (but with a proprietary protocol), as mentioned by Kathleen, I'm clearing my DISCUSS.
For documentation purposes, the BLOCK was: 
More of DISCUSS-DISCUSS for the telechat than a BLOCK.

"These elements may be communicating inter-domain or intra-domain over
links that may be congested by attack traffic resulting in hostile
conditions for connection oriented approaches and more generalized
signaling and telemetry solutions."

"Document or Documents describing the problem space, use cases, protocol
requirements and other qualifying information as the WG sees fit."

I would strongly encourage the group to focus first on the intra-domain: this is already a huge problem. The inter-domain use cases will lead to different set of requirements (sending telemetry info across domains, potential synchronization of the collecting infrastructure).
Sharing IPFIX data between domains is not a reality today, and and when I see "Feedback between participating elements is required for increased awareness supporting effective decision making.", it remains to be seen if elements from different domains will communicate...
Don't make the scope too big.


========================
Btw, any link with BGP Flow Spec to block the attack?

One consistent issue that I have found with pushing  telemery and then mitigation upstream is the loss of visibility into the attack. so while downstream customers may be senders of information at some point they also need any telemetry generated upstream.

Thank you for addressing my issue.

I have the same question Martin has, in his BLOCK. If there are any requirements for the transport protocol that would disqualify TCP (or, for extra credit, SCTP or MP-TCP),  it would be great to know that at charter time.

Thank you for addressing Stephen's BLOCK-light.

This is not a BLOCK but I'd like to chat about it and may consider
it being a BLOCK at the next stage, depending on the discussion.
The text says "providing for privacy in operation" but I think it
ought say "providing for privacy in operation, with privacy-friendly
choices being the default in all cases" (or similar). This kind of 
reporting can easily end up privacy-unfriendly, especially when 
we're saying the WG should consider "network security applications 
beyond the DDoS problem space" which could be interpreted by 
some to include very privacy-unfriendly applications. So I think 
explicitly calling for the default to be whatever privacy-friendly
choices exist and are usable is important here.

The first thing that grabbed me was impact of DOTS on a system/network that is under attack. I think Martin has raised it well, so I won't belabour the point.

I wonder if this, in the nature of the work, is going to be of a far more experimental nature than it is a standards track body of work? I can foresee _multiple_ iterations (presuming the proponents move passed talking about the problem) over implementation and design principles. As a WG outputting experimental documents it will mean that they will have an interesting time modifying existing RFCs within the WG, but will be able to still collaborate with other WGs as necessary.