Software-Defined Networking: A Perspective from within a Service Provider Environment
draft-sin-sdnrg-sdn-approach-09
Yes
No Objection
(Barry Leiba)
(Gonzalo Camarillo)
(Jari Arkko)
Abstain
Note: This ballot was opened for revision 05 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2013-11-21 for -06)
Unknown
We need to take the "SDNRG" out of the top left corner
Stewart Bryant Former IESG member
(was Discuss)
Yes
Yes
(2014-01-06)
Unknown
Thank you for the additional text on bootstrapping, discovery and control channel maintenance. I believe the new text highlights a number of important issues that are often glossed over in discussions on SDN.
Barry Leiba Former IESG member
No Objection
No Objection
(for -05)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -06)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-11-20 for -06)
Unknown
I would like to hear why this draft is put forward as AD sponsored, as this looks like a fine thing for the ISE track.
Sean Turner Former IESG member
No Objection
No Objection
(2013-11-20 for -06)
Unknown
Regardless of what stream it gets published through I think it ought to clear say which service provider's opinion this draft documents. The title of the draft is: A Perspective From Within A Service Provider I assume the provider to which this draft is referring is France Telecom because the authors are both form the same company? Wouldn't a better title be: France Telecom's Perspective on Software-Defined Networking With that title change then it would be like every other draft we "discuss" that comes through the IESG that is an organization's protocol, view, profile, etc. ?
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-11-21 for -06)
Unknown
Overall, I like this - it should be useful input for people designing SDN stuff. I do wonder why it isn't just an IRTF SDNRG document though, since it might fit better there. But doing it this was is fine by me. - 3.3 says that some s/w modules might be controlled by external entities - surely that would raise some additional security and privacy consideratons in an SDN deployment? I'd say that would be worth a mention in section 6. - Section 6 could probably also mention s/w update requirements, if that's not already covered in Sam Hartman's draft that's referenced. (Can't recall.)
Benoît Claise Former IESG member
Abstain
Abstain
(2013-11-21 for -06)
Unknown
On one side, I'm happy to see a first SDN document in the IETF. This document is nice little introduction and explain some high level concepts. Thanks On the other side, I have some concerns: While the text is not bad, it states some personal opinions. We could debate on some points for some time: COPS-PR (I thought it was dead), where does the intelligence reside? interfaces, etc. Also, it seems like a self promotion of the authors other drafts [I-D.boucadair-connectivity-provisioning-profile] [I-D.boucadair-connectivity-provisioning-protocol] [I-D.boucadair-network-automation-requirements] Bottom line, I asked for some opinion, and I receive this one: "it's not really accepted by the community; its very much the personal opinions of those two guys" This also reflects my personal conclusion. Note that the acknowledgments section does show an overwhelming set of SP reviewers. I abstain, and would move to no objection if this documnet would go through ISE. I could leave with a SDNRG document.
Brian Haberman Former IESG member
Abstain
Abstain
(2013-11-20 for -06)
Unknown
While I agree with many of the points raised in this document, I cannot support its publication as an IETF stream RFC. This type of opinion piece is much better suited as a corporate whitepaper or an Informational RFC via the ISE. Given that view, I am abstaining on this document.
Joel Jaeggli Former IESG member
Abstain
Abstain
(2013-11-20 for -06)
Unknown
The section on flexibility 2.2 essentially says we're not going to define it (flexibility), but imagine a case where signaling is used to twiddle cos/packet treatment. I would characterize that as deeply unsatisfying. section 3.5 seems like a poorly targeted screed on openflow and I don't think it particularly appropiate as written to include such things in IETF documents.
Richard Barnes Former IESG member
Abstain
Abstain
(2013-11-20 for -06)
Unknown
I agree with my esteemed colleagues that this document would be far more appropriate on the Independent stream. Or, as I expected from the draft name, the IRTF stream. I do have to admit, though, that this document could fit through the same loop hole I suggested for RTMFP -- it is a product of the IETF in the sense that the IETF thought it was a good idea to publish. That concern aside, thanks to the authors for a readable, thoughtful document. In Section 3.1: "(references can be added if needed)" This can probably be deleted at this point.
Spencer Dawkins Former IESG member
Abstain
Abstain
(2013-11-21 for -06)
Unknown
I really like this doc, and the comments others have made would improve it (so that I would really, really like this doc), but it is awkwardly straddling IRTF and IETF, with a third leg pointed towards ISE. I would support it being published in either the IRTF stream or the ISE stream.. What I'd really like to see, is it being published as an Independent Submission as "one service provider's view" and/or forming the basis of a taxonomy document with broader support. I note that the Beyond OpenFlow section (3.5) is almost a mantra in SDNRG - it's the kind of thing you can say when it's not an IETF stream document. What Lars would really like to see, is "SDNRG Working Group" not being in the upper left hand corner of the title page. Does that get rewritten by the RFC Editor anyway?