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

[Ladislav Lhotka <[e-mail]>]

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.

Lada

> to DisplayString if the device supports the SNMP objects.
> I prefer that the <rpc> request get rejected with an 'invalid-value' error
> than lie and return <ok>.  The configured value is never going
> to be a valid value on a device that supports SNMP. I am not
> a big fan of separate config and state versions of the same object,
> especially since the protocol has no real way to discover why the
> operational value is different than the configured value.
>
>
>
>
>
>> Lada
>>
>>
>
> Andy
>
>
> On 12 Dec 2013, at 18:19, Andy Bierman <[e-mail]> wrote:
>>
>> > Hi,
>> >
>> > What if these objects do not have corresponding SNMP values on the
>> device?
>> > What if the device does not implement SNMP?
>> >
>> > Are you suggesting we need duplicate versions for devices that do
>> support SNMP,
>> > with an "if-feature snmp" statement to make it conditional?  What does
>> it mean
>> > if the 2 variants have different values?
>> >
>> > I think the new proposed text forces a device to limit the object to
>> 7-bit ASCII
>> > if the SNMP version of the object is supported.
>> >
>> > It seems old syntax is being forced on devices, not new syntax.
>> >
>> >
>> > Andy
>> >
>> > On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh <[e-mail]> wrote:
>> > Hi,
>> >
>> > Personally, I think it would be simpler to just have the YANG objects be
>> > constrained by DisplayString syntax, but then, I come from a country
>> where
>> > 7-bit ASCII covers my language of choice. It would be nice to have a
>> > consistent underlying instrumentation without duplication of effort and
>> > resources, but that would require choosing the least common denominator
>> > (DisplayString).
>> >
>> > My second choice would be to treat them as separate instances, one of
>> > DisplayString syntax, one of YANG string syntax. That way, we don't have
>> to
>> > worry about side effects of changing the YANG object via the MIB, or
>> > changing the MIB object via YANG. If we want to internationalize the
>> syntax,
>> > you cannot do that to the MIB within SMI limits. Mapping between them if
>> > they support different syntax raises a whole lot of issues for the
>> database
>> > handling and UI of an NMS, stands the chance of breaking existing
>> > implementations if implementers handle the translations wrong or in a
>> > non-interoperable manner, and stands the chance of misleading operators
>> (and
>> > applications) if the value of the MIB object is changed dynamically
>> because
>> > the value is changed (in any way) via translation from the YANG object.
>> >
>> > I think it would be better for standardization and interoperability if
>> we do
>> > not try to force-feed new syntax into the existing MIB object(s). If you
>> > were trying to do this by updating the MIB, you would most certainly
>> need to
>> > define a new object (much like we had to do with Counter64s to replace
>> > Counter32s). If the YANG object is treated as a separate object from the
>> MIB
>> > object, then if and when the MIB is updated, the MIB can add an object to
>> > map to the YANG object, and deprecate the DisplayString syntax object.
>> >
>> > If the YANG object says it can be mapped, then I think the YANG object
>> must
>> > REQUIRE that it be implemented with DisplayString constraints, whether a
>> > server implementation maps to the MIB or not. Assuming an NMS supports
>> both
>> > MIB and YANG queries, and an implementer MAY treat them as separate, then
>> > the NMS must treat them as separate. If the implementer MAY treat them as
>> > mapped, the NMS still needs to implement them as separate because they
>> MAY
>> > be separate, but the NMS probably must treat the NMS-side variables as
>> > mapped to ensure they are in sync; otherwise reading the value via the
>> MIB
>> > without simultaneously reading the value via YANG would lead to the NMS
>> > potentially displaying different values even though on the device the
>> values
>> > are the same. This optionality greatly increases the complexity of
>> > implementing these objects on the NMS side. An NMS would need to
>> determine
>> > whether the agent/server implemented these as mapped or separate,
>> presumably
>> > by changing one and seeing if it affected the other, so it knew whether
>> to
>> > try to perform synchronization between the two. Lots of work for limited
>> > benefit to the operator. And if NMS implementations handled
>> synchronization
>> > differently, the operator is stuck trying to manage with conflicting
>> > information from different NMSs.
>> >
>> > It would be much better to standardize the expectation - either these
>> > objects MUST be mapped and constrained by DisplayString syntax per the
>> IETF,
>> > or MUST be defined as separate objects of different syntax per the IETF
>> > standard. Then an NMS implementer knows what to expect.
>> >
>> > David Harrington
>> > [e-mail]
>> > [phone]
>> > > -----Original Message-----
>> > > From: netmod [mailto:[e-mail]] On Behalf Of Randy
>> > > Presuhn
>> > > Sent: Thursday, December 12, 2013 3:43 AM
>> > > To: Martin Bjorklund
>> > > Cc: [e-mail]
>> > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > >
>> > > Hi -
>> > >
>> > > > From: "Martin Bjorklund" <[e-mail]>
>> > > > To: <[e-mail]>
>> > > > Cc: <[e-mail]>; <[e-mail]>
>> > > > Sent: Wednesday, December 11, 2013 11:52 PM
>> > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > > >
>> > > > Randy Presuhn <[e-mail]> wrote:
>> > > > > Hi -
>> > > > >
>> > > > > >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-
>> > > university.de>
>> > > > > >Sent: Dec 11, 2013 12:38 AM
>> > > > > >To: Randy Presuhn <[e-mail]>
>> > > > > >Cc: [e-mail]
>> > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>> > > > > >
>> > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote:
>> > > > > >
>> > > > > >> > Anyway, for a standardized approach, someone would have to
>> write
>> > > a
>> > > > > >> > document that defines how unicode code points are represented
>> as
>> > > > > >> > escaped charater sequences in DisplayStrings. I do not think
>> that
>> > this
>> > > > > >> > document is in charge of doing this. Hence, until such a
>> standard
>> > is
>> > > > > >> > written, I think things need to be implementation specific.
>> > > > > >>
>> > > > > >> Perhaps, though that is the route to being stuck with ASCII
>> until
>> > the
>> > > > > >> successor to Netconf rolls along.
>> > > > > >
>> > > > > >Not necessarily. If you configure via NETCONF (or most CLIs these
>> > > > > >days), you can use unicode characters. The code that maps names to
>> > > > > >legacy non-unicode interfaces then needs to do suitable
>> translations
>> > > > > >to fit whatever constraint there is.
>> > > > >
>> > > > > Not if the data definition restricts the values to an ASCII
>> > > > > subset, as has been proposed.  What's in the draft at the
>> > > > > moment will bring its own interoperability problems, but
>> > > > > at least it's a baby step forward.
>> > > >
>> > > > So it seems we have a chance to fix this now.  But I need to
>> > > > understand what exactly you and/or Juergen propose.  Preferrably
>> > > > concrete text.  I *think* that the proposal is something like this:
>> > > >
>> > > >    o  An implementation MUST allow any legal "string" (YANG string).
>> > >
>> > > There are good reasons to restrict formatting and control characters -
>> > > I'll assume YANG strings do this already.  If not, that's another long
>> > > discussion.
>> > >
>> > > >    o  An implementation that maps this value to the corresponding MIB
>> > > >       object, which has size and character set limitations, MUST use
>> > > >       some mechanism out of the scope for this document to ensure
>> that
>> > > >       the MIB object syntax is still valid.
>> > >
>> > > Yes this seems reasonable.
>> > >
>> > > But it doesn't cover a "round trip".  If the value is modified via the
>> MIB
>> > > interface to include what looks like the implementation-specific
>> encoding
>> > > into ASCII of a non-ASCII Unicode code point, does retrieving that
>> value
>> > > via the Netconf interface get the Unicode code point or the
>> > implementation-
>> > > specific ASCII encoding of it?  If it does (and I think it should) then
>> > there
>> > > needs to be some though put into what happens when the code point
>> > > encoded using ASCII would, if converted to Unicode, be illegal (for
>> > > whatever reason) in the YANG string.  It's probably best to keep the
>> > > SNMP instrumentation ignorant of all this, so code in the Netconf side
>> > > would need determine whether any of the ASCII "escape sequences"
>> > > would produce forbidden code points, and, in such cases, *not* evaluate
>> > > those sequences and just pass them through unevaluated.
>> > >
>> > >
>> > > > Also, just to make sure, we are talking about:
>> > > >
>> > > >    system/location        -- sysLocation
>> > > >    system/contact         -- sysContact
>> > > >    interface/description  -- ifAlias
>> > >
>> > > Perhaps also sysDescr (even though read-only, my comment above seems
>> > > applicable,
>> > > particularly since on at least some systems this comes from a static
>> > > configuration
>> > > file, and would be useful to support local language in some minimal
>> way.)
>> > >
>> > > sysName (think IDN) might also be worth thinking about.  There was a
>> long
>> > > debate
>> > > about this a while back; I don't know what current thinking is.
>> > >
>> > > Randy
>> > >
>> > > _______________________________________________
>> > > netmod mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>

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