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

[Andy Bierman <[e-mail]>]

Hi,

Here is Martin's suggestion:

> I don't think it makes much sense to have two such similar objects in
> this data model.
>
> One option would be to simply remove the connection between
> sysLocation and this new location leaf (and same for contact),
> essentially making the snmp object the "legacy" object.

I like this idea.  The client can decide if it wants the location leaf
and sysLocation SNMP object to have the same value.

There are many languages that cannot use 7-bit ASCII. We should be
using UTF-8 for all administrative strings.


Andy



On Thu, Dec 12, 2013 at 10:11 AM, ietfdbh <[e-mail]> wrote:

> Hi,
>
>
>
> Comments inline
>
>
>
> David Harrington
>
> [e-mail]
>
> [phone]
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, December 12, 2013 12:19 PM
> *To:* ietfdbh
> *Cc:* Randy Presuhn; Martin Bjorklund; [e-mail]
> *Subject:* Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>
>
> Hi,
>
>
>
> What if these objects do not have corresponding SNMP values on the device?
>
> What if the device does not implement SNMP?
>
>
>
> I don’t really care whether SNMP is implemented on the device or not.
>
> I care about standardizing consistent syntax for the YANG object.
>
>
>
> Are you suggesting we need duplicate versions for devices that do support
> SNMP,
>
> with an "if-feature snmp" statement to make it conditional?
>
>
>
> *Absolutely not. I am saying the syntax should not be conditional. Period.
> No if-feature needed.*
>
>
>
> Either make the syntax of the YANG object the same as DisplayString (which
> would force old syntax on new implementations, sometimes unnecessarily from
> a device perspective, but would allow mapping) or make it two separate
> objects with different syntax (to support internationalization in the newer
> standard, while the old object supports the old syntax, and it doesn’t
> support mapping by the implementation).
>
>
>
> Making it optional is a problem for the NMS side which has to support
> multiple devices that are allowed to make different implementation choices
> for the same object.
>
> Making it optional is a problem for the device side which has to deal with
> translations between values of different syntax.
>
> Allowing the objects to be separate OR mapped, and allowing side-effects
> to change the values seems especially problematic from a synchronization
> standpoint for the NMS (and the operators) who have to consider the results
> of queries by two different protocols of the MAYBE-MAYBENOT-mapped objects.
>
>
>
> *Get rid of the optionality. Standardize the syntax of the YANG object one
> way or the other.*
>
>
>
> What does it mean
>
> if the 2 variants have different values?
>
>
>
> If they are separate variables, they can have different values and
> different syntax. No big deal.
>
> If the **operator** wants them to be the same value, they limit themselves
> to DisplayString syntax when setting the YANG object, and it is their
> responsibility to keep the two variables in sync, not the implementer’s
> responsibility.
>
> If the **operator** wants internationalized YANG names, they can with YANG
> strings.
>
> If the **operator** wants internationalized MIB names, too bad; the MIB
> standard doesn’t permit that.
>
>
>
> 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.
>
>
> If you don’t want the new object to be constrained by old syntax, then
> make it a separate object, unconstrained by any mapping to the standard MIB
> object.
>
> From the perspective of this NMS developer, I would MUCH prefer separate
> objects, each with a consistently standardized syntax, over separate
> objects for whom the syntax may or may not be the same.
>
>
>
> The operators who spoke up around the time of rfc3535 said they don’t
> trust applications to necessarily get things right, so asking the
> implementations to do some type of automated lossless translation between
> objects of different syntax and size sounds like you’re asking for trouble.
>
>
> 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-
> <j.schoenwaelder@jacobs-%0b>> 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
>
>
>