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

Balazs Lengyel <[email protected]> Fri, 28 Feb 2014 13:38:03 +0100
Newsgroups gmane.ietf.ops
Message-ID <[email protected]>
IMHO we should define in Netconf/YANG how to handle operational
state data.

Balazs

P.S. "Ephemeral configuration" is a much better name. It is writable
configuration and it effects how the node behaves. The name
"operational state" carries neither of these two meanings.

On 2014-02-28 13:06, Benoit Claise
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 ].

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?

Regards, Benoit

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

--
Balazs Lengyel Ericsson Hungary Ltd.
System Manager
ECN: 831 7320 Tel: +36-1-437-7320
Mobile: +36-70-330-7909 email: [email protected]

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