Re: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

On Fri, Feb 28, 2014 at 4:06 AM, Benoit Claise <[email protected]> wrote:

>  Dear all,
>
> [I bcc'ed some people, with whom I discussed this issue privately. I want
> to make sure they're in the opsarea loop. Sorry, if you receive this email
> twice]
>
> I discussed the following statement with the IESG. I ideally wanted to
> have this statement approved as an IESG statement before the beginning of
> the week, but I realize that it might need some more discussion among the
> OPS community...
>
> The OPS area recommends the use of NETCONF/YANG standards for
> configuration. IETF working groups are therefore encouraged to use the
> NETCONF/YANG standards for configuration, especially in new charters. SNMP
> MIB modules *creating and* modifying persistent configuration state
> should only be produced by working groups in cases of clear utility and
> consensus to use SNMP write operations for configuration.
>
> Btw, one IESG member insisted on having "*creating and* modifying"
> instead of "modifying".
>
> Let me focus on a more important issue.
> First let me make sure that we agree on one terminology. The NETCONF/YANG
> terminology is in RFC 6244:
>
>   o  Configuration data is the set of writable data that is required to
>       transform a system from its initial default state into its current
>       state [RFC4741 <http://tools.ietf.org/html/rfc4741>].
>
>    o  Operational state data is a set of data that has been obtained by
>       the system at runtime and influences the system's behavior similar
>       to configuration data.  In contrast to configuration data,
>       operational state is transient and modified by interactions with
>       internal components or other systems via specialized protocols.
>
>    o  Statistical data is the set of read-only data created by a system
>       itself.  It describes the performance of the system and its
>       components.
>
> Operational state data is sometimes called ephemeral (or non-persistent
> configuration data), as opposed to the "configuration data" that is
> persistent.
> See RFC 6244 section 4.3.2.x for some useful examples.
>
> The statement has been carefully crafted to cover the 4 different cases:
>
>
>   SNMP                                                         NETCONF/YANG
>
> +-----------------------------------------------------------------+--------------------------------------------------+
>             Configuration data  | SHOULD NOT specify writable MIB modules
>   |  SHOULD use NETCONF/YANG          |
>
> |-----------------------------------------------------------------+--------------------------------------------------|
>      Operational State data  | Not clear guidelines at time point in time
> (*)   |   SHOULD use NETCONF/YANG         |
>
> +---------------------------------------------------------------------------------------------------------------------+
>
>
> Let me focus on (*).
> Some of you are telling: SNMPset is not enabled in networks, period. Don't
> specify new writable MIB modules, even for operational state data, it
> doesn't make sense.
> Some others are telling: Note that this statement limits the discussion to
> configuration data. Note also that there is no standard way to modify
> operational state via NETCONF at this point in time (so it would be strange
> to discourage SNMP if there is no standardized alternative).
>
> I believe we need some more discussion on this specific point.  Please
> share your point of view:
> - Should we keep the statement as it is, but better explain it? (which
> might require more background, so maybe a draft instead of a brief
> statement)
> - Should we extend the statement and remove "persistent" from this
> sentence: SNMP MIB modules creating and modifying persistent configuration
> state should only be produced by working groups in cases of clear utility
> and consensus to use SNMP write operations for configuration?
> - Something else?
>


Unless some WG is asking to use SNMP Set to edit operational state, I don't
see why new work (SNMPv4?) would begin, or even why guidance is needed
in this matter.

NETCONF already supports actions that can change operational state as
a side-effect.  A standard edit function to do the same could be added.
I am more concerned with the security and operational issues related
to editing operational state, than the editing mechanics.
Where is the standard audit log for example?

If we say "SHOULD use (whatever)", then it seems we are saying that
any WG can start creating editable state.  I don't think that is a good
idea.
It would be better to wait and see how it goes with I2RS before making
general guidelines.  IMO a protocol-independent architecture that
properly deals with the interactions between "running config", "ephemeral
config",
"operational state", and "statistics" is needed.



> Regards, Benoit
>

Andy


>
>
>
>
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>
>

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area