DDoS Open Threat Signaling (DOTS) Requirements
Note: This ballot was opened for revision 18 and is now closed.
Benjamin Kaduk Yes
Ignas Bagdonas No Objection
Deborah Brungard No Objection
(Ben Campbell) No Objection
Comment (2019-02-20 for -18)
- I'm curious what the archival value this has for publishing as an RFC. Did the WG consider alternative publication methods? (e.g., leave as a draft, publish in a WG wiki) §1.2: The draft uses 2119/8174 keywords to describe requirements for protocol design. That's not really how 2119 defines them. That doesn't prevent using them here, but it would be helpful to modify or add to the boilerplate to indicate this.
Alissa Cooper No Objection
Comment (2019-02-21 for -18)
I agree with others in that this document seems to have been overtaken by events. I agree with the Gen-ART reviewer that the specification of the heartbeat requirements is so detailed that I suspect much of it will be essentially reproduced in the actual solution documents.
Suresh Krishnan (was Discuss) No Objection
Comment (2019-03-05 for -20)
Thanks for addressing my DISCUSS and COMMENTs.
Mirja Kühlewind (was Discuss) No Objection
Comment (2019-03-18 for -21)
Thanks for addressing my discuss. There is still my comment about references for SIG-002: For PLMTUD the correct reference is RFC4821, however, as commented by Joe, RFC1191 is less reliable and therefore usually not recommended. I would recommend to re-add a reference to RFC4821 and no reference to RFC1191 (or only with a warning that RFC4821 is preferred due to ICMP blocking). Further, the correct reference for datagram PLMTUD is draft-ietf-tsvwg-datagram-plpmtud. I would recommend to add a reference to this draft as well. And this general comment still holds: I understand that having wg consensus for this document is import to proceed the work of the group, however, I don't see the value in archiving this document in the IETF RFC series as a stand-alone document. If the group thinks documenting these requirements for consumption outside the group's work at a later point in time is valuable, I would rather recommend to add the respective requirements to the appendix of the respective protocol specs.
Alexey Melnikov No Objection
(Eric Rescorla) (was Discuss) No Objection
Comment (2019-03-23 for -21)
I believe we have come to a satisfactory resolution and Benjamin will ensure that the correct changes are made.
Alvaro Retana No Objection
Comment (2019-02-20 for -18)
It seems to me that if "the requirements in this document are derived from [I-D.ietf-dots-use-cases] and [I-D.ietf-dots-architecture]", then those documents should be Normative references. Given that those documents haven't been published yet, and that the solutions (draft-ietf-dots-data-channel and draft-ietf-dots-signal-channel) have already passed WGLC, the publication value of this document may have been overtaken by events. I am not standing in the way of publication.