Subject: Re: [netmod] Snmp configuration charter addition

From: Wes Hardaker <[email-masked]>
Date: Mon, 05 Dec 2011 10:15:32 -0800

>>>>> On Fri, 18 Nov 2011 06:48:55 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> 5. Data model for configuring SNMP engines. The model must be capable
JS> of representing all SNMP engine configurations possible with the
JS> standard SNMPv3 MIB modules that are common operational practice.

I don't think "common operational practice" can be put in there safely.
Simply put, the IETF has had a miserable time collecting "what is
common" and I don't think anyone in the IETF has a good clue about what
is operationally deployed.  I know that the questions I get on our
mailing lists go far and above what is talked about within the IETF as
"deployed", and I've heard similar statements by folks from SNMP
Research as well.  I'd drop everything after "modules".  Or replace it
with "that are implementable easily using yang".  IE, the whole point of
the previous text was to exclude the requirement to model aspects of the
existing SNMP configuration components that would be a pain under yang
(Note: I'm not blaming yang here; they're simply different and neither
modeling language is at fault).  Instead, just state that: some elements
of the MIB modules may not be implementable in yang, so we won't.  But
we'll document anything that doesn't match properly.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Dec 2011 19:29:27 +0100

> [...] IE, the whole point of the previous text was to exclude the
> requirement to model aspects of the existing SNMP configuration
> components that would be a pain under yang (Note: I'm not blaming
> yang here; they're simply different and neither modeling language is
> at fault).  Instead, just state that: some elements of the MIB
> modules may not be implementable in yang, so we won't.  But we'll
> document anything that doesn't match properly.

I am sorry Wes, but I believe this is pretty much off as far as I
understand the discussion. I am not aware of any YANG limitation that
affects this charter text - please let me know what I might have
missed.

/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: Wes Hardaker <[email-masked]>
Date: Mon, 05 Dec 2011 12:04:33 -0800

>>>>> On Mon, 5 Dec 2011 19:29:27 +0100, Juergen Schoenwaelder <[email-masked]> said:

>> document anything that doesn't match properly.

JS> I am sorry Wes, but I believe this is pretty much off as far as I
JS> understand the discussion. I am not aware of any YANG limitation that
JS> affects this charter text - please let me know what I might have
JS> missed.

What's the point of "that are common operational practice" mean?  Why is
it in there?
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Dec 2011 22:12:16 +0100

> What's the point of "that are common operational practice" mean?  Why is

Instead of repeating the discussion, I suggest you read the mailing
list archive to understand how we got where we are.

Do you object the proposed charter text?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 5 Dec 2011 20:33:49 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, December 05, 2011 10:29 AM
> Subject: Re: [netmod] Snmp configuration charter addition
>

I think Wes has a valid point.  It's a perfectly reasonable requirement for
the YANG models for configuring SNMP engines to be faithful to the
corresponding MIB models, and to permit deviation only in cases where
YANG cannot match the semantics, or can only do so with great difficulty.
If there are no such cases, that would be a good thing.

What has been argued on this list, however, is a desire to "improve" the
models by eliminating possible configurations that from some point
of view are either not useful or "meaningful".  The text currently under
discussion was an attempt to avoid the situation made manifest in the
I-D, where perfectly reasonable and operationally useful MIB
configurations were explicitly prohibited by the YANG model.

The thrust of Wes' argument is that the WG would be skating on very
thin ice. As he wrote:
|  I don't think "common operational practice" can be put in there safely.
|  Simply put, the IETF has had a miserable time collecting "what is
|  common" and I don't think anyone in the IETF has a good clue about what
|  is operationally deployed.

Though I'm no longer "in the business", Wes' comment certainly
seemed to apply when I was, and I don't see how things have changed
in any way that would increase the IETF's chances of getting things
right if the YANG models modified the constraints on what were
"valid" configurations.  I'm still convinced that to be useful as a
configuration management tool, it needs to be able to back up
and restore the any configuration from the set of configurations
that could possibly have been put into effect in the SNMP engine
in question via the MIB interface.

I can live with the proposed language, but only because I'm not
in the business any more and don't care as much about the potential
for disaster, and think that at least some of the people who are active
in the WG recognize the hubris in that language and will be willing to
go out into deployments and verify that the things that end up being
disallowed are in fact not used by any products in the field.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Dec 2011 08:40:18 +0100

> If there are no such cases, that would be a good thing.

There is no YANG problem I am aware of. Can someone please explain
this to me?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Dec 2011 01:49:20 -0800

> There is no YANG problem I am aware of. Can someone please explain

Can someone explain to me why this level of detail is holding up a charter discussion?
Can somebody explain why the normal process of vendors looking out for their own
requirement to meet customer needs will not produce an adequate solution?
If the solution is deficient, a vendor will say "we need knob X because we have
customers that use feature Y".

> /js

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 06 Dec 2011 08:08:00 -0800

>>>>> On Mon, 5 Dec 2011 22:12:16 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> Instead of repeating the discussion, I suggest you read the mailing
JS> list archive to understand how we got where we are.

JS> Do you object the proposed charter text?

I do, because I think its too subjective and unneeded in the first place.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: David Spakes <[email-masked]>
Date: Tue, 6 Dec 2011 11:45:10 -0500 (EST)

The charter determines the guidelines and boundaries for the concept
development.  I believe Wes isn't talking about low-level knobs and
switches but about the philosophy of the design.  I believe Randy
correctly identifies the two general directions that this group could
take:

1. The YANG module(s) could preserve the structure of the USM/VACM MIB
modules.  In brief, the MIB modules define several tables that have
flexible linkage between them.  One table can refer to a single row in
another table by specifying its index.  Or, one table can refer to
multiple rows in another table using tags and tag lists.  This design
is "second generation" because the designers applied lessons learned
from an earlier model (party-party-context, RFC 1441-1447).

2. The YANG module could restructure the MIB tables to try to "improve"
them.  For example, one might consider it an improvement to use nested
tables since YANG supports having a list inside another list.  One might
argue that a user must always be a member of a group so the list of users
should belong inside the list of groups.  This takes us in the direction
of rigid linkage between the tables, reminiscent of party-party-context.

The flexible linkage provided by the current MIB modules has practical
and intentional purposes.  I mentioned in an earlier post that "common
operational practice" includes configuring USM users that are not
connected to any VACM group.  These are used as templates for creating
other USM users without passing the new user's credentials across the
network.  These users represent shared secrets that are required to
make remote administration of SNMPv3 highly secure.

The flexible linkage provided by the current MIB modules has also allowed
vendors to implement features that go beyond the original scope of
USM/VACM.  It is arguable that the YANG document need not be concerned
with this case.

If the above statement stops after "the standard SNMPv3 MIB modules",
it takes us in the direction #1 above (flexible linkage).

If the above statement includes the phrase "that are common operational
practice", it takes us in direction #2 above (rigid linkage).

-dss

On Tue, 6 Dec 2011, Andy Bierman wrote:

> Can someone explain to me why this level of detail is holding up a
> charter discussion? Can somebody explain why the normal process of
> vendors looking out for their own requirement to meet customer needs
> will not produce an adequate solution? If the solution is deficient, a
> vendor will say "we need knob X because we have customers that use
> feature Y".

On Mon, 5 Dec 2011, Wes Hardaker wrote:

> is operationally deployed ... Instead, just state that: some elements

-------------------------------------------------------------
 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: Tue, 06 Dec 2011 09:26:08 -0800

> correctly identifies the two general directions that this group could

OK -- I see your point.

> from an earlier model (party-party-context, RFC 1441-1447).

If you want this approach, then run "smilint -f yang" (or your implementation of smi2yang)
on the desired MIB modules.  It would be a good test of the conversion algorithms.
IMO, this is good enough and there is no point wasting WG resources to hand-convert
SMIv2 modules.

> of rigid linkage between the tables, reminiscent of party-party-context.

I doubt that many vendors want to spend lots of IETF resources refining
YANG data models for corner-case configurations they don't even support
in their CLI.

I thought the point of redoing these data models in YANG was to standardize
the common bits of what vendors support in their products.   YANG should be
used full-strength, if the IETF is going to bother working on data models at all.

> USM/VACM.  It is arguable that the YANG document need not be concerned

If enough people support the feature, it should be in scope.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Dec 2011 18:30:18 +0100

> of rigid linkage between the tables, reminiscent of party-party-context.

As far as I understand, this is not something Martin's I-D actually
does. You can have USM users that are not a member of any VACM groups
and you can have VACM group members that do not exist anywhere as
security names.

I meanwhile believe we would be much better off if we all would be
investing our energy on improving the I-D rather than having abstract
charter discussions. My understanding is that Martin will lift the
current leaf-ref restriction that requires that views exist and which
got the whole discussion started. If there is anything else that needs
changes, please let Martin / the WG know.

/js (writing as a puzzled contributor)

---

From: Andy Bierman <[email-masked]>
Date: Tue, 06 Dec 2011 12:29:05 -0800

> changes, please let Martin / the WG know.

OK -- so this is the source of all the debate:

5. Data model for configuring SNMP engines. The model must be capable of
    representing all meaningful SNMP engine configurations possible with the
    standard SNMPv3 MIB modules. Any differences in functionality and
    behavior should be documented.

This text is flawed because 'must' in sentence 2 does not leave room
for the WG to make judgments wrt/ cost/benefit per feature, etc.
Change 'must' to 'should' and the text is fine.

I don't see how this text in any way provides guidance for the specific YANG module
constructs used in the solution (which is correct).  It seems you guys have been debating
solutions this whole time, not charter text.

IMO, 'meaningful' in the text above implies "configurations used in common deployments",
because our goal is to do common things in a common way.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Dec 2011 13:04:21 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "David Spakes" <[email-masked]>; "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, December 06, 2011 12:29 PM
...
> Change 'must' to 'should' and the text is fine.

Actually, going to "should" would take the charter in precisely the
direction I find objectionable.  I'd want to see *less* wiggle room,
not more, but was willing to go along with the proposed compromise
text just so work could get underway.
 
> because our goal is to do common things in a common way.

I find both too loose for comfort, but having made my case,
I'm willing to live with the latter.  I think the difference between
Wes' position and mine is how much we're willing to trust the
WG to do the right thing when given the opportunity to prohibit
configurations that the MIB model permits.  When Juergen
makes his assurances, I feel like everything will be fine.  When
Andy talks about changing the "must" to a "should", I fear the
worst.  But again, I'm willing to go along with the currently
proposed text because I think I've made my misgivings
sufficiently clear.

Randy

---

From: David Spakes <[email-masked]>
Date: Wed, 7 Dec 2011 11:29:06 -0500 (EST)

On Tue, 6 Dec 2011, Andy Bierman wrote:

> If you want this approach, then run "smilint -f yang" (or your
> implementation of smi2yang) on the desired MIB modules.  It would be a
> good test of the conversion algorithms. IMO, this is good enough and
> there is no point wasting WG resources to hand-convert SMIv2 modules.

I believe than an automatic conversion of these MIB modules to YANG would
NOT work properly.  There are issues that would need to be worked out that
would be worthy of IETF resources.

The best example is the usmUserTable.  You don't configure a user's
authentication and privacy keys simply by pushing them in a protocol
message.  Also, key values are not readable.  The localized keys depend on
the authSnmpEngineID value, which must be unique for each SNMP entity.  A
NETCONF client might expect to be able to do a <get-config> on one device
and an <edit-config> on another device to copy a configuration, and that
simply would not work using an automatically-converted document.

> I thought the point of redoing these data models in YANG was to
> standardize the common bits of what vendors support in their products.
> YANG should be used full-strength, if the IETF is going to bother
> working on data models at all.

That sounds like a worthy goal.  However, if the output of the WG is a
new-and-improved administration framework for SNMP that is implemented in
exactly zero devices in the field, then it will be years before it is
placed into practical use, assuming that ever happens.

Another goal could be to produce YANG modules that closely follow the
existing MIB modules so they could be used to manage the configuration
of existing SNMPv3 engines.  In the short term, this could be done
through a protocol translator that follows special-case procedures
outlined in the document for difficult items like the usmUserTable.
In the longer term, vendors could implement native support more easily
because this approach would help them to maximize code re-use.

> It seems you guys have been debating solutions this whole time, not
> charter text.

I am fairly neutral on this decision.  Either way the WG decides to go,
I imagine that in the coming months I'll be working to implement it.
Obviously, I can't help but think how decisions like this will affect
my implementation and others.  Some choices are difficult to implement,
but they're good for the technology and are worth the effort.  Sometimes
we make choices because they sound good in principle, but in the end the
result is no better than what we started with, so the effort hardly seems
worth it.  It's not clear to me at this point that "YANG should be used
full-strenth" in this particular instance.  This may be the time to
be subtle--to show that YANG can model and fit existing technology
without needing to reinvent it.

-dss

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 Dec 2011 08:49:59 -0800

On 12/07/2011 08:29 AM, David Spakes wrote:
> NETCONF client might expect to be able to do a<get-config>  on one device
> and an<edit-config>  on another device to copy a configuration, and that

Are you saying that a description-stmt could not be written telling client developers
how to use the data model?  You are raising an important point about SMI2YANG.
Converting data modeling languages is only part of the problem.  Using the data model
with NETCONF is also important.  Converting 'SNMP logic' to NETCONF may require
some work.

But since the SMI2YANG mapping is read-only, it is not applicable to this data model.

> without needing to reinvent it.

I think you will find that people without any direct business case for working
on this data model are going to mostly  ignore it.  IMO, there are plenty of experts working
on it (so it will get adequate review), but I don't expect many people will care
about theoretical completeness.

Andy

---

From: David Spakes <[email-masked]>
Date: Wed, 7 Dec 2011 14:29:57 -0500 (EST)

On Wed, 7 Dec 2011, Andy Bierman wrote:

> Are you saying that a description-stmt could not be written telling
> client developers how to use the data model?  You are raising an
> important point about SMI2YANG. Converting data modeling languages is
> only part of the problem.  Using the data model with NETCONF is also
> important.  Converting 'SNMP logic' to NETCONF may require some work.
>

The USM/VACM MIB modules were specifically created to support SNMP
configuration.  There is not much value in polling for these objects.
Their usefulness comes from being able to create and delete rows and
to modify the values.  One could use the SMI2YANG mapping to create a
read-only YANG module, but what would be the point?

Hence, we are discussing the charter for a WG to design the data model
that would allow NETCONF to be able to perform SNMP configuration.  That
data model could be very different, moderately different, somewhat
similar, or very similar to the existing data model defined in SMIv2.
There's nothing to prevent this WG from choosing to create a YANG module
that is identical to the SMI2YANG mapping but with the following changes:

  - read-write and read-create objects are config true, not config false

  - as deemed necessary, make a NETCONF-saavy tweak the to usmUserTable

  - as deemed appropriate, since NETCONF has its own mechanism to
    create and delete rows, do not include RowStatus objects in the
    YANG module, or convert these objects as config false

  - some cosmetic changes as desired, such as converting SnmpTagList
    (space-separated words in a string) to a leaf-list

> I think you will find that people without any direct business case for
> working on this data model are going to mostly ignore it.  IMO, there
> are plenty of experts working on it (so it will get adequate review),
> but I don't expect many people will care about theoretical completeness.

I am a very practical person.  My concept of completeness here is that
an operator is able to switch back-and-forth from using an SNMP-based
configuration tool and a NETCONF-based configuration tool.  Changes made
to the configuration of an SNMP entity by one tool show up nice and neat
in dashboard of the other tool and vice-versa.

-dss

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Dec 2011 11:53:39 -0800

Hi -

> From: "David Spakes" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "Juergen Schoenwaelder" <[email-masked]>; "Randy Presuhn" <[email-masked]>; "David Spakes"
<[email-masked]>; <[email-masked]>
> Sent: Wednesday, December 07, 2011 11:29 AM
...
> in dashboard of the other tool and vice-versa.

If we accept this as a requirement (I think it is an extremely reasonable one)
then an immediate consequence is that  the NETCONF model must allow
all the configurations of the underlying instrumentation that could be set up
by the MIB model.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Dec 2011 21:20:56 +0100 (CET)

Hi,

> simply would not work using an automatically-converted document.

This is one area where the current draft needs more work.  It would be
great to work on this and see what can be done, and your input is very
valuable.  I suspect you have some way to handle this in your tools.

If only we could agree on the charter text so we can work on the
solution...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 07 Dec 2011 12:32:14 -0800

On 12/07/2011 11:53 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "David Spakes"<[email-masked]>
>> To: "Andy Bierman"<[email-masked]>
>> Cc: "Juergen Schoenwaelder"<[email-masked]>; "Randy Presuhn"<[email-masked]>; "David Spakes"
> <[email-masked]>;<[email-masked]>

I hope you are referring only to the snmp-cfg YANG module, and not to all YANG modules
produced by the IETF.

I think most SNMP deployments are now configured with proprietary CLI.
Any new YANG module is going to require new work by a vendor.

It doesn't seem realistic to me that a NETCONF application developer
would do anything special for config that happens to be for the SNMP agent
vs. some other system component.  The server capabilities and NETCONF/YANG specs
will dictate how the application is written.

If there are any SNMP agent configurations which the WG solution does not
properly support, then these issues can be raised on the mailing list.
Supporting config options for component combinations that are not actually
used is kind of a waste of time.  Mandating it in a charter is not going to avoid
any debates on the details.

Andy

---

From: David Kessens <[email-masked]>
Date: Wed, 7 Dec 2011 21:00:20 -0800

> any debates on the details.

And this brings us back to the charter text:

Randy/David: although you are not entirely happy with the current proposal,
can you live with the text under assumption that the working group will take
your contributions and concerns seriously (as we already are supposed to)?

Basically, I much rather have us investing time on the draft itself and work
out any real life differences for the draft than hypothetical issues for the
charter text that might not even arise. A charter item is there to guide our
work but it doesn't have to spell out the whole draft in advance.

David Kessens
co-chair netmod wg
---

---

From: David Spakes <[email-masked]>
Date: Thu, 8 Dec 2011 10:27:39 -0500 (EST)

I said in an earlier post that I was neutral on this issue.  Please don't
hold up a charter text decision on my account.  After the others who
have provided input are content, I'll go along with the group decision.

I'm not certain what is the current proposal at this point.  I really
liked Andy's suggestion to change 'must' to 'should' (with the phrase
about common operational practice discarded).  The text would be:

   5. Data model for configuring SNMP engines. The model should be
      capable of representing all SNMP engine configurations possible
      with the standard SNMPv3 MIB modules.

-dss

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 8 Dec 2011 10:18:12 -0800

Hi -

> From: "David Kessens" <[email-masked]>
> Cc: "Randy Presuhn" <[email-masked]>; <[email-masked]>; "David Spakes" <[email-masked]>
> Sent: Wednesday, December 07, 2011 9:00 PM
...
> your contributions and concerns seriously (as we already are supposed to)?

As I've said multiple times, I can live with the proposal.

I'm no longer in the SNMP business, so to me the cost
of the screwups it's inviting is negligible.  I do think it is
overly optimistic to assume that the WG will find out in
a timely manner about  the consequences of its decisions
to introduce incompatibilities.  The people most familiar
with some of the SNMP engine code bases have been
conspicuously absent from the discussion.  However,
people from the sole dominant vendor seem to be engaged,
so that's probably good enough, and it's probably not a
technical problem if the solution only works with that
vendor's code.  Personally, I have no particular
motivation to follow this work closely, and
certainly can't commit to reviewing the work.

Again, I can live with the current proposal.

Randy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 09 Dec 2011 13:15:56 -0800

>>>>> On Tue, 6 Dec 2011 13:04:21 -0800, "Randy Presuhn" <[email-masked]> said:

RP> I think the difference between Wes' position and mine is how much
RP> we're willing to trust the WG to do the right thing when given the
RP> opportunity to prohibit configurations that the MIB model permits.

Could be.  I tend to like wiggle room in charters because I think you
can work yourself into a corner and it's easier to put the wiggle room
in first so you don't have to change it later.  

[But then, I think the SNMP configuration should be the last thing the
WG works on in the first place; all the rest of the
operational-impacting models should be done first as I think operators
would find them more important to get out soon; but if we're going to
do any of them I think you have to allow for "this is the best we could
do" cases to go forward rather than be blocked by a "must" in the charter]

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 10 Dec 2011 12:25:30 +0100

Dne 9.12.2011 22:15, Wes Hardaker napsal(a):
>>>>>> On Tue, 6 Dec 2011 13:04:21 -0800, "Randy Presuhn"<[email-masked]>  said:
>

Right, it has been my impression, too, that the WG spends a lot of 
cycles on this particular issue that could be better invested in the 
existing charter items.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C