Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Oct 2010 15:35:01 +0200 (CEST)

Hi,

This draft might be of interest for the WG, even though it is not
covered by our charter.

Chair(s?) - if there is time when we meet in Beijing, we would like to
present this draft.

/martin

Subject: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 18 Oct 2010 07:14:11 -0700 (PDT)

A new version of I-D, draft-bjorklund-netmod-snmp-cfg-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository.

Filename:	 draft-bjorklund-netmod-snmp-cfg
Revision:	 00
Title:		 snmp cfg
Creation_date:	 2010-10-18
WG ID:		 Independent Submission
Number_of_pages: 36

Abstract:
This document defines a collection of YANG definitions for
configuring SNMP engines.

The IETF Secretariat.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Oct 2010 08:47:37 -0700

Hi,

This draft is rather terse wrt/ purpose and fit within the NETCONF standard.
There is 1 sentence:

   Abstract

Since YANG is a data modeling language for NETCONF (it's even in the title),
how is this supposed to be used?  Since SNMP is not widely used for configuration,
why is this work important to NETCONF standardization?  If we have an SMIv2 to YANG
mapping algorithm, why do we need to publish YANG versions of SMIv2 modules?

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Wednesday, October 20, 2010 6:35 AM
To: [email-masked]
Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

Hi,

This draft might be of interest for the WG, even though it is not covered by our charter.

Chair(s?) - if there is time when we meet in Beijing, we would like to present this draft.

/martin

---

From: "David Harrington" <[email-masked]>
Date: Wed, 20 Oct 2010 13:14:50 -0400

Hi,

Andy, You apparently didn't read the draft.
Since SNMP is not widely used for configuration, we need something
else to do that configuration.
Netconf is the IETF-preferred standard for doing configuration. 
This is a yang data model for doing configuration of SNMP engines
using netconf.

The draft seems quite light on text.
I'll do a more thorough review when the document is fleshed out more.

A point I will make is that the feature definitions do not align with
snmpv3 (IETF) compliance requirements.
These feature sets might make perfect sense from an ooperational point
of view.
But you should probably point out that not supporting the feature
might make your configuration non-compliant to the IETF standard. For
example, I think proxy and multiple context support are required as
part of the snmpv3 standard.

Regarding type definitions. If the WG documents will define normative
translations of SMIv2 datatypes for admin-string, identifier,
context-name, etc., it would be better to reference the other
document.

Is there a reason you are using abbreviations in your names? When an
operator reads sec-name, they will not necessarily recognize it as
being snmp-security-name; I think you could imporve the meaningfulness
of your typedefs. 

In Spectrum we avoided the use of "OID" and "ObjectIdentifier" in our
GUI and called it something else ("variable name" or something), and
operators complained because they would need to go to the User's Guide
to see whether the definiiton/semantics of our naming matched the
naming in the SNMP standard. Customers found it so confusing we had to
change our screens to use the naming from the standard. Modifying the
accepted naming should only be done with good reason. Obviously the
change form securityName to security-name has a good reason; chaging
from securityName to sec-name seems much less justified.

I don't know what the identifier typedef refers to. What type of
identifier is this in SNMP terms? is this an OID? see above. if so,
keep in mind that OID is a term from the underlying (managed)
functionality. You want to reflect what you are actually modeling,
because the operator is going to think in the terminology appropriate
to the thing being managed.

Do you have a reference clause in YANG typedefs? that would help a lot
here.

Assuming this is true in yang as well, you might want to echo the fact
that adminstring is measured in octets, not characters (due to
internationalization). I think that might be important enough to
mention in your typdef, rather than relying on the reference to 3411
to make that point.

I'm a bit concerned with defining snmp-agent. SNMPv3 is designed so
that "agent" just refers to a particualr configuration of
snmp-applications within an engine. This is important because it
caused massive problems in SNMPv2 when we tried to add informs, and
had a security mib inside a manager. There is no clear definition of
the difference between an SNMP agent and an SNMP manager and an SNMP
proxy. An "agent" represents the aggregation of certain feature sets
(command-responder, notification-originator, etc.). 

I recommend you focus on configuring the engine, independent of role,
and then confugure specific feature sets. In SNMPv3, we wrote separate
MIB modules to correspond to different functionality/features, such as
USM, VACM, security models, messaging models, transport models, and
applications; these are specific aspects of the underlying managed
technology, much as spanning tree and vlans are aspects of bridging
technology. I recommend against ignoring the underlying design.

You might want to change udp-port to a union of transport protocol and
port. 
If SNMP might use DNS to discover a manager-service, you might also
want to include a service name in the union. This is becoming a fairly
popular thing to do. Since I've been transport AD, I've seen a lot of
things being defined as a service, and then DNS identifies the
address, port, and transport protoocl to use to access the service.
And I notice a new draft to do that.

Is version extensible? (not that I think a new snmp version will be
seen anytime soon, but with things like DNS lookup of an SNMP service
and multiple interfaces and separation of identifier and address in
HIP and LISP, I wouldn't rule it out totally.

enterprise-number - you might want to reference the IANA
enterprise-number registry.

you have a typedef engine-id and a container engine-id. I assume it's
legal in yang, but is that wise?

more later ...

dbh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Wednesday, October 20, 2010 11:48 AM
> To: Martin Bjorklund; [email-masked]
> Subject: Re: [netmod] Fw: New Version Notification for 
> draft-bjorklund-netmod-snmp-cfg-00
> 
> Hi,
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Oct 2010 10:37:59 -0700

David,

I did read the draft.
I don't agree that the IETF needs to provide NETCONF write access to any SNMP data.
These objects have been available in SNMP.  If they were that important,
they would be implemented by now.

I suppose if people want to implement this as a standard they should
work on this draft.  

Andy

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2010 10:15 AM
To: Andy Bierman; 'Martin Bjorklund'; [email-masked]
Subject: RE: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

Hi,

more later ...

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Oct 2010 22:06:04 +0200

> I suppose if people want to implement this as a standard they should

Give me a honest answer: How do you configure your SNMP agent? Via
SNMPv3 sets or via a CLI or config file? Shall we ask operators?

/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: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Oct 2010 22:32:01 +0200 (CEST)

Hi David,

> The draft seems quite light on text.

To put it mildly... :)  We decided to publish what we had, and since
we got these comments from you, I think that was the right thing to
do!

It started out (in the early days of YANG) as an exercise to see what
a configuration model for VACM could look like in YANG, then it grew
to be a complete model for an agent, and now it has actually been
implemented and is used in some products.

> part of the snmpv3 standard.

I agree that the features should match the compliance requirements.
But I think they do.

3413 says:

   A proxy forwarder application forwards SNMP messages.  Note that
   implementation of a proxy forwarder application is optional.

Our feature should use this terminology though, and have a reference to
3413.

3411 says:

   An SNMP entity potentially has access to many contexts.

and I don't think there is anything that says that a particular engine
MUST have more than one context.  There is also no way to configure
contexts over SNMP.

Maybe we should add more features for vacm, usm, (tsm).

> context-name, etc., it would be better to reference the other

Ok.

> being snmp-security-name; I think you could imporve the meaningfulness

Ok.

> from securityName to sec-name seems much less justified.

Ok.

> identifier is this in SNMP terms?

Note that the 'identifier' type is a restricted admin-string:

  typedef identifier { 
    type admin-string {
      length "1..32"; 
    }

It is just a convenient type for a common restriction in these MIBS,
e.g.:

snmpTargetAddrName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(1..32))

snmpTargetParamsName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(1..32))

vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))

etc.

We should at least describe it better, probably rename it.  An option
is to remove it and use the same kind of restriction as in the MIBs.

> is this an OID? see above. if so,

Yes, we can use reference in typedefs; I will add that.

> mention in your typdef, rather than relying on the reference to 3411

No, it is not true in YANG; the string's length restriction is number
of characters.  So the current restriction is not quite correct.  We
have to do something, probably describe the real (number of octets)
restriction in the description clause.

> and then confugure specific feature sets.

Ok.  The focus for us has really been the "agent" part
(obviously...).  I'll think about what we can do.

> In SNMPv3, we wrote separate

I saw that too.  Yes, I agree we need to make this more flexible.

> Is version extensible?

No it isn't.  It could be made extensible, but this enum is simpler,
and even if we'll see a new version someday, it's not likely new
versions will be added often.  So if it happens, this enum must be
revised.

> (not that I think a new snmp version will be

Ok.

> legal in yang, but is that wise?

Yes, it is legal, but you're probably right.

Thanks again for your comments!

/martin

P.S.
I extended the very handy tool 'smistrip' so that it can extract YANG
modules, and actually any code component marked with the convention we
use in the NETMOD/NETCONF specs.  If anyone is interested, it is
available at:

http://www.yang-central.org/twiki/pub/Main/YangTools/rfcstrip

D.S.

---

From: Jon Saperia <[email-masked]>
Date: Wed, 20 Oct 2010 16:45:29 -0400

> SNMPv3 sets or via a CLI or config file? Shall we ask operators?

From what I have seen:

.. it depends on the type of system in my experience.  Some basic systems use things like snmpd.cnf or a variant of that for configuration even though there is full access to the standard MIB Objects for configuration of the SNMP Framework.  That does not mean that there is no CLI access either.  Many systems I have seen support SNMP, CLI and File.  The access method is dependent on how complex the overall system is.  YMMV.

In those cases where there are multiple access methods (the case for most of the systems I know), how the rest of the management environment and NOC is organized are the determining factors.. 

/jon

---

From: Phil Shafer <[email-masked]>
Date: Wed, 20 Oct 2010 17:14:37 -0400

>SNMPv3 sets or via a CLI or config file? Shall we ask operators?

Heck, give an honest prediction:  How will you configure your NETCONF
user and permissions?  CLI, NETCONF, or RADIUS?

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Oct 2010 23:40:53 +0200

> user and permissions?  CLI, NETCONF, or RADIUS?

Perhaps a CLI running over NETCONF to configure how a RADIUS server
validates user credentials. Can I not do this with SNMP? Please. ;-)

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Oct 2010 09:29:04 -0700

Though interesting and I have no objection to actually following it up
and making it happen, I don't think it's the best use of our resources
at this time.  (That being said, if there is people that want to do the
work my opinion is that the IETF should let the work happen rather than
say "no, not at this time).

For myself, though, it would make more sense to concentrate on models
that operators really need the most, like routing, user tables,
firewalls, etc.  Spending time configuring SNMP will likely only delay
working on the real problems people care the most about unless we can do
them all at once.

[on a side note: I sure get a lot of questions from people about
configuring SNMP using SNMP; if no one is doing it, why am I getting
questions?]

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 12:54:36 -0700

On 10/21/2010 09:29 AM, Wes Hardaker wrote:
...
> configuring SNMP using SNMP; if no one is doing it, why am I getting

Ummm, because SNMP is so hard to use for configuration?
Because these particular MIB modules are complicated and non-intuitive?

I can't commit to working on the details on this module,
but I don't mind if it is published.  I agree with Juergen
that having specific modules published in RFCs is forward progress.
This also shows how much more powerful YANG is than SMIv2, which is important.

My concern is that we pull in lots of SNMP baggage by requiring
that new YANG modules be compatible with all existing modules,
which will include this one.  Establishing precedent is extremely
important, and requires attention and resources.  Wasting it
on unimportant content amounts to mis-management.

It turns out that what modules to standardize and in what order
is rather important.  IMO, interface naming has to be first.
Almost every YANG module, including 1 in progress in the IPFIX WG,
needs to refer to interface instances.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Oct 2010 22:43:59 +0200

On Thu, Oct 21, 2010 at 12:54:36PM -0700, Andy Bierman wrote:
 
> which will include this one.

My brain got a segfault on this one.

/js

---

From: David Spakes <[email-masked]>
Date: Thu, 21 Oct 2010 17:42:40 -0400 (EDT)

> This also shows how much more powerful YANG is than SMIv2, which is

In time, the capabilities of YANG that are beyond SMIv2 to model
application data will be commonly exercised in new documents that
are created.  However, IMHO, the wise course of action for the short
term would be to take small steps.

Instead of redesigning "MIB-II" objects in the first go around, I
would suggest writing YANG documents that mirror the existing RFCs
as closely as possible.  Think about vendors who would want to add a
NETCONF server in their product, and then consider how many might
delay that decision because they would have to overhaul their
code that interacts with the stack and kernel to exchange data.

> needs to refer to interface instances.

I agree with Andy here.  At the very least, the working group should
produce a document that is the YANG equivalent to RFC 2863.  IMHO,
it should exactly mirror the existing objects, at least the ones
that are not deprecated.

-dss

-------------------------------------------------------------
 David Spakes                       email:   [email-masked]
 SNMP Research                      voice:   +1 865 573 1434
 3001 Kimberlin Heights Road          fax:   +1 865 573 9197
 Knoxville, TN  37920-9716  USA      http://www.snmp.com
-------------------------------------------------------------

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 Oct 2010 14:31:46 -0700

> My brain got a segfault on this one.

Try parsing this...
I don't want to waste any effort working on SNMP in the NETMOD WG right now.
It is not a high priority, and working on it concurrently with framework
components such as interfaces may be counter-productive.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 22 Oct 2010 11:11:04 +0200 (CEST)

Hi,

David Spakes <[email-masked]> wrote:
> At the very least, the working group should

I disagree.  If all we do is put YANG syntax around existing MIB
objects, we haven't achieved anything.  We should concentrate on
interface configuration.  It is not important to duplicate all
interface counters etc.  One thing that *is* important though is how a
YANG interface configuration model relates to the MIB.  (For example, 
how the interface name maps to ifIndex.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Oct 2010 08:55:00 -0700

Hi,

I agree with Martin.
There should be a new interfaces table that contains a mapping to ifIndex
so monitoring MIBs like RMON-MIB can be used with SNMP, even though the
config may be done through NETCONF.  RMON is an example that supports complete
self-configuration through SNMP, but vendors has decided to configure it through
CLI anyway.

To understand the framework, we have to understand (at least) how an individual
feature would be realized within that framework.

Some requirements (IMO):
  1) Ability to support easy to use YANG module for any service or feature.
     Global and per-interface inter-related components are the norm.
     This must be clear in the data model.
  2) Ability to continue retrieving interface-related operational data with SNMP
  3) Ability to also retrieve operational data with NETCONF
     - mapping algorithm automatically translates any SMIv2 read-only
       OBJECT-TYPE macro into functionally equivalent YANG module, such that
       predictable top-level YANG data nodes, suitable for <get> retrieval,
       are defined.
  4) Ability to let vendors continue using their own interface identification strings
     - Provide optional YANG extension to let vendors describe identifier string components
  5) Ability to identify/configure parent and child interface relationships, 
     if there is some hierarchy within the interfaces. 
     - other interface relationships such as hot-standby, load-balancing, trunking 
       should also be supported
  6) Ability to pre-provision interfaces which are not currently present.
  7) Ability to enable or disable an interface
  8) Ability to move child nodes from one interface to another
     (e.g., move a service, replicate a service, line-card changes slot)

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Friday, October 22, 2010 2:11 AM
To: [email-masked]; [email-masked]
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-snmp-cfg-00

Hi,

/martin

---

From: Jon Saperia <[email-masked]>
Date: Fri, 22 Oct 2010 13:36:00 -0400

The point Martin made about relating the SNMP Model with the YANG based one is important.  The issue is, at least in the SNMP universe, interface naming is not static/stable and not always predictable.  This has always been an issue for management applications even when not attempting to map to an alternate name space such as YANG so mapping counters for an interface with it's YANG based configuration information could be problematic.  Beyond this, most management systems will not keep the core data in either model (SNMP or YANG) they will have an internal data base that is based on their own internal model.  It is not clear to me based on applications I know that this extra mapping is all that helpful since it will have to be redone in the management software application.
/jon

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Oct 2010 16:02:02 +0200

I agree with Andy and Martin on the  approach. This looks like a good
set of requirements to start from. 

Dan
(speaking as a contributor) 

> Sent: Friday, October 22, 2010 5:55 PM
> To: Martin Bjorklund; [email-masked]; [email-masked]
> There should be a new interfaces table that contains a 
> mapping to ifIndex so monitoring MIBs like RMON-MIB can be 
> used with SNMP, even though the config may be done through 
> NETCONF.  RMON is an example that supports complete 
> self-configuration through SNMP, but vendors has decided to 
> configure it through CLI anyway.
> 
> To understand the framework, we have to understand (at least) 
> how an individual feature would be realized within that framework.
> 
> Some requirements (IMO):
> > At the very least, the working group should produce a 
> document that is 
> > the YANG equivalent to RFC 2863.  IMHO, it should exactly 
> mirror the 
> > existing objects, at least the ones that are not deprecated.
> 
> I disagree.  If all we do is put YANG syntax around existing 
> MIB objects, we haven't achieved anything.  We should 
> concentrate on interface configuration.  It is not important 
> to duplicate all interface counters etc.  One thing that *is* 
> important though is how a YANG interface configuration model 
> relates to the MIB.  (For example, how the interface name 
> maps to ifIndex.)
> 
> 
> /martin