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

[Martin Bjorklund <[e-mail]>]

Juergen Schoenwaelder <[e-mail]> wrote:
> Hi,
> 
> I believe we need a reality check here. Unfortunately, I do not have
> access to many recent devices. I would like to know what todays devices
> do if you configure properties via the CLI that are export via SNMP
> agents.
> 
> - Do boxes reject anything at the CLI that does not conform to
>   DisplayStrings?

One router I tried did this.

> - Or do CLIs accept stuff and the agents provide strings not
>   conforming to DisplayStrings?

One router I tried did this.

> - Or do CLIs accept stuff and there is implementation specific
>   translation happening?
> 
> For me, US 7-bit ASCII forever can't really be the answer.
> 
> /js
> 
> PS: At least on common *nix systems, the SNMP agent is a completely
>     separate process - one out of many. If I change the name of my
>     interface (and I can change it pretty arbitrarily), the SNMP agent
>     is not being asked and it has to deal with the name it finds the
>     kernel using. Some of the popular SNMP code bases out there not
>     even manage to properly truncate strings to DisplayString size. I
>     know it is a weak argument but in the real world, I am sure
>     management systems already have to deal with these issues.

This seems to indicate that it would be best to remove the current
mapping between YANG and SNMP objects.

I'll start a new thread on this issue...


/martin



> 
> On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh 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
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>