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

On 13 Dec 2013, at 18:37, ietfdbh <ietfdbh@comcast.net> wrote:

> 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.”

In our case, derivable would mean a standardized mapping procedure, right? I think it is easier to leave it to the server and just make the result available.

Lada

> 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
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C