Subject: [netmod] Snmp configuration charter addition

From: David Kessens <[email-masked]>
Date: Mon, 14 Nov 2011 19:57:43 -0800

After previous meeting, we discussed a potential addition to our charter for
a datamodel for SNMP engine configuration. We didn't converge quickly on an
appropriate amendment to our charter and the discussion died down over time.

I have reviewed the discussion and would like to propose the
following text:

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.

Please let the working group think how you feel about this text, and if you
don't agree, propose alternative text that addresses your concerns.

David Kessens
netmod co-chair
---

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 14 Nov 2011 21:36:44 -0800

Hi -

> From: "David Kessens" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, November 14, 2011 7:57 PM
> Subject: [netmod] Snmp configuration charter addition
...
> don't agree, propose alternative text that addresses your concerns.

I'm still worried about "meaningful."  As the discussion on the list revealed,
it's not always immediately obvious whether a given legal configuration is
meaningful.  More importantly, one should take care to not dismiss as
"meaningless" a configuration whose utility is not immediately obvious.
The i-d which was cited as background for the discussion prohibited
as meaningless well-formed configurations which have legitimate uses,
thus my concern.  Delete the word "meaningful" and I'd be happy with
the proposed text.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 15 Nov 2011 09:27:26 +0100

On Mon, Nov 14, 2011 at 09:36:44PM -0800, Randy Presuhn wrote:
> 
> I'm still worried about "meaningful."  As the discussion on the list
> revealed, it's not always immediately obvious whether a given legal
> configuration is meaningful.  More importantly, one should take care
> to not dismiss as "meaningless" a configuration whose utility is not
> immediately obvious.  The i-d which was cited as background for the
> discussion prohibited as meaningless well-formed configurations
> which have legitimate uses, thus my concern.  Delete the word
> "meaningful" and I'd be happy with the proposed text.

I like to know your answer to the following two questions.

1 What about SNMPv1 message processing in combination with the USM
  security model? You can configure this with the SNMPv3 MIB tables -
  do you think it is necessary to preserve this capability in the YANG
  data model?

2 We also have other things like the transport endpoints SNMP engines
  are listening on for which there are no standardized configuration
  tables - do you think this should hence be excluded from the YANG
  data model, even though there is operational experience that this is
  useful/necessary to configure?

/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: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Nov 2011 11:19:38 -0800

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, November 15, 2011 12:27 AM
> Subject: Re: [netmod] Snmp configuration charter addition
>

Yes, but it's only needed for the products that permit such pathological things.

(My concern was that the I-D prohibted things that were not pathological at all,
but were in fact well-defined and common operational practice.)

Wes has already commented on the (deplorable, in some cases)
semantics associated with such pathological configurations, but the reality
is that they exist.  I think the YANG modelers need to figure out for
themselves how/whether they want to account for the differences
in what various products allow.  If the decision is to exclude certain
vendors' products from being supported by the Yang models, it
needs to be a conscious decision by the WG.

This problem is hardly specific to SNMP engine configuration.  The point
is that the YANG model needs to permit everything that any product
would allow.

But I'm less concerned about the philosophical debate than the more
fundamental problem that the YANG model in the I-D prohibits things
are in fact well-defined and common operational practice.

>   useful/necessary to configure?

This is indeed useful stuff.  I'd love to have a MIB module for it, too.
Having it only accesible via Netconf would just be pathological.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Nov 2011 21:26:16 +0100 (CET)

Hi,

"Randy Presuhn" <[email-masked]> wrote:
> If the decision is to exclude certain

The question is, in this case and in other cases, what we put in the
standard module.  Vendors can always add to the standard model, if the
standard model cannot express everything their product supports.

> is that the YANG model needs to permit everything that any product

I disagree (in the general case).  The standard YANG model does not
have to be (should not be) the union of every conceivable parameter
vendors can come up with.

> Having it only accesible via Netconf would just be pathological.

Do you believe this in general?  Do you think that for every YANG
model we produce, we also need a MIB module for the same thing,
otherwise we should not do the YANG model?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 15 Nov 2011 13:14:37 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
...
> otherwise we should not do the YANG model?

In the particular context of this discussion on the problem of configuring
SNMP engines, to add configuration elements without ensuring that
they are also accessible via SNMP seems dysfunctional at best.

The ironic deficiences of the MIB models for configuring SNMP engines
are tied up in history (a little) and politics (a lot).  I don't think it's helpful
to try to turn whatever way the group does (or does not) deal with these
peculiarities into any sort of general principle.

At the risk of going into a discussion that won't bring this thread to
a conclusion, I think we need to remember an important distinction:

   - Using different protocols and / or data models to manage the same
     information model

  - Having multiple information models with intersecting semantics, ie.,
    hooks into the same instrumentation

This work seems to be being driven in the latter direction.  That seems
ironic to me, because one of the "selling points" of this work seemed to have
been its ability to document / work with whatever models vendors had
already implemented, rather than just procrustean MIBs.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Nov 2011 09:24:59 +0100

> but were in fact well-defined and common operational practice.)

I understand what I think your concerns are and I do believe the
document is going to change.
 
> needs to be a conscious decision by the WG.

And here is my point: The WG finally needs to reach concensus on the
deliverable and then there is the whole process that follows it. By
having somewhat fuzzy words in the charter, we express the fact that
we trust the WG to come up with something that is reasonable and
achieves WG concensus.

> are in fact well-defined and common operational practice.

If we can agree on 'common operational practice' I am actually fine.
Shall we replace 'meaningful' with 'common operational practice'?
Both have the same level of vagueness and require the WG to achieve
concensus.
 
> Having it only accesible via Netconf would just be pathological.

I do not mind if there is someone going to write a MIB module for this
- this should actually have happened years ago but apparently the SNMP
community was fine leaving this to proprietary models.

If I read your answer correctly, I hear you saying that you find this
pathological from an SNMP point of view but would not object if it
would happen. Is that correct?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 17 Nov 2011 10:14:59 -0800

Hi -

> Sent: Thursday, November 17, 2011 12:24 AM
....
> Both have the same level of vagueness and require the WG to achieve

I could live with "common operational practice".

...
> community was fine leaving this to proprietary models.

The issue was hotly debated and rather politicized at least as far back
as the SNMPv2 meltdown.

> would happen. Is that correct?

It's not merely pathological from an SNMP point of view.  It's pathological
from both a systems and a network management perspective.  It's probably
not the job of this particular WG to fix it, but it is a symptom of a larger
IETF dysfunction.

As a *modeling* issue, this gets back to the question
of whether the goal is to provide access to a common
underlying information model.  Since some of the netmod
work seems to be an attempt to maintain the useful fiction
of common information models, an approach to consider
might be to put the "additions" like port / interface configuration
into a module of their own, or otherwise formally represent that
they represent an additional package of functionality.

Randy

---

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

> don't agree, propose alternative text that addresses your concerns.

Taking the recent discussion into account, here is a revised version
of the new charter text:

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

Please let the working group know how you feel about this text, and if
you don't agree, propose alternative text that addresses your
concerns.  Since we like to move forward with this (we have been stuck
on this for a while now), please raise any concerns by November 28.

/js

---

From: David Spakes <[email-masked]>
Date: Fri, 18 Nov 2011 11:54:00 -0500 (EST)

> on this for a while now), please raise any concerns by November 28.

Why not just stop the sentence after "modules"?  i.e.,

-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: Phil Shafer <[email-masked]>
Date: Fri, 18 Nov 2011 12:03:37 -0500

>    behavior should be documented.

To keep folks from coming up with "use cases" that are neither
common nor reasonable.  Saying "all" without qualifiers is asking
for trouble.  I was happier with the first wording, which actually
used the word "reasonable".

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Nov 2011 10:01:17 -0800

Hi -

> From: "David Spakes" <[email-masked]>
> To: "Juergen Schoenwaelder" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, November 18, 2011 8:54 AM
...
>     behavior should be documented.

That would be fine with me, but I think we're trying to reach a compromise
here that would allow the WG to introduce incompatibilities when they
are found necessary.  The sticking point is deciding which sorts of
incompatibilities would be tolerable.  Earlier versions set the threshold
at "meaningful", the version proposed uses "operational practice".
I find it quite ironic that "operational practice" appears to be a higher
bar than "meaningful", at least as used in this discussion.

Randy

---

From: David Reid <[email-masked]>
Date: Fri, 18 Nov 2011 14:36:53 -0500

> on this for a while now), please raise any concerns by November 28.

I agree with this proposed text.

-David Reid

---

From: David Spakes <[email-masked]>
Date: Fri, 18 Nov 2011 14:38:23 -0500 (EST)

I see.  Yes, it's a difficult definition to nail down.  What is meaningful
to one deployment may not be meaningful to another deployment.

Current common operational practice, for example, would include the
configuring of USM users that are not members of any VACM group.  Why?
Because they are used for cloning purposes only (RFC 3414, page 40).

Some configurations I have seen are meaningful but only to the deployments
that make special use of them.  For example, I know of one large company
that configures VACM views that are not connected to any VACM group.
Why?  Because they connect the views in a proprietary way to RFC 3413
snmpProxyTable entries, allowing them to conditionally forward SNMP
packets based on the payload.  Packets carrying sensitive data that is
not contained within the authorized view aren't forwarded...it's a nice
little security enhancement.

-dss

On Fri, 18 Nov 2011, Randy Presuhn wrote:

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Nov 2011 12:18:09 -0800

Hi -

> Cc: "David Spakes" <[email-masked]>; <[email-masked]>
> Sent: Friday, November 18, 2011 11:38 AM
...

Excellent points.  Any divergence from what the existing MIBs allow
should be undertaken only with extreme caution.  The language
Juergen proposed seems good enough for compromise purposes,
but will require folks like you, Shawn, Wes, and so on to monitor this
work closely.  As your examples demonstrate, the repercussions of
a change won't always be immediately obvious to those not intimately
familiar with SNMP engines and how they are actually used.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Nov 2011 21:45:08 +0100 (CET)

> on this for a while now), please raise any concerns by November 28.

This text is ok for me.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 18 Nov 2011 21:46:41 +0100 (CET)

Hi,

> little security enhancement.

FWIW, the current document supports both these use cases.

/martin