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

[Ladislav Lhotka <[e-mail]>]

Hi,

just an idea: would it help if the server simply records the mapped DisplayString version in state data?

Lada

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