IETF conflict review for draft-pfaff-ovsdb-proto
conflict-review-pfaff-ovsdb-proto-02

There's a lot of JSON stuff in there, so I had a look, and it all seems fine from an App Area point of view.

No objection to the classification, but objection to the text (not sure if that makes it a no objection or a discuss)

"The IESG has concluded that this work is related to IETF work done in WGs
TRILL and NVO3, but this relationship does not prevent publishing."

There is related work in I2RS, with the difference that OVSDB management protocol  focuses on switches and I2RS to routers. This is appropriate to mention if someone would think to extend OVSDB management protocol for routers.
There is also related work in NETCONF, as this protocol, which is RPC based is similar to NETCONF.
In the industry, there is a conflict with OF-CONFIG, which is NETCONF and YANG based. NETCONF and YANG are the preferred configuration protocol and data model in the IETF. However, this can't change the conflict review conclusion.

NEW:

"The IESG has concluded that this work is related to IETF work done in WGs
I2RS, NETCONF, TRILL and NVO3, but this relationship does not prevent publishing."



Some more feedback.

-   [DB-SCHEMA]
              "Open vSwitch Database Schema",
              <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf/>.

This points nowhere!
-
      Creation, modification and deletion of OpenFlow datapaths
      (bridges), of which there may be many in a single OVS instance;

OVS instance definition in the terminology would be useful

- opensource:
The abstract mentions that 
   Open vSwitch is an open source software switch designed to be used as
   a vswitch (virtual switch) in virtualized server environments. 
However, it's not clear if the "OVSDB management protocol" is open source as well. My research seems to indicate that this is the case.
That seems an important point to clarify in the draft.
I thought about it when I wonder whether "VMware" should be added in the RFC title, like for many independent submissions.

- I assume that Stewart's comment about asking the WG's
named has been handled.

- Seems odd to just say "use TLS" but not define or pick a
mechanism for client authentication, normally in that case
I'd expect one mechanism at least to be picked for that to
get interop.

However I think that we should look at a process a bit. Surely before we name specific WGs in the deconflict list we should consult the WG chairs lest they know of impacts that we are not aware of.