Subject: Re: [netmod] snmp configuration data model charter addition

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Sep 2011 22:42:15 +0200 (CEST)

Hi,

[found an old unfinished thread...]

"Randy Presuhn" <[email-masked]> wrote:
> Hi -
> 
> > From: "Martin Bjorklund" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, July 29, 2011 5:33 AM
> > Subject: Re: [netmod] snmp configuration data model charter addition
> >
> > "Randy Presuhn" <[email-masked]> wrote:
> > > Perhaps this is what is meant?
> > >    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.
> > 
> > This is not exactly what the current document tries to do.  It is
> > capabale of representing all "usable" configurations, but for example,
> > the MIBs allow an snmpTargetParamsEntry with:
> > 
> >   snmpTargetParamsMPModel = 0
> >   snmpTargetParamsSecurityModel = 3
> > 
> > but this is not possible in the YANG model.
> > 
> > Here's another example: (copy&pasting from a comment...)
> > 
> > # In some cases, the YANG model imposes stricter constraints on valid
> > # configurations than the corresponding MIB model.  For example, the
> > # leaf "/snmp/community/tag" is a leafref, which means that in a valid
> > # configuration, it MUST refer to an existing target tag, as defined in
> > # ^RFC6020^.  There is no such constraint the MIBs.
> 
> Consider this case:
>    Such a configuration has been put in place using SNMP or other means.
>    (a)  What happens when a NETCONF client attempts to
>           retrieve that configuration?

It would not get these "orphan" parts of the config.

>    (b)  What happens in a configuration backup / restore scenario when
>           NETCONF is the protocol used to shovel the information around
>           using this model?

You will (probably) loose the "orphan" parts.

This only happens if NETCONF and SNMP are used at the same time, on
the same device to configure the engine.

> It seems to me that this fails to meet one of the most basic configuration
> management use cases.

I see your point, but I think the pros outweighs the cons.  In my
experience, such orphan rows have been a source of confusion.  In
some sense the basic configuration use case still applies; when you
take a backup and later restore it, you get the exact same
functionality configured as before.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 7 Sep 2011 17:57:32 -0700

Hi -

> Sent: Wednesday, September 07, 2011 1:42 PM
...
> >    Such a configuration has been put in place using SNMP or other means.
...
> functionality configured as before.

I don't find this persuasive.  I think the difference in our perspectives
is that I consider a reference to a tag which has not yet been instantiated
to be akin to references to a line card which has not yet been installed, rather
than an error, and the losing that information in a backup/restore would be
a serious bug, rather than a feature.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Sep 2011 08:40:05 +0200 (CEST)

> a serious bug, rather than a feature.

I agree that pre-provisioning of e.g. line cards is important, and
that info must not be lost in a backup / restore scenario.  But I
think this use case is a bit different than the SNMP config issue.
The difference is that the line card reference points outside of the
configuration (in this case to a physical resource).  The
tag-reference is internal to the configuration.  If we said that a
line card MUST be present in order to be configured, we have a problem
if the card is temporarily removed, since during that time the config
is invalid.  This is why config references in YANG cannot point to
non-config nodes.

/martin

---

From: David Reid <[email-masked]>
Date: Thu, 08 Sep 2011 10:06:06 -0400

> a serious bug, rather than a feature.

I agree with Randy. I think the yang module should allow the representation
of all possible SNMPv3 engine configurations.

-David Reid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Sep 2011 16:48:46 +0200

> of all possible SNMPv3 engine configurations.

I am not sure I heard Randy asking for all possible configurations. I
heard him talking specifically about tag references. Randy, please
clarify.

The latest proposal for charter text (July 29th) was:

   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.

What this means to me is that for each case where there is not a 1:1
mapping, we need to evaluate whether this causes a restriction on
_meaningful_ SNMP engine configurations. So we would have to take
decisions case-by-case (painful as it might be - but there have been
off-list discussions on some of them).

Are you saying you want that anything I can ever express in the many
SNMP tables must be representable in the YANG interface and you want
to have that stated in the charter update?

/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: Thu, 8 Sep 2011 09:43:18 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "David Reid" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, September 08, 2011 7:48 AM

The specifically disallowed case is in my opinion a clear example of why
the netconf infrastructure shouldn't be second-guessing what a "valid"
configuration is.  From my perspective, if a configuration can be represented
in the SNMP engine's (persistent) local configuration datastore, then, for
the netconf stuff to be useful for configuration management, it MUST be
possible to back up and restore that configuration.

> to have that stated in the charter update?

The problem is the word "meaningful".  The SNMPv3 engine MIBs were
carefully designed so that things like references to non-existent table
rows still have well-defined semantics, and are thus (as far as I'm
concerned) quite meaningful.  Disallowing such references would be
a major change to the semantics.  Perhaps someone could give an
example of a well-formed (from a MIB perspective) but "meaningless"
configuration.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Sep 2011 18:53:20 +0200 (CEST)

> example of a well-formed (from a MIB perspective) but "meaningless"

Previously in this thread I examplified with:

  The MIBs allow an snmpTargetParamsEntry with:

(maybe the DESCRIPTION clause of snmpTargetParamsSecurityModel allows
an agent to reject this; it's not entirely clear.)

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 8 Sep 2011 10:28:08 -0700

Hi -

> Sent: Thursday, September 08, 2011 9:53 AM

If an implementation does not support a particular combination of values,
then the attempt to set snmpTargetParamsRowStatus to active MUST fail.
While I would be surprised if any implementation permitted the combination
you describe, if some implementation *did* permit that combination, I
would expect backup/restore to preserve it, rather than silently deleting it.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Sep 2011 22:14:07 +0200 (CEST)

> would expect backup/restore to preserve it, rather than silently deleting it.

So do you think the requirement is that these combinations must be
possible to do in the YANG data model as well, or is the requirement
that an explicit backup / restore must preserve them?

I also do not think it is obvious that everything you set via SNMP must
be part of a proper configuration backup.  Do you expect volatile rows
be part of the backup (get-config)?  nonVolatile rows that are
notInService?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 8 Sep 2011 19:50:25 -0700

Hi -

> Sent: Thursday, September 08, 2011 1:14 PM
...
> that an explicit backup / restore must preserve them?

I'd like to understand how backup/restore built on Netconf can
violate the corresponding YANG data model.  I'm assuming I'm
missing something improtant here.

> be part of the backup (get-config)?  nonVolatile rows that are

Whether nonvolatile rows are included should be a user option; if such
an option isn't possible, I would not include them in backup/restore.

If a row's RowStatus is notInService, the NOTE WELL on page 16 of
RFC 2579 applies, and it would not be reasonable to assume that a
row in such a state would persist for more 5 minutes if there's not text
to the contrary somewhere in that table's DESCRIPTION clauses.
consequently, I would exclude such rows from backup/restore.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Sep 2011 09:33:33 +0200 (CEST)

> missing something improtant here.

It can't.  I am trying to understand your concern.  I wonder if you
feel it is important to keep the flexibility in these tables, or if
the concern is rather that you expect data set using SNMP be part of a
NETCONF <get-config> operation.

> consequently, I would exclude such rows from backup/restore.

Ok.  So we agree that not everything set over SNMP must be kept in a
<get-config>.

/martin

---

From: David Reid <[email-masked]>
Date: Fri, 09 Sep 2011 10:34:46 -0400

> to have that stated in the charter update?

Yes. But the current proposed charter text does not preclude what I want,
so I have no objection to the proposed text. I prefer the text Randy suggested,
but I'm OK with the current proposed text.

-David Reid

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 9 Sep 2011 10:20:47 -0700

Hi -

> Sent: Friday, September 09, 2011 12:33 AM
...
> NETCONF <get-config> operation.

Neither.  (Though to a very limited degree, both.)

Assuming the purpose of Netconf is to aid in configuration management,
I would like to avoid having the Yang models over-specified in ways that
preclude the backup / restore of perfectly valid configurations.

For that purpose it seems quite reasonable to use RowStatus / StorageType
or text from DESCRIPTION clauses spelling out volatility constraints to decide
how to cull information that might be accessible from the SNMP implementation's
management infrastructure.  What does not seem reasonable is to add
constraints to the models which would cause portions of legitimate
configurations to silently disappear.

...
> Ok.  So we agree that not everything set over SNMP must be kept in a

It's not a question of whether the information came to be by being set using SNMP.
It's a question of avoiding gratuitous incompatibilities between the models
that would sabotage the most basic configuration management functions.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Sep 2011 23:30:45 +0200

> preclude the backup / restore of perfectly valid configurations.

This is only an issue if someone / something configures an SNMP agent
via SNMP and does backup/restore via NETCONF. One could ask whether
this is a common use case.
 
> For that purpose it seems quite reasonable to use RowStatus /
> StorageType or text from DESCRIPTION clauses spelling out volatility
> constraints to decide how to cull information that might be
> accessible from the SNMP implementation's management infrastructure.

Out of curiosity, how do you treat a row with StorageType

     permanent(4),   -- e.g., partially in ROM

if the goal is complete backup/restore via NETCONF?

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 9 Sep 2011 15:12:24 -0700

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, September 09, 2011 2:30 PM
...
> this is a common use case.

I don't know how frequent it would be.  I see it more as an argument from
first principles of what configuration management is about.  If Netconf can't
faithfully do backup/restore of something as straightforward as the SNMPv3
MIBs, I'd be very worried about whether it could be trusted to faithfully
handled more complex / subtle data models from other environments.

> if the goal is complete backup/restore via NETCONF?

I agree some though would need to go into both the permanent
and readOnly cases.  For purposes of doing diffs, backups, and
off-line configuration validation, these values would need to be read
and preserved.  For purposes of doing a restore, the management
application doing the restore would need to assess whether the
rows in question had already been instantiated on the target
system, and, if so, evaluate whether what was there was compatible
with the values to be "restored", and if those rows were absent,
instantiate functionally equivalent rows with a nonVolatile StorageType.
But this is work that needs to be done with *any* existing model
that provides for persistant configuration data, whether using
StorageType, DESCRIPTION text, or totally ad hoc means.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 11 Sep 2011 19:32:11 +0200 (CEST)

> handled more complex / subtle data models from other environments.

This is off-topic, but yes, NETCONF can do backup/restore of any
config data, as long as it can be expressed in XML.  In the case of
SMI data, one problem is that SMI does not have a notion of what is
configuration, so it is not obvious what to include in the
<get-config> reply.  By defining a SNMP engine data model in YANG, we
make it clear what is configuration.

This is, btw, not unique to NETCONF.  You have the same (theoretical)
problem in current CLIs.

The question is not if NETCONF/YANG _can_ do it; it is trivial to do a
1-1 mapping (e.g.; using Juergen's SMI->YANG algorithm, and tweak teh
output model to just do config), but the result is pretty useless.

The issue right now if whether we take the opportunity to make a
simpler data model for configuration, or if we must preserve old model
in all details.

As Juergen stated, the "problem" (I am not convinced this is a real
problem) only occurs if you do config via SNMP, and backup/restore
over NETCONF.  If this is not common, should we really solve it?

And even for the use case where an operator does use SNMP to configure
the SNMP engine, but NETCONF for backup / restore, some rows
(depending at least on RowStatus and StorageType values) will not be
part of the config backup.  So if we clearly document which rows are
part of the config and which are not, I think we have solved this
problem.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 11 Sep 2011 19:16:07 -0700

Hi -

...
> over NETCONF.  If this is not common, should we really solve it?

The problem could also occur for agent-created rows, and for configurations
set by internal APIs, as might be used by the disman MIBs.

> part of the config and which are not, I think we have solved this

"this problem"?
At least three distinct problems have been brought up in this thread.

   (1) identifing the subset of a data model which
         constitutes potential configuration data

   (2) deciding how to use the various possible combinations
         of rowStatus and storageType to determine whether a
         given row should be backed up how to handle restore
         for readOnly / permanent configuration data

   (3) deciding whether use the YANG model to prohibit
         configurations which would be perfectly OK created
         via SNMP

My primary objection was to (3).  The discussion then meandered
into (2), and you now seem concerned about (1).  (1) has already
been dealt with at some length, and I think it is a red herring.
(2) admits solutions that will "do the right thing", though it sounds
like expressing them in YANG would be difficult, if it is even possible,
and would instead have to rely on management application logic above
the netconf protocol.  I'm not terribly worried about it, even though the
details would be a bit gnarly.  I remain convinced that (3) is asking
for trouble.

If this WG believes that fidelity to the capabilities of the SMI-based
models is not a requirement, then the charter should explicitly say so.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Sep 2011 10:02:56 +0200 (CEST)

Hi,

> > part of the config and which are not, I think we have solved this

Yes I meant (3) below.  I agree that (1) and (2) can be handled.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2011 10:23:03 +0200

> StorageType, DESCRIPTION text, or totally ad hoc means.

So can we conclude that unless an application configured a box via
SNMP in the first place, a proper backup/restore of SNMPv3
configuration is in general not possible even with SNMP?

As a matter of fact, there are a number of CLIs for configuration of
SNMP and it seems there is a certain number of networks where SNMP
configuration via interfaces other than SNMP seems attractive. Perhaps
the goal of this work is not backup/restore of a configuration done
via SNMP but instead configuration and backup/restore via NETCONF but
with proper representation to SNMP managers. Does that make sense?

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 12 Sep 2011 07:43:24 -0400

>over NETCONF.  If this is not common, should we really solve it?

So we define rows where RowStatus isn't active as non-configuration
data, just a "work space" for SNMP.  In the same way one can't
backup/restore invalid configs built inside the candidate database
(that would fail any commit operations), one can't backup/restore
the snmp work space.

This means that activating the row makes it become configuration
data, and deactivating the row makes it become non-config data
again.

Hmmm....  perhaps this resembles the "inactive" configuration we
support in JUNOS, where a hierarchy of configuration data can be
deactivated, essentially commenting it out of the data we expose
to JUNOS subcomponents, while keeping the data in the configuration
database.  See CLI session transcript below (where deactivating
netconf removes it from inetd.conf and activating it restores it).
Inactive config is marked with "inactive:" in the CLI and with the
"inactive" attribute in XML.

Thanks,
 Phil

------------
[edit]
user@cli# edit system services 

[edit system services]
user@cli# show 
ssh;
netconf {
    ssh;
}

[edit system services]
user@cli# run file show /var/etc/inetd.conf | match netconf 
netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf
netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf

[edit system services]
user@cli# show 
ssh;
netconf {
    ssh;
}

[edit system services]
user@cli# deactivate netconf 

[edit system services]
user@cli# commit 
commit complete

[edit system services]
user@cli# run file show /var/etc/inetd.conf | match netconf    

[edit system services]
user@cli# activate netconf 

[edit system services]
user@cli# commit 
commit complete

[edit system services]
user@cli# run file show /var/etc/inetd.conf | match netconf    
netconf stream tcp nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf
netconf stream tcp6 nowait/75/150 root /usr/sbin/sshd sshd -i -f /etc/sshd_netconf -o SubsystemOnly=netconf

[edit system services]
user@cli# 

[edit system services]
user@cli# deactivate netconf

[edit system services]
user@cli# show 
ssh;
inactive: netconf {
    ssh;
}

[edit system services]
user@cli# show | display xml
<rpc-reply>
    <configuration>
            <system>
                <services>
                    <ssh/>
                    <netconf inactive="inactive">
                        <ssh/>
                    </netconf>
                </services>
            </system>
    </configuration>
</rpc-reply>

[edit system services]
user@cli#

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2011 14:32:41 +0200

> "inactive" attribute in XML.

I do not think RowStatus is a challenge since all states other than
`active' are transient. In particular, RFC 2579 says:

       - `notInService', which indicates that the conceptual
       row exists in the agent, but is unavailable for use by
       the managed device (see NOTE below); 'notInService' has
       no implication regarding the internal consistency of
       the row, availability of resources, or consistency with
       the current state of the managed device;

Assuming proper usage of RowStatus, rows that are not 'active' can
IMHO safely be ignored.

But I think RowStatus was not really the issue that got us here. I
believe we started from the question whether the YANG data model for
configuring SNMP has to support things like dangling references that
are possible to have in the SNMP tables and whether it has to support
configurations that might be legal to have in SNMP tables but that are
not useful operationally. My feeling was that we likely have to sort
this out on a case by case basis.

And all this is likely coupled with the underlying question whether we
assume there is an SNMP speaking manager creating SNMP configurations
and a NETCONF manager is merely providing a secondary interface or we
assume a NETCONF manager is the primary configuration interface and
what is being created by NETCONF must be properly represented in the
SNMP tables so SNMP speaking managers can understand the configuration
(can carry out certain functions such as key changes etc.). Randy most
likely says both must be equally be possible - and I agree except that
the devel is in the details.

/js (as contributor)

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Sep 2011 14:52:01 +0200 (CEST)

Hi,

> this out on a case by case basis.

If we had Phil's inactive support in NETCONF, we could support these
dangling references, by marking a node with a dangling reference as
'inactive'.  This is very neat.  Unfortunately, 'inactive' is not
standardized :(

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2011 15:23:37 +0200

> 'inactive'.  This is very neat.  Unfortunately, 'inactive' is not

I guess Randy would argue that they are active, just not used at the
moment. For example, an access control policy might be active but
simply not used until an SNMP over SSH sessions comes in with a RADIUS
provisioned mapping to a group name that suddenly makes use of the
"dangling" access control policy. OK, this example is kind of
constructed and the YANG data model does not seem to have a problem
here.

We started from the leafref requirement for some nodes where there is
no requirement that stuff points to existing other stuff in SNMP
land. For example, the vacmAccessReadViewName may be arbitrary
nonsense but YANG says it should be a leafref, that is, it requires
consistency where SNMP does not require it. One option, of course, is
to give up this consistency requirement such that the YANG model can
represent SNMP configurations that happen to have unused references or
references in non-existing definitions.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Sep 2011 15:39:23 +0200 (CEST)

> references in non-existing definitions.

Yes, for leafrefs this is trivial to change - just don't use a
leafref.  My concern is that these dangling references makes the
solution more error prone.  A typo in e.g. a vacmAccessReadViewName
will go undetected.

But for other "valid" configurations it is not that easy.  For example
the mp/security model combination I mentioned earlier:

With the proposed YANG model, this cannot be represented.  (Maybe we
can have a catch-all 'case' in the YANG model:

  case non-sense-config {
    leaf snmpTargetParamsMPModel { ... }
    leaf snmpTargetParamsSecurityModel { ... }
    ...
  }

)

/martin

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 12 Sep 2011 07:48:29 -0700

>>>>> On Sun, 11 Sep 2011 19:16:07 -0700, "Randy Presuhn" <[email-masked]> said:

RP> "this problem"?
RP> At least three distinct problems have been brought up in this
RP> thread.

...

FYI, I'm at the "+1 to everything Randy has said" point, as his
arguments are sound and reflect the reality of what exists is the
current world, whether or not NETCONF wants it to be there.

Rows *do* exist in SNMP tables where the values have dangling
references.  I see them all the time, and they're there by intention
(and the mention of the dangling VACM reference waiting for a RADIUS
connection is a good example, but even more to the point: I've seen
administrators leave references in tables dangling because they want to
use it as a "flip the switch when I need it by adding the missing row
when i want it active").

I've also seen lots of cases where internally to the software the SNMP
table isn't the complete set of config: it's simply the closest they
could do to expose parts of the config that exist in SNMP tables.  There
are other bits laying around in private-data/internal-config that are
either not exposed because there is no MIB objects to expose them in, or
because they're intentionally hidden because the vendor wants those
config bits to be proprietary (a situation I hate, but they do exist to
create vendor-lock-in).  I've seen cases of rows being marked and
created as permanent because they're created internally but are exposed
in part to allow at least some run-time configuration.  The problem is
that netconf's "copy" really isn't designed to handle cases like this.
Especially when the row references change (eg, the ifIndex of the two
devices swap on reboot (yes, I know they shouldn't; but they do in many
implementations)).

I've also seen vendors use "special values" to get around creating their
own private MIBs to house special data in.  And the MPModel = 0,
securityModel = 3 is exactly those types of cases where "because it'll
never exist in the standards world, why don't we just reuse that weird
combination to do something special internal".  Yes, every time someone
asks me if that's ok I do tell them "no".  But unfortunately, not
everyone asks and not everyone listens to the responses they get.

So, I'm sure many people who made it this far into my text are saying
"yes, but half of that argument is about illegal values or values that
shouldn't exist in that combination".  Sure, you're partially right.
Many things shouldn't exist, but often do anyway.

The real question is: until NETCONF achieves market dominance, will you
succeed when you approach a widget, be it an SNMP agent or other object
needing config, and say "we have this great new technology for sending
configuration data around, but it'll require you to limit yourself and
stop your code and your customers from doing what they're doing at the
moment."  Until NETCONF is the elephant that everyone wants, I don't see
this argument succeeding.

More specifically to my particular case: if someone proposed a
allow-NETCONF-config patch to Net-SNMP and wanted it incorporated but it
meant that it'd wipe out all the dangling VACM references and would
fail to work with any permanent rows, I'd be flamed if I tried to
propose accepting it.

But your SNMP configuration example is but the beginning.  In some sense
it's a bad one to start with because of the potential perception of
competing-technologies that may appear to be the root cause (but really
isn't).  If you try to do similar things with any other highly-different
internal models you're likely to run into similar problems.  EG,
configuring firewalls (where permanent rows are common) from 4 different
vendors will likely have the same problem: the models may not act the
way you want them to in an ideal world.

NETCONF needs to make the technology it's trying to instrument easier to
configure without making imposing restrictions on it.  It's up to the
underlying model to define the restrictions, *not* the configuration
protocol.  Yes, this likely means you'll end up with yang models that
are not as restrictive or clean as you'd like.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Sep 2011 17:38:16 +0200

On Mon, Sep 12, 2011 at 03:39:23PM +0200, Martin Bjorklund wrote:
 
> With the proposed YANG model, this cannot be represented.

For me personally, this is clearly an example of a configuration that
is never ever meaningful. If this fails the backup/restore test, fine.
The description of snmpTargetParamsSecurityModel is really interesting:

snmpTargetParamsSecurityModel OBJECT-TYPE
    SYNTAX      SnmpSecurityModel (1..2147483647)
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The Security Model to be used when generating SNMP
          messages using this entry.  An implementation may
          choose to return an inconsistentValue error if an
          attempt is made to set this variable to a value
          for a security model which the implementation does
          not support."
    ::= { snmpTargetParamsEntry 3 }

I love this "may choose to return an inconsistentValue error"
phrase. So apparently an implementation can be compliant by accepting

and in the best case your agent drops this target when trying to send
a message or in the worst case your agent just dies. Would be
interesting to try how existing agents handle this and how many
survive. ;-)

Someone previously asked for an example of a non-meaningful
configuration. For me, this is such an example.

/js (as contributor)

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Sep 2011 18:58:14 +0200 (CEST)

> with proper representation to SNMP managers. Does that make sense?

Yes, I think this makes sense.  What would the charter text be to
cover this?

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 12 Sep 2011 11:18:25 -0700

Hi -

> Sent: Monday, September 12, 2011 1:23 AM
...
> configuration is in general not possible even with SNMP?

No.  The "unless" condition you propose is neither necessary nor sufficient.
In that particular set of pathological cases, the conflict arises due to the
potential for incompatibilities between "hard-wired" portions of the
configuration data on different boxes that are nonetheless sufficiently
similar for configuration portability to be desirable.  There are heuristic
work-arounds, but once one reaches the limits of those heuristics, I think
the conclusion has to be "don't do that", as the things being configured
aren't sufficiently similar to support the management objective.

> with proper representation to SNMP managers. Does that make sense?

It is plausible, but I still object to the idea of introducing gratuitous incompatibilities
into the data models.  In any case where the semantics or constraints in the
YANG model are different from the SMI, there should be an explicit statement
of why the incompatibility is necessary and desirable.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 12 Sep 2011 12:35:37 -0700

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Monday, September 12, 2011 9:58 AM

If folks really want to do this, perhaps something like this might serve
as a rough starting point:

  The YANG models MUST NOT permit configurations the 
  corresponding SMI models would be unable to represent.
  The YANG models MAY be more restrictive than the SMI models,
  but MUST explicitly document why such incompatibilities are
  necessary and desirable, and spell out what happens when
  NETCONF is used to attempt to retrieve, modify, or replace portions
  of a configuration which the SMI can represent but which the
  YANG models for any reason reject.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Sep 2011 15:09:12 +0200 (CEST)

Hi,

>   corresponding SMI models would be unable to represent.

Actually, we do want to cover some things not present in the MIBs,
e.g., the listen address(es).

>   YANG models for any reason reject.

I don't disagree with the meaning of this text, but maybe it is a bit
too detailed for a charter?  Actually, I think the underlying meaning
of this text is covered by Juergen's proposed text:

     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.

In the WG, we need to make sure that we clearly spell out the mapping,
and that any difference in the data model is documented.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Sep 2011 09:37:17 -0700

Hi -

> Sent: Wednesday, September 14, 2011 6:09 AM
...
> e.g., the listen address(es).

The only way I could support this would be if the scope of the work
explicitly included an update to the MIBs to add any such information.
 I think that creating a situation where *neither* protocol is able to
operate on the complete configuration is a recipe for disaster,
and should be carefully avoided.

If such information is added, it should also be acompanied by updates
to RFC 3411, 3412, 3413, RFC 2741, and possibly RFC 1227, since
changes to things like listen addresses need to be carefully serialized
with the elements of procedure in these documents.

> and that any difference in the data model is documented.

I still have a huge problem with "meaningful".  It's far too loose, and, as
Wes has spelled out, the I-D demonstrates that it already has been
understood in ways that are at odds with both the design of the MIBs
and with common operational practice.

But this discussion seems to be looping, so I think I'll bail for now.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 Sep 2011 22:01:03 +0200

> with the elements of procedure in these documents.

Pretty much all SNMP agents I have seen allow to configure the port
they are listening on. Yes, there is no MIB interface to do this. This
situation is out there for +20 years. Are you saying we have to keep
this situation or first define MIB modules in order to do what
proprietary configuration interfaces already provide for +20 years?

> But this discussion seems to be looping, so I think I'll bail for now.

The devil is in the details. Apparently, the MIB modules allow to
configure SNMPv1 with USM. This never ever works. So is it really
useful to allow this in a YANG configuration data model, given that
even the MIB module allows agents to reject this (but does not require
this)? I am in favour of going through the details where there are
differences instead of adopting general rules.

/js (speaking as contributor)

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 14 Sep 2011 18:04:26 -0700

Hi -

> Sent: Wednesday, September 14, 2011 1:01 PM
....
> proprietary configuration interfaces already provide for +20 years?

What I'm saying is that if the opposition to standardization of this
capability has finally gone away after all these years, (alleluia!)
that to do it right, we should be able to do it via a standards-track
MIB interface.
 
....
> differences instead of adopting general rules.

Whether such a combination is rejected or not is implementation-specific,
and as an implementation-specific behaviour, using the model to bless
one implementation while damning another seems like inappropriate
over-engineering, if not outright anti-competitive behaviour.

Since I'm no longer in the business (and the code with which I am most
familiar would probably reject such a setting as an inconsistant value)
I don't really care that much, other than to say this still seems rather unwise.

I'd be less concerned if the implementors of today's widely deployed code
bases were all saying this won't be a problem, and  were all willing to check
against their respective code bases any incompatibilities the WG decided
to add or inadvertantly allowed to creep in.   The SNMP engine people I've
seen in this dicussion (Wes, David Reid, and myself) might be considered
"old guard" due to our association with rather mature code bases, and that
might also explain our lack of support for adding incompatibilies.   Are
there some other folks from the SNMP engine room, perhaps of more recent
vintage, who could speak up, pro or con?

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 15 Sep 2011 08:03:36 +0200

> that to do it right, we should be able to do it via a standards-track

I believe this is a separate issue to discuss and I am not even sure
whether you scope this "requirement" just to SNMP engine configuration
or even want this in more general. As a matter of fact, CLIs on most
devices cover configuration knobs MIB modules do not cover, see also
the discussions back when RFC 3535 was created.
  
> vintage, who could speak up, pro or con?

As far as I know, the YANG module in the I-D (which surely will chance
and likely to reduce differences, e.g. making the leafrefs just
ordinary strings is not a big deal) has been reviewed and discussed
privately with people from large SNMP engine suppliers to find out
whether there are any issues with their code base. And this is what
needs to continue in the WG if this work becomes a WG work item and I
understood that David Reid is going to do that for one SNMP engine
supplier. Wes' statement is not clear to me since he also kind of said
any combination of legal or illegal values might be overloaded with
other semantics and I do not know how to deal with that.

That said, more input to the discussion at this point in time would be
very useful, both from SNMP engine folks but also from operators that
configure today's SNMP engines.

/js