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

[Martin Bjorklund <[e-mail]>]

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.

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


/martin