Subject: [MIB-DOCTORS] Fwd: configuration: writable MIB modules versus NETCONF/YANG modules - part 2

From: Benoit Claise <[email-masked]>
Date: Fri, 28 Feb 2014 12:19:46 +0000

Dear all,

Hopefully, you are all part of the ops-area mailer, where the discussion 
should continue.

Regards, Benoit

-------- Original Message --------
Subject: 	configuration: writable MIB modules versus NETCONF/YANG 
modules - part 2
Date: 	Fri, 28 Feb 2014 12:06:07 +0000
From: 	Benoit Claise <[email-masked]>
To: 	[email-masked] <[email-masked]>

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?

Regards, Benoit

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Feb 2014 05:51:59 -0800

Hi,

I think we are entering new territory wrt/ editing what has traditionally
been read-only data.
There have always been "actions with side effects", e.g. a "clear-counters"
operation.
People seem to want a more direct management model, but down in the code it
is basically the same.

The definition of "config data" has a very real impact on YANG XPath.
We explicitly forbid must/when conditionals for config data to reference
non-config data. This is (IMO) due to the perception that config is stable
and operational state is not, and implementing must/when is intractable
if it includes operational state.

>From a security POV, editing operational state seems scary hard.
The opportunities to mess with a system and stay under the radar
are almost unbounded.

So far, the NETCONF community has not even figured out how to
audit all these changes.  How do I know if a hacker set those RIB
entries with I2RS or if a routing protocol did it?  Maybe the I2RS
folks will make better progress on these issues.

I don't think SNMP actually meets many of the requirements
posed by I2RS-ARCH. NETCONF is currently much closer.
Nobody has actually proposed that I2RS use SNMP, so it
is odd that this topic even came up.

Andy

On Fri, Feb 28, 2014 at 4:19 AM, Benoit Claise <[email-masked]> wrote:

> -------- Original Message --------  Subject: configuration: writable MIB
> modules versus NETCONF/YANG modules - part 2  Date: Fri, 28 Feb 2014
> 12:06:07 +0000  From: Benoit Claise <[email-masked]><[email-masked]>  To:
> [email-masked] <[email-masked]> <[email-masked]>
>
> 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]
>
> 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...
>
> 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".
>
> First let me make sure that we agree on one terminology. The NETCONF/YANG
> terminology is in RFC 6244:
>
>             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         |
>
> 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).
>
> 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
>
>
>
>
>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
>
>