Skip to main content

DDoS Open Threat Signaling (DOTS) Requirements
draft-ietf-dots-requirements-22

Yes

(Benjamin Kaduk)

No Objection

(Alexey Melnikov)
(Deborah Brungard)
(Ignas Bagdonas)

Note: This ballot was opened for revision 18 and is now closed.

Benjamin Kaduk Former IESG member
Yes
Yes (for -18) Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection (for -18) Not sent

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2019-02-21 for -18) Sent
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.
Alvaro Retana Former IESG member
No Objection
No Objection (2019-02-20 for -18) Sent
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.
Ben Campbell Former IESG member
No Objection
No Objection (2019-02-20 for -18) Sent
- 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.
Deborah Brungard Former IESG member
No Objection
No Objection (for -18) Not sent

                            
Eric Rescorla Former IESG member
(was Discuss) No Objection
No Objection (2019-03-23 for -21) Sent
I believe we have come to a satisfactory resolution and Benjamin will ensure that the correct changes are made.
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -18) Not sent

                            
Mirja Kühlewind Former IESG member
(was Discuss) No Objection
No Objection (2019-03-18 for -21) Sent
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.
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2019-03-05 for -20) Sent
Thanks for addressing my DISCUSS and COMMENTs.