Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

Hi,

I agree with the approach of treating these as separate objects, both as an
SNMP greybeard and as an (ex-)NMS developer.

Following the general philosophy of good MIB design, keep the agent simple
and let the NMS handle complexity.
That is normally seen with the following design guideline:
"Exclude objects that are simply derivable from others in this or other MIB
modules."
But would also include handling correlation/synchronization between MIB
queries and YANG queries - let the NMS handle that.

Soapbox:
[Originally the IAB recommended having one data modeling language and one
virtual database of management objects, accessible by multiple protocols.
But that approach was found to be unrealistic, because the SMI became
outdated - it cannot effectively model some aspects of real-world device
implementations, such as nested tables, and would seriously limit the
functionality of non-SNMP protocols like NETCONF and ipfix and syslog. While
it would be nice to be able to access MIB data via other protocols,
sometimes that just isn't going to be viable without hampering new models
with outdated syntax and data structures. When that is the case, I think we
need to move on and use the new, more capable DMLs.]

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Friday, December 13, 2013 6:15 AM
> To: lhotka@nic.cz
> Cc: netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
> 
> Ladislav Lhotka <lhotka@nic.cz> wrote:
> > Andy Bierman <andy@yumaworks.com> writes:
> >
> > > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka <lhotka@nic.cz>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> just an idea: would it help if the server simply records the mapped
> > >> DisplayString version in state data?
> > >>
> > >>
> > > No.  I am OK with the proposal to force the server to constrain the
> > > objects
> >
> > Why not, actually? I mean something like this:
> >
> > { "system-state" : {
> >     ...
> >     "location" : "Schrödingerstraße",
> >     "mib:sysLocation" : "Schroedingerstrasse",
> >     ...
> > }
> >
> > This is similar to what Randy proposed with "legacy-location", but it
> > is in *state*, so it doesn't introduce a second configuration object.
> 
> But why report the MIB object at all in this case?
> 
> If we decide these objects are really separate, I don't see the need
> to report the MIB object.  A manager that wants to see the SNMP object
> in addition to the NETCONF object (for some reason) can use SNMP.
> 
> 
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod