Minutes for DOTS at IETF-95
minutes-95-dots-1

IETF 95 ACE Meeting Agenda
Friday, April 8, 2016, 10:00-12:30

Chairs: Roman Danyliw, Tobias Gondrom
Meeting Minute Taker: Xia Liang (Frank)

1. Status update (chairs):
Milestone has been modified and delayed.

2. WG use cases draft (Roland):
- Not exhaustive, representative.
- 02 will be a major re-factoring of document.
- New use cases will combine components, exchanges, and processes.
- combine inter operator use cases from another individual use cases drafts,
and new co-authors

linda dunbar: not clear what is the dots client? what capability it have?
Roland: any devices have ip address, such as router, mitigation device, web
server daemon, ... Daniel, Bob: will clarify the definition in 02 version

3. inter-domain use cases draft (Kaname):
Flemming: how much of the delegation model is in scope here?
Kaname: the minimal info should be the same for C2P and P2P, but the optional
info maybe is not the same. Flemming: Multihop deligation call for mitigation. 
Move the mitigation closer to the attack. Roland: all the mitigation methods
are out of scope of dots, maybe in i2nsf. Chris: clients do not see the
mitigation methods, it's the DOTS server's decision. Daniel: also not sure
about how to do the sharing between domains, the overlapping between DOTS and
I2NSF should be clarified. Tobias(as chair): we will negotiate and cooperate
with I2NSF for further analysis and conversation.

linda: what do you mean about wrong of bgp flowspec?
Kaname: not mean it. just say some bgp flowspec need be changed.

4. inter-domain problems and mechanisms draft (Kaname):
Chris: no matter what use cases, the basic is dots client to dots server
relation. DOTS client should only see DOTS server and call for help, and need
not know and do more. Frank: you are right. but some difference exists about
how to construct a coordinating system based on the basic relation. Roland: 1.
topology isn't super important here. 2. different networks/operators may have
different gear/capabilities - so prescritptive solutions are not as good.
'lowest common denonimator is important'. Flemming: disagree - possible at l7
for problems to require much more assitance/info. alexander lemon: diff tech
will bring diff results Tobias (hat-off): lowest common denonimator is the
basic principle. But for the customer (operators), more information can bring
more benefits, so welcome more input and information for this part! Dave: is it
useful to exchange dots server info to dots client? Frank: Your question makes
sense mainlyfor the distributed architecture, but the problem is full
bidirecitonal signaling exchange is a little bit complex. Maybe now we should
make it simple that just client send its info and call for help to server, and
let the server to make decision in the first stage. alexander lemon: be away
from the hierarchy way!

5. dots requirements draft (Andrew):
Frank:conflict detection and notification, and lookup caching need more
clarificaion, what we can do for these parts? need more discussion on ML
Flemming: DNS ttl ignoring? Bob: when network is attacked, we cannot rely on
DNS system to lookup the address. Roland: peering for dots does not require
dns/resolution. Daniel: question plus timestamp for lifetime quesiton Dave: Is
it in scope of DOTS that DOTS client requests more detailed mitigation, such
as: filtering part of the traffic. Andrew: out of scope most likely?? discuss!
Roman: encourge more suggestions about data channel part contents!

6. dots architecture draft (Andrew):
Roland: suggest to be conservation for current dots information, maybe in
future we can add more. Tobias (as chair): how many people have read this
draft? call for adoption

7. dots transport draft (Dan Wing):
Dan: asking for feedback on CoAP vs http/etc
Daniel: does json/cbor/etc make sense with coap? expand on why
Dan: need more study?
Andrew: like CoAP. but most of the texts in this draft about how to distribute
filters is more about Restful, not so closely related with DOTS. Dan: agree

chairs: happy eyeballs and coap need some discussion on ML and get consensus
dave: eyeballs need more buf and response time, and maybe multiple success.
also need to consider what data model will influence the transport protocol.
Nik: support eyeballs Luyuan Fang: like CoAP. Daniel: make the transport
protocol implementation simple.

8. inter-domain dots problems and mechanisms: (frank)
Roland:  IPFIX reimplemented across another channel.  Why not just send IPFix
as usual. Andrew:  Uses HTTP and JSON.  Does client run HTTP server? Frank: 
All server messages are responses to client messages. Luyuan:  What about
communicating also during good times? Tobias (hat-off): we need them. but is
something in discussion. Firstly, we need to guarantee not to lose them. chairs
and Nik: running code and current existing implementation are all important to
help us succeed. Kaname: NTT has some inter implementation for some use cases,
be pleased to share.

9. draft-moskowitz-dots-gre-00 (Bob)
Dave:port can be another attack surface. suggest DOTS protocol to not have
fixed port, or have some dynamic negotiated port. Flemming: it's interesting
but suggest to focus on UDP

10. Introducing session layer considerations (Bob)
     - draft-moskowitz-dots-ssls-01
     - draft-hares-i2nsf-slss-00
Roland: maybe a corner-case, but is real and important. Another options to
solve the related problems is by provisioning, or OOB channel. Tobias
(hat-off): have we outlined the alternated transport use case in our WG draft?
Roland: not yet, but will do.

Close of session.