Last Call Review of draft-ietf-netmod-opstate-reqs-04
review-ietf-netmod-opstate-reqs-04-secdir-lc-kivinen-2016-02-11-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This is terminology and requirements document for handling operational
state. As such the security considerations section cannot have very
detailed problems, but it does properly point out that while
configuration is being applied the device might be in inconsistent
state, and that might cause security issues.

It does not say anything about how the configuration requests needs to
be secured, but I assume that is more in to the actual protocol RFC
issue, than this document.

It does not also comment anything about whether the different states
(intended configuration, applied configuration and derivative state)
should have different security policies to applied to them, i.e.
it does say that it should be possible to retrieve only applied
configuration or only derived state, but does not mention should there
also be different security policies to do those operations. In some
cases the derivative state might contain things like traffic keys
negotiated during the protocol runs, or traffic information aabout
flows passing the devices (privacy issues), so derivative state might
be more sensitive than the actual applied configuration.

Outside the security considerations section the requirement which
says:

       A.  A server MUST support only synchronous configuration
           operations, or only asynchronous configuration operations, or
           both synchronous and asynchronous configuration operations on
           a client-specified per-operation basis.

is bit funny, as it effectively says that either syncronous or
asyncronous MUST be supported and both may be supported, but I do not
understand what the "client-specified per-operation basis" is meaning
for the requirement for server.

Client cannot really require server to change its IMPLEMENTATION on
per-operation basis (i.e., client 1 requesting that server MUST
support only asyncronous operations, and client 2 requesting that
server MUST support only syncronous operations).

Client can use either syncronous or asyncronous if both are supported
by the server, and I assume this is trying to say that client can
select syncronous/asyncronous operation per-operation basis, but when
you are talking about that "A server MUST support ..." I do not think
it is ok to requiring that on a client-specified way.

I.e. proper way would be to say that if server supports both, it MUST
allow client to select which method is used on per-operation basis.
-- 
kivinen at iki.fi