Software-Defined Networking: A Perspective from within a Service Provider Environment
RFC 7149

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

(Stewart Bryant) (was Discuss) Yes

Comment (2014-01-06)
No email
send info
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.

(Adrian Farrel) Yes

Comment (2013-11-21 for -06)
No email
send info
We need to take the "SDNRG" out of the top left corner

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Stephen Farrell) No Objection

Comment (2013-11-21 for -06)
No email
send info
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.)

Barry Leiba No Objection

(Martin Stiemerling) No Objection

Comment (2013-11-20 for -06)
No email
send info
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) No Objection

Comment (2013-11-20 for -06)
No email
send info
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. ?

(Richard Barnes) Abstain

Comment (2013-11-20 for -06)
No email
send info
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.

(Benoît Claise) Abstain

Comment (2013-11-21 for -06)
No email
send info
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.

(Spencer Dawkins) Abstain

Comment (2013-11-21 for -06)
No email
send info
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?

(Brian Haberman) Abstain

Comment (2013-11-20 for -06)
No email
send info
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) Abstain

Comment (2013-11-20 for -06)
No email
send info
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.