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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> Ladislav Lhotka <[e-mail]> wrote:
>> Andy Bierman <[e-mail]> writes:
>> 
>> > On Thu, Dec 12, 2013 at 9:31 AM, Ladislav Lhotka <[e-mail]>
>> > 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.

But the two object are not separate, they are coupled!

If a NETCONF client configures "location", the server maps the value to a DisplayString, records the result in "mib:sysLocation" and updates the MIB object with it.

Conversely, if "sysLocation" is set via SNMP, both "mib:sysLocation" and "location" are updated to that (DisplayString) value - "location" in state and possibly also in configuration, though the latter is IMO problematic due to possible locks or pending to-be-confirmed commits.

Lada
 
>
>
> /martin

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