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

[Ladislav Lhotka <[e-mail]>]

On 13 Dec 2013, at 13:55, Martin Bjorklund <[e-mail]> wrote:

> Ladislav Lhotka <[e-mail]> wrote:
>> 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.
> 
> Aha, so this is an alternative where an implementation MAY map, and if
> it maps, it MUST (?) use some vendor-specific translation, and it MUST
> record this in the read-only variable mib-sys-location.

Yup.

> 
> If this is what you meant, I still don't think the read-only variable
> is necessary.  The value is available over SNMP.

Right, but performing the mapping *and* recording the result is probably the maximum of what a NETCONF server can be expected to do, unless we restrict the “location” value to a DisplayString. Of course, the mib-sys-location leaf can be only optional, either feature-dependent or defined in a separate module. I am assuming it can be useful to be able to learn the mapped value without going to SNMP.

Lada

> 
> 
> /martin

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