Dissemination of Flow Specification Rules
draft-ietf-idr-flow-spec-09
Yes
(Adrian Farrel)
(David Ward)
(Ron Bonica)
No Objection
(Chris Newman)
(Cullen Jennings)
(Lisa Dusseault)
(Mark Townsley)
(Pasi Eronen)
(Russ Housley)
(Tim Polk)
Recuse
(Ross Callon)
Note: This ballot was opened for revision 09 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
()
Unknown
David Ward Former IESG member
Yes
Yes
()
Unknown
Ron Bonica Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
(was No Record, No Objection)
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2009-02-12)
Unknown
Health warnings and ACL configuration by management interfaces are not defined. This may be within the scope of future work in the OPS area - formalized by some form of SMI.
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2009-04-27)
Unknown
1) I have let go off my IPv6 discuss, on the basis that Danny McPherson has promised to write a document on this, and the RTG ADs agree that the work belongs in the charter and should be done. 2) I would suggest that the document needs to talk more about in which situations the use of flowspec is appropriate, e.g., dos prevention, disabling specific attacks, etc. vs. any routing of flows in the core of the internet. The additions to the text clear my discuss, explaining the proper usage would do far more to convince the reader that this does not cause a scalability problem than saying "its not been a problem and we can build bigger routers", which the current text basically states. (FWIW I believe that is a true statement, but nevertheless.)
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2009-02-10)
Unknown
Section 2., paragraph 2: > While forwarding information is, typically, dynamically signaled > across the network via routing protocols, there is no agreed upon > mechanism to dynamically signal flows across autonomous-systems. This is incorrect. RSVP has been used for this purpose for a long time. See RFC2210. Section 4., paragraph 28: > Type 4 - Port > Encoding: <type (1 octet), [op, value]+> > Defines a list of {operation, value} pairs that matches source > OR destination TCP/UDP ports. This list is encoded using the > numeric operand format defined above. Values are encoded as 1 > or 2 byte quantities. SCTP and DCCP also use port numbers. Suggest to add them to the list above. (Same for source and destination ports below.)
Lisa Dusseault Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
(2009-04-01)
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
Recuse
Recuse
()
Unknown