Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules

From: Benoit Claise <[email-masked]>
Date: Thu, 13 Feb 2014 16:39:57 -0800

Dear all,

We occasionally see read-write MIB module proposals within the IETF.
However, the write capabilities of those MIB modules are rarely implemented.

While discussing this issue with the MIB doctors, we arrive to the 
conclusion that it's now time to set the direction for future MIB 
developments within the IETF. Basically, let's not specify read-write 
MIB modules unless we have a good reason. Read-only MIB modules are 
still fine though, as SNMP is clearly used for monitoring purposes.

Here is the statement we came up with:

    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, specifically in new
    charters. SNMP MIB modules 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.

Ideally, this should become an IESG statement.
Your feedback is most welcome.

Regards, the MIB doctors & Benoit

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Feb 2014 06:39:00 +0000

Thanks Benoit, this is definitely a step in the right direction.
As a chair of WGs outside the OPS area, I'd still like to see additional guidance around
notification/logging mechanisms as well (IPFIX vs Syslog vs SNMP traps/informs, etc.)

So carry on and I would like to see more.

Thanks,
-Dave

From: OPS-AREA [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, February 13, 2014 4:40 PM
To: [email-masked]
Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules

Dear all,

While discussing this issue with the MIB doctors, we arrive to the conclusion that it's now time to set the direction for future MIB developments within the IETF. Basically, let's not specify read-write MIB modules unless we have a good reason. Read-only MIB modules are still fine though, as SNMP is clearly used for monitoring purposes.

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, specifically in new charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 09:46:17 +0100

On Fri, Feb 14, 2014 at 06:39:00AM +0000, Dave Thaler wrote:

> As a chair of WGs outside the OPS area, I'd still like to see
> additional guidance around notification/logging mechanisms as well
> (IPFIX vs Syslog vs SNMP traps/informs, etc.)

This is much harder. Here is how I see things:

IPFIX works well for large amounts of notification/logging data that
has a common structure, i.e. you get things reported with a few IPFIX
templates. SYSLOG works well with semi-structured data - traditionally
there was very little common structure and the value was in the
free-form text field. SNMP again works with structured data that is
defined in data models (which is different from many IPFIX templates
that IPFIX data processors are expected to discover at runtime,
although I am aware of I-Ds trying to nail down IPFIX templates).

Both, SYSLOG and SNMP notifications have seen many years of wide
spread deployment, IPFIX for notification/logging is more a new kid on
the block. IPFIX may have nice performance characteristics but most
management systems I have seen support SNMP notifications and/or
SYSLOG messages to extract notification/logging data but not IPFIX. I
believe what is widely deployed today (and feel free to prove me
wrong) is largely SYSLOG and SNMP for notification/logging data.

What I am saying here is that the situation is less clear cut compared
to SNMP for persistent configuration.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 14 Feb 2014 15:34:09 +0100

Hello Benoit,

We have a use case that might end up in an IETF RFC, which involves
updating a small set of data very frequently (2 times/sec).

It is kind of on the border of configuration and SDN/routing.

What would be a good protocol for this purpose? Is it still Netconf,
or a custom protocol?

regards Balazs

On 2014-02-14 01:39, Benoit Claise
wrote:

Dear all,

We occasionally see read-write MIB module proposals within the
IETF.

However, the write capabilities of those MIB modules are rarely
implemented.

While discussing this issue with the MIB doctors, we arrive to the
conclusion that it's now time to set the direction for future MIB
developments within the IETF. Basically, let's not specify
read-write MIB modules unless we have a good reason. Read-only MIB
modules are still fine though, as SNMP is clearly used for
monitoring purposes.

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,
specifically in new charters. SNMP MIB modules modifying
persistent configuration state should only be produced by
working groups in cases of clear utility

_______________________________________________
OPS-AREA mailing list
[email-masked]
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-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 15:36:31 +0100

On Fri, Feb 14, 2014 at 03:34:09PM +0100, Balazs Lengyel wrote:
>    What would be a good protocol for this purpose? Is it still Netconf, or a
>    custom protocol?

Are the updates persistent or are you modifying operational state?

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 14 Feb 2014 15:37:36 +0100

The updates are not persistent, they are operational state.
Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 14 Feb 2014 15:55:59 +0100 (CET)

> The updates are not persistent, they are operational state.

If you want to model your data in a MIB, it seems SNMP works fine for
this use case.

If you want to model your data in YANG, a "custom rpc" can be defined
for the data modification, and NETCONF or RESTCONF can be used to
invoke the custom rpc.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 14 Feb 2014 15:58:18 +0100

> The updates are not persistent, they are operational state.

The statement starting this thread was primarily about persistent
configuration state. And the basic NETCONF options do not modify
operational state, as you know (but of course one can add new
RPCs). But you asked Benoit, so I will let him answer. ;-)

/js

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 14 Feb 2014 09:59:57 -0500

Hi,

I agree we could provide some guidance on notification/logging mechanisms. 

Here's how I see things:

The Syslog community insisted on maintaining the freeform text fields when
the IETF developed a standardized message format. 
The Syslog WG developed the SDE format to provide more structured and
standardized data to supplement the freeform text.
There have been few SDEs standardized in the IETF, and they tend to be
singletons rather than cohesive data models.
Since humans are good at interpreting freeform text, but applications
typically have difficulty with freeform text, Syslog is good for uses where
a human will be looking at the messages. Sys-logs can be filtered by
priority and word-matching techniques to lessen the onerous task of finding
relevant messages in the stream, but it comes down to human review and
interpretation, typically at the device/endpoint level.

I don't work with ipfix, but had some experience with one of the candidate
protocols that led to ipfix. 
My impression of ipfix is that it is really better at three major things
than SNMP and Syslog:
1) capturing and reporting large quantities of potentially short-lived data,
such as the creation and deletion of IP flows or NAT bindings, and
2) offloading large amounts of data quickly and reliably, since it works
over streaming sessions, and
3) efficiency, since it uses templates rather than self-identifying varbinds
or full syslog messages, cutting message overhead.

SNMP provides standardized objects organized into data models using OIDs,
that can be hard for operators to understand, but easier for applications to
process. SNMP applications can correlate standardized data models across
multiple devices, can initiate a poll in response to a notification to get
more information, and can correlate notifications with polled information
(often including historic polled data). 
SNMP applications can also act upon its data analysis by automated
modification of configurations using RW objects, where supported. SNMP
notifications end up being useful for large-scale automated management, and
for network management applications rather than just device management
applications, because SNMP is not only notification/logging, but an
integrated package of notification/logging + polling + cohesive data models
consistent across vendors + (where available) automatable SET capability.

David Harrington
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Friday, February 14, 2014 3:46 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules
>

---

From: t.petch <[email-masked]>
Date: Fri, 14 Feb 2014 15:02:06 +0000

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 14, 2014 12:39 AM
implemented.
> Your feedback is most welcome.

You probably know that there is currently a consensus call in progress
over

"Please indicate Support or Oppose for this MIB
(draft-ietf-mpls-tp-te-mib) to be read-only."

and I was pleasantly surprised to see opposition, albeit with one
opponent later changing their mind (perhaps they were sat on from a
height:-).  I don't see much sign of Netxxxx in the mpls arena but there
is a need there for configuration, since there need not be a control
plane to set things up.  Perhaps writable MIB modules will still be with
us in the distant future in some corners of the Internet..

Ideally, this idea would be fleshed out in an I-D.

Tom Petch

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 14 Feb 2014 10:24:39 -0500

Hi,

If it is a small set of operational data that needs updating, and if you
want acknowledgement of the change at the receiver, then SNMP SET might meet
your needs, if the targeted environments support SNMP SET. If you only need
acknowledgement of the receipt of the update message, then SNMP Inform might
meet your needs. 

However, if this is updating routing information, then you might do better
to NOT use a layer 7 management protocol like Netconf or SNMP, but a routing
layer protocol to distribute such updates.

If you develop a custom protocol, then you are faced with getting that
protocol implemented and deployed before the solution can be useful. A
custom protocol might be a viable scenario for a solution that works only
within a single vendor’s ecosystem, but is likely to be problematic in a
heterogeneous network, until the protocol is supported across multiple
vendors’ products. You might want to rethink the problem to make it fit into
an existing implemented and deployed infrastructure, such as SNMP or Netconf
or standard routing protocols.

Without more information (and I am not requesting that you turn this thread
into a discussion of your proposal), it is hard to provide advice.

Why don’t you start a separate thread by posting a pointer to a relevant
internet-draft, and ask what would be appropriate for that use case?

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: OPS-AREA [mailto:[email-masked]] On Behalf Of Balazs
Lengyel
Sent: Friday, February 14, 2014 9:34 AM
To: Benoit Claise; [email-masked]
Cc: Attila Mihály
Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
NETCONF/YANG modules

Hello Benoit,
We have a use case that might end up in an IETF RFC, which involves updating
a small set of data very frequently (2 times/sec).
 It is kind of on the border of configuration and SDN/routing.
What would be a good protocol for this purpose? Is it still Netconf, or a
custom protocol?
regards Balazs

On 2014-02-14 01:39, Benoit Claise wrote:

Dear all,

While discussing this issue with the MIB doctors, we arrive to the
conclusion that it's now time to set the direction for future MIB
developments within the IETF. Basically, let's not specify read-write MIB
modules unless we have a good reason. Read-only MIB modules are still fine
though, as SNMP is clearly used for monitoring purposes.

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, specifically in new charters. SNMP MIB modules
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.

---

From: "Joan Cucchiara" <[email-masked]>
Date: Fri, 14 Feb 2014 13:27:35 -0500

Hi Tom,

As the MIB Dr. on this draft,  I have responded on the MIB Dr. thread that I
do NOT see a way to make this draft (draft-ietf-mpls-tp-te-mib) read-only.
This draft contains extension tables for tables in LSR and TE MIBS which are
created by RowStatus (which is read-create).   Like it or not, RowStatus of
those MIBs (i.e. LSR and TE MIBs) effect the rows in the extension tables of
this draft (think the case of row creation or row deletion).   That is an
SNMP Set operation which effects the draft.

I believe the statement that Benoit puts forth would allow for such a
situation as this draft, specifically:

"... SNMP MIB modules 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."

Perhaps, additional wording, such as "For example, in the case of proposed
SNMP MIB modules which extend or augment rows that are created by
configuration in a SNMP MIB module which is already a RFC, the proposed SNNP
MIB modules will be grandfathered, if the working group finds consensus to
do so."

However, I am okay with the statement as written.

Thanks,
  -Joan 

-----Original Message-----
From: OPS-AREA [mailto:[email-masked]] On Behalf Of t.petch
Sent: Friday, February 14, 2014 10:02 AM
To: Benoit Claise; [email-masked]
Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
NETCONF/YANGmodules

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: <[email-masked]>
Sent: Friday, February 14, 2014 12:39 AM
implemented.
> Your feedback is most welcome.

You probably know that there is currently a consensus call in progress over

and I was pleasantly surprised to see opposition, albeit with one opponent
later changing their mind (perhaps they were sat on from a height:-).  I
don't see much sign of Netxxxx in the mpls arena but there is a need there
for configuration, since there need not be a control plane to set things up.
Perhaps writable MIB modules will still be with us in the distant future in
some corners of the Internet..

Tom Petch

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3705/7092 - Release Date: 02/14/14

---

From: "ietfdbh" <[email-masked]>
Date: Sat, 15 Feb 2014 11:35:59 -0500

Hi Benoit,

I think the statement fails to provide advice about whether WGs should
produce read-only MIB modules for monitoring.

Your intro to the statement says it's still fine, but the statement itself
does not.

David Harrington

+1-603-828-1401

From: OPS-AREA [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, February 13, 2014 7:40 PM
To: [email-masked]
Subject: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG
modules

Dear all,

---

From: Andrew Donati <[email-masked]>
Date: Sat, 15 Feb 2014 14:58:05 -0500

A

> On Feb 15, 2014, at 11:35 AM, "ietfdbh" <[email-masked]> wrote:
> 
> Hi Benoit,
>  
> I think the statement fails to provide advice about whether WGs should produce read-only MIB modules for monitoring.
> Your intro to the statement says it’s still fine, but the statement itself does not.
>  
> David Harrington
> [email-masked]
> +1-603-828-1401

---

From: [email-masked]
Date: Sat, 15 Feb 2014 20:05:01 +0000 (UTC)

I agree with Dave. Even though it may already be implied, the statement should explicitly state that read-only MIB modules can be produced for monitoring. 
- Andy 

----- Original Message -----

From: "ietfdbh" <[email-masked]> 
To: "Benoit Claise" <[email-masked]> 
Cc: [email-masked] 
Sent: Saturday, February 15, 2014 11:35:59 AM 
Subject: Re: [OPS-AREA] configuration: writable MIB modules versus NETCONF/YANG modules 

Hi Benoit, 

David Harrington 

[email-masked] 

+1-603-828-1401 

Dear all,

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 15 Feb 2014 17:51:38 -0500

Indeed. We should not discourage that - even implicitly. 

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Sun, 16 Feb 2014 07:54:54 -0800

Hi,

I think this recommendation should just say that it applies only
to SNMP for configuration.  I don't want it to say "SHOULD use
NETCONF for configuration and (MUST/SHOULD) use SNMP
for monitoring."

In NETMOD WG, we started down this path for interfaces
and some vendors said "give us the counters in NETCONF.
We have no plans to implement SNMP in our device for anything."

I think NETCONF and IPFIX are good monitoring candidates,
better than SNMP by some metrics, and worse by other metrics.
A WG should weigh all factors and make the best choice for their
situation.  A 1-size-fits-all policy is not that helpful here.

Andy

On Sat, Feb 15, 2014 at 12:05 PM, <[email-masked]> wrote:

> I agree with Dave.  Even though it may already be implied, the statement
> should explicitly state that read-only MIB modules can be produced for
> monitoring.
> - Andy
>
> ------------------------------
> *From: *"ietfdbh" <[email-masked]>
> *To: *"Benoit Claise" <[email-masked]>
> *Cc: [email-masked]
> *Sent: *Saturday, February 15, 2014 11:35:59 AM
> *Subject: *Re: [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG        modules
>
> Hi Benoit,
>
>
>
> *From:* OPS-AREA [mailto:[email-masked]] *On Behalf Of *Benoit
> Claise
> *Sent:* Thursday, February 13, 2014 7:40 PM
> *To:* [email-masked]
> *Subject:* [OPS-AREA] configuration: writable MIB modules versus
> NETCONF/YANG modules
>
>
>
> Dear all,
>
> configuration. IETF working groups are therefore encouraged to use the
> NETCONF/YANG standards for configuration, specifically in new charters.
> SNMP MIB modules modifying persistent configuration state should only be
> produced by working groups in cases of clear utility

---

From: Simon Leinen <[email-masked]>
Date: Mon, 17 Feb 2014 10:39:26 +0100

>     configuration. IETF working groups are therefore encouraged to
>     use the NETCONF/YANG standards for configuration, specifically
>     in new charters. SNMP MIB modules 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.

> Your feedback is most welcome.

Agree - it's time for such a statement, and this is a good one.
It doesn't make any recommendations about monitoring or notifications.
I think that (absence) is also appropriate at this point.
-- 
Simon.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Feb 2014 10:54:05 +0100

> I think that (absence) is also appropriate at this point.

I agree that it is a feature to be silent about things this statement
is not talking about.

/js

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 17 Feb 2014 11:08:40 +0100

Agree

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 17 Feb 2014 10:19:17 +0000

+1

Dan

> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Bert
> Wijnen (IETF)
> Sent: Monday, February 17, 2014 12:09 PM
> To: Simon Leinen; Benoit Claise; [email-masked]

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 17 Feb 2014 14:20:09 -0500

+ 1

-Joan

-----Original Message-----
From: OPS-AREA [mailto:[email-masked]] On Behalf Of Romascanu,
Dan (Dan)
Sent: Monday, February 17, 2014 5:19 AM
To: Bert Wijnen (IETF); Simon Leinen; Benoit Claise; [email-masked]
Subject: Re: [OPS-AREA] configuration: writable MIB modules versus
NETCONF/YANG modules

+1

Dan

> > I agree that it is a feature to be silent about things this 
> > statement is not talking about.
> >
> > /js
> >
> 

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3705/7098 - Release Date: 02/16/14

---

From: Dave Thaler <[email-masked]>
Date: Mon, 17 Feb 2014 19:22:55 +0000

> Sent: Monday, February 17, 2014 1:54 AM
> To: Simon Leinen
> Cc: [email-masked]
> I agree that it is a feature to be silent about things this statement is not
> talking about.
> 
> /js

It may be a feature to the OPS area, but it is not a feature as far as the audience
of the statement is concerned (I speak as one of the latter, and one who's asked
for a statement about notifications).

It sounds like the silence is due to lack of any consensus or simple answer.
The lack of a simple consensus answer is a problem, not a feature.
But that's the current world we live in.

-Dave

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 17 Feb 2014 18:40:41 -0500

I don't think remaining silent is a feature, when WGs have asked for
guidance.

David Harrington
[email-masked]
+1-603-828-1401
> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Dave
> Thaler
> Sent: Monday, February 17, 2014 2:23 PM
> To: Juergen Schoenwaelder; Simon Leinen
> Cc: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Feb 2014 16:06:52 -0800

Hi,

Note that none of the people asking for more text have provided any
proposed changes.

   WGs should use the monitoring protocol(s) that best fit their
requirements.

How's that?

Not sure it is worth the effort to create a cookbook
for all possible requirements that could occur, or
try to give meaningful guidance in 1 or 2 sentences.

Andy

On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh <[email-masked]> wrote:

> is
> not
> > It may be a feature to the OPS area, but it is not a feature as far as
> the
> > audience
> > of the statement is concerned (I speak as one of the latter, and one
> who's
> > asked

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Feb 2014 01:20:27 +0100

> RPCs). But you asked Benoit, so I will let him answer. ;-)
No perfect answer at this point.
However, Martin provided a good summary.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Feb 2014 01:25:20 +0100

Hi Tom,

The important questions are:
- will the writable aspects of the MIB module be implemented by the 
vendors (basically requested by the operators)?
- will the writable aspects be used by the NMS'?

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Feb 2014 01:38:38 +0100

Dear all,

As pointed by Simon, Jürgen, Dan, Bert, Joan, yes, it was a feature not 
to speak about monitoring in this statement. If we do, then why not 
Fault, Accounting, Performance?
If we take on the task to specify all FCAP aspects, this will be too big 
of a job for an IESG statement. However, as I mentioned multiple times, 
I'll work on this ... I have 2 years (to try) to achieve that. I foresee 
a lot of discussions.

So, I would prefer to keep this statement purely for configuration.

Regards, Benoit.
> On Mon, Feb 17, 2014 at 3:40 PM, ietfdbh <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>
>     +1-603-828-1401
>     > From: OPS-AREA [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Dave
>     > Thaler
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > > From: OPS-AREA [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Juergen
>     > > Schoenwaelder
>     > > Cc: [email-masked] <mailto:[email-masked]>
>     standards for
>     statement is
>     > It may be a feature to the OPS area, but it is not a feature as
>     far as the
>     > audience
>     > of the statement is concerned (I speak as one of the latter, and
>     one who's
>     > asked
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Feb 2014 08:15:19 +0100

>    WGs should use the monitoring protocol(s) that best fit their

I do not see the value of such a statement since I assume this to be
the default for any protocol selection.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Feb 2014 08:27:59 +0100

> I don't think remaining silent is a feature, when WGs have asked for

I do not think David's protocol selection problem warrants an IESG
statement. Protocol selection is a question that many WGs face. It
continue to believe that it is a feature that the proposed IESG
statement stays focused.

If people believe there could be an IESG statement concerning
notifications, go ahead and draft text, start a discussion thread and
build consensus around it.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 17 Feb 2014 23:55:17 -0800

> the default for any protocol selection.
OK -- so no need for any statement on monitoring since there are no specific
recommendations to make.

Andy

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Feb 2014 09:00:39 +0100

On 18/02/2014 08:55, Andy Bierman wrote:
>
>
>
> On Mon, Feb 17, 2014 at 11:15 PM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
Exactly.

Regards, Benoit

---

From: t.petch <[email-masked]>
Date: Tue, 18 Feb 2014 10:30:51 +0000

----- Original Message -----
From: "Benoit Claise" <[email-masked]>
To: "Andy Bierman" <[email-masked]>; "ietfdbh" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, February 18, 2014 12:38 AM

> Fault, Accounting, Performance?

Because we already have 45 pages gently maturing on the topic
(draft-ietf-opsawg-oam-overview)?

I think that that I-D well demonstrates the challenges of producing
satisfactory guidance on the work of the IETF.

Tom Petch

> >     > > > >     configuration state should only be produced by
working
> >     groups in
> >     > It sounds like the silence is due to lack of any consensus or
simple
> >     answer.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 18 Feb 2014 08:52:00 -0500

> On Feb 18, 2014, at 2:15 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

	What we need is a statement as Benoit proposed because there is a *defacto* and implicit statement that WGs should use SNMP for management - just look at most charters. 

	--Tom

---

From: Warren Kumari <[email-masked]>
Date: Tue, 18 Feb 2014 17:08:53 -0500

On Mon, Feb 17, 2014 at 7:25 PM, Benoit Claise <[email-masked]> wrote:
> - will the writable aspects of the MIB module be implemented by the vendors
> (basically requested by the operators)?

Who knows if it would be implemented by the vendors, but I'm sure most
operators would refuse to use it.
As a test I just proposed enabling SNMP write and got some good
giggles (actually I got a "Good plan! Do  it with snmpv1, no one uses
that.", but I'm not really able to convey the sarcasm / mocking tone
in mail).

I know of no large operator / network that allows write access -- I
suspect that the risks are not really as bad as folk make out, but it
has become network lore that snmp write is bad mojo and once something
becomes lore...
Things may be different in the enterprise space (I think ciscoworks
tries to use snmp write). Oh, and Bay Network's Site Mangler used to
-- which is why most people used BCC...

W

>>>      charters. SNMP MIB modules modifying persistent configuration
>>
>> state
>>>
>>>      should only be produced by working groups in cases of clear
>>
>> utility
>>>

---

From: t.petch <[email-masked]>
Date: Thu, 20 Feb 2014 09:37:14 +0000

----- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: "Benoit Claise" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, February 18, 2014 10:08 PM
> > - will the writable aspects of the MIB module be implemented by the
vendors
> has become network lore that snmp write is bad mojo and once something

I say again, go look at the mpls list, where
draft-ietf-mpls-tp-te-mib
has been returned to the WG to consider the question of making it
read-only, and several have spoken up against.  They are of course
speaking as individuals and are not speaking for operators, or
manufacturers, but they are a constituency in favour of writable MIB
modules.

And yes, I have in the past worked with enterprises who configure with
SNMP (with security provided other than by SNMP).

Tom Petch

IETF.
> >>> developments within the IETF. Basically, let's not specify
read-write

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 20 Feb 2014 09:50:05 -0500

> SNMP (with security provided other than by SNMP).

	How many of those few enterprises that enable snmp writes do you think run MPLS-TP? 

	--Tom

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 20 Feb 2014 07:15:04 -0800

A little late to this discussion, but...

> although I am aware of I-Ds trying to nail down IPFIX templates).

I've been saying for a while that a straight recommendation for "use X
for Y" isn't helpful.  Each of us typically thinks in certain realms,
and by far the IETF considers high-end routers as the core case for most
of their decisions.  But the reality is that the protocols we develop
are used in many many types of devices from embedded systems to high-end
routers to satellites to packet radios to...  And saying uniformly that
"X is best for your Y usage" is simply not the truth.  We've already had
3 sub-threads that have started in this discussion about "um, but is
that true for this particular case?".

I've argued (not enough) for a summary table in the past that compared
and contrasted.  What are the strengths of each protocol?  What are the
weaknesses?  Juergen's last paragraph above is a great start down that road.
Uniformity in a certain class of problems is definitely good.  We don't
want any device to have to implement SNMP, Netconf, IPFIX and Syslog
because 4 working groups chose different tools.  But it may be best for
energy management type devices, which are highly constrained, to choose
one solution while routers to choose another (and in fact, I'd argue
there is no such thing any more as a "small" router).

-- 
Wes Hardaker
Parsons

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Feb 2014 07:47:58 -0800

Hi Wes,

I agree, but I think NETCONF monitoring got left out of Juergen's summary.
NETCONF has 4 main features for monitoring:

   - complete subtree selection: augment data is included in the same
subtree as
     the data being augmented.  This simplifies retrieval for the client
   - XPath filtering: powerful needle-in-a-haystack filtering is possible
with XPath
   - custom RPC operations: dedicated filters for "show" commands allow
     canned (but extremely complex filtering) with little or no effort by
the client
   - control over default leaf retrieval (usually redundant info can be
easily suppressed)

IMO if a WG is designing a NETCONF/YANG solution for some feature,
it should include monitoring and notifications in NETCONF/YANG as well.
I think SNMP makes the most sense for a WG if no configuration
is standardized.

Andy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2014 20:33:27 +0100 (CET)

On Thu, 20 Feb 2014, Andy Bierman wrote:

> IMO if a WG is designing a NETCONF/YANG solution for some feature, it 
> should include monitoring and notifications in NETCONF/YANG as well. I 
> think SNMP makes the most sense for a WG if no configuration is 
> standardized.

My view is that we should try to replace SNMP over time, and netconf/yang 
should be used for monitoring and configuration. I wish SNMP write would 
go away, mainly due to beforementioned security problems. I am not sure 
the current implementation of netconf transport for yang makes sense for 
bulk collection of data, and that's perhaps something that should be 
rectified over time. However, I fully support the initial proposal to 
encourage more netconf/yang usage over SNMP and other configuration 
methods.

Question is, since it's hard to make the working groups create SNMP MIBs, 
it's going to be even harder to make them create yang models (at least 
initially), how is this going to be achieved?

Also, doing models by means of publishing RFCs is kind of heavy process 
approach to achieving a structured model of management. I wish we could 
come up with something a bit more lightweight that would support including 
model extensions within the drafts proposing new behaviour.

For instance, today an author can request protocol number allocations from 
IANA etc. Wouldn't it make sense to have a similar model for extensions of 
yang models?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Thu, 20 Feb 2014 19:42:01 +0000

Wes Hardaker writes:
> I've been saying for a while that a straight recommendation for "use X for Y"
> isn't helpful.  Each of us typically thinks in certain realms, and by far the IETF
> considers high-end routers as the core case for most of their decisions.  But
> the reality is that the protocols we develop are used in many many types of
> devices from embedded systems to high-end routers to satellites to packet
> radios to...  And saying uniformly that "X is best for your Y usage" is simply
> not the truth.  We've already had
> 3 sub-threads that have started in this discussion about "um, but is that true
> for this particular case?".
> 
> I've argued (not enough) for a summary table in the past that compared and
> contrasted.  What are the strengths of each protocol?  What are the
> Uniformity in a certain class of problems is definitely good.  We don't want
> any device to have to implement SNMP, Netconf, IPFIX and Syslog because 4
> working groups chose different tools.

It's worse than that.  The situation today is where the *same* WG had to choose
among 4 different tools.  If there are different people in the WG with drafts
proposing each of the 4 (or more...), there is no guidance to WGs on how to
choose, or whether to adopt all 4 possibilities.  And in that case, a device might
have to implement all 4 people the *same* WG standardized 4 different things.

-Dave (WG chair who's had exactly the above problem occur)

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Feb 2014 11:55:02 -0800

Hi,

On Thu, Feb 20, 2014 at 11:33 AM, Mikael Abrahamsson <[email-masked]>wrote:

> should be used for monitoring and configuration. I wish SNMP write would go
> away, mainly due to beforementioned security problems. I am not sure the
> current implementation of netconf transport for yang makes sense for bulk
> collection of data, and that's perhaps something that should be rectified
> over time. However, I fully support the initial proposal to encourage more
> netconf/yang usage over SNMP and other configuration methods.
>
For now the NETMOD WG is working on standard YANG modules.
I think monitoring would only be done to support a configuration module.
For existing MIB modules, we already have RFC 6643 to provide
a direct (read-only) mapping from SMIv2 to YANG.

> model extensions within the drafts proposing new behaviour.
IMO, the bar is high in the IETF and that's a good thing.
Vendors have to agree on the details. That's always been the
hard part -- not the RFC publication process.

> IANA etc. Wouldn't it make sense to have a similar model for extensions of

Anybody can define their own YANG modules. IANA is not needed
to publish non-IETF modules.

Andy

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Feb 2014 21:13:24 +0100 (CET)

> to publish non-IETF modules.

You completely missed my point. My point was to have yang modules defined 
in the same RFC as the proposed standard was defined in, and that a 
request would go out to some entity to approve the proposed yang model for 
whatever was being standardized. There would be a repository of IETF yang 
models somewhere, and these would no longer be published in RFC form, but 
by some other process. The IANA reference was just an example of existing 
such process/registry.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Feb 2014 12:22:03 -0800

On Thu, Feb 20, 2014 at 12:13 PM, Mikael Abrahamsson <[email-masked]>wrote:

> in the same RFC as the proposed standard was defined in, and that a request
> would go out to some entity to approve the proposed yang model for whatever
> was being standardized. There would be a repository of IETF yang models
> somewhere, and these would no longer be published in RFC form, but by some
> other process. The IANA reference was just an example of existing such
> process/registry.
>
>
I don't see any reason to avoid the RFC publication process for YANG
modules.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 20 Feb 2014 20:09:47 -0800

Dave Thaler <[email-masked]> writes:

> among 4 different tools.

Nope, I understand that.  Because there is no comparison table to help
them pick!
-- 
Wes Hardaker
Parsons

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 20 Feb 2014 20:11:05 -0800

> I agree, but I think NETCONF monitoring got left out of Juergen's

Yes, it's a start.  Not a complete list.

The point is that there are pluses and minuses to each one.  But those
are not spelled out anywhere (especially because each person biased
toward the pluses of their own favorite and the minuses of everyone
else's).
-- 
Wes Hardaker
Parsons

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Feb 2014 09:07:28 +0100

> toward the pluses of their own favorite and the minuses of everyone

This whole NM protocol selection / guidance discussion comes up
periodically. I just found what I wrote down the last time (plus a few
minor modifications).

/js

---

From: t.petch <[email-masked]>
Date: Fri, 21 Feb 2014 09:47:13 +0000

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
To: "Dave Thaler" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 21, 2014 4:09 AM

> Nope, I understand that.  Because there is no comparison table to help

Just like Security, where you and I have been involved in adding
security to an existing IETF protocol and it has been do we use IPsec,
Kerberos, SSL, SSH, .... with no help or guidance from a security
directorate, just an army of WGs each busy working away on its own
thing:-(

The IETF can produced over-arching strategic considerations (or the IAB
can) or the nitty gritty, but in between, we leave a hole.

Tom Petch

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 21 Feb 2014 11:57:48 -0500

Hi,

I agree the biases and claims kind of get in the way of providing good
advice.

It would be good if we had some empirical research to back up our advice.
Has anybody done an analysis of the timing/overhead of repetitive small
queries between Netconf/MIB and SNMP/MIB?
I'd love to see an analysis; unfortunately I don't have the environment to
run such a test.
Can anybody provide such tests?

I would like to see comparisons of 
1) a query for five counters in different tables, plus sysUptime,
2) a query for an initial read of a table with multiple rows of mixed types,
3) a query for an initial read of multiple inter-related tables,
4) a non-initial read of a table focusing on the objects that are likely to
change dynamically in less than a (typical) day.

Does anybody have  other monitoring scenarios that should be tested?

David Harrington
[email-masked]
+1-603-828-1401

> From: OPS-AREA [mailto:[email-masked]] On Behalf Of Wes
> Hardaker
> Sent: Thursday, February 20, 2014 11:11 PM
> To: Andy Bierman
> Cc: [email-masked]

---

From: Benoit Claise <[email-masked]>
Date: Mon, 24 Feb 2014 12:37:54 +0100

On 20/02/2014 16:15, Wes Hardaker wrote:
> weaknesses?
The tables at http://tools.ietf.org/html/rfc6632#appendix-A was a first 
attempt.
Not complete for sure.

Regards, Benoit
> Juergen's last paragraph above is a great start down that road.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 24 Feb 2014 12:48:00 +0100

Hi Mikael,

I share the same concern. If the process to produce RFC-based YANG 
modules is too heavy, then the YANG modules will be defined out of the 
IETF process.  Period.
The good news is that YANG modules (based on some sort of consensus or 
running code) will be defined. The bad news is the IETF will not be 
relevant any longer.

Easing the YANG modules production at the IETF is a top of mind priority.

Regards, Benoit

> You completely missed my point. My point was to have yang modules 
> defined in the same RFC as the proposed standard was defined in, and 
> that a request would go out to some entity to approve the proposed 
> yang model for whatever was being standardized. There would be a 
> repository of IETF yang models somewhere, and these would no longer be 
> published in RFC form, but by some other process. The IANA reference 
> was just an example of existing such process/registry.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 24 Feb 2014 08:16:02 -0500

To be fair, Mikael is partially correct - there are modules being defined outside of the IETF process in external organizations like Open Daylight where the modules are being defined based on actual implementations. It is part of our mission in NETMOD and the other IETF WGs, to help bring these back into the IETF process by helping folks bring them in and have them standardized once real implementations have helped knock out most of the details. This is really not different from how the IETF process is supposed to work: running code, rough consensus.

	--Tom

> On Feb 24, 2014, at 6:48 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Mikael,
> 
> I share the same concern. If the process to produce RFC-based YANG modules is too heavy, then the YANG modules will be defined out of the IETF process.  Period.
> The good news is that YANG modules (based on some sort of consensus or running code) will be defined. The bad news is the IETF will not be relevant any longer.
> 
>> You completely missed my point. My point was to have yang modules defined in the same RFC as the proposed standard was defined in, and that a request would go out to some entity to approve the proposed yang model for whatever was being standardized. There would be a repository of IETF yang models somewhere, and these would no longer be published in RFC form, but by some other process. The IANA reference was just an example of existing such process/registry.
> 
>