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

From: Randy Presuhn <[email-masked]>
Date: Wed, 11 Dec 2013 09:47:56 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 11, 2013 12:38 AM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>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.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Dec 2013 08:52:09 +0100 (CET)

> 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).

   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.

Also, just to make sure, we are talking about:

   system/location        -- sysLocation
   system/contact         -- sysContact
   interface/description  -- ifAlias

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 12 Dec 2013 00:42:57 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Wednesday, December 11, 2013 11:52 PM

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.
 
>       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.

>    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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Dec 2013 12:41:32 +0100

>    o  An implementation MUST allow any legal "string" (YANG string).

I do not think we need to state this since this is the default anyway
for an object using the string type.
 
>       the MIB object syntax is still valid.

Yes.

>    interface/description  -- ifAlias

It might also apply to interface/name (ifName).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Dec 2013 12:52:30 +0100

> I'll assume YANG strings do this already.  If not, that's another long

RFC 6020 says:

   The string built-in type represents human-readable strings in YANG.
   Legal characters are tab, carriage return, line feed, and the legal
   characters of Unicode and ISO/IEC 10646 [ISO.10646]:

     ;; any Unicode character, excluding the surrogate blocks,
     ;; FFFE, and FFFF.
     string = *char
     char = %x9 / %xA / %xD / %x20-D7FF / %xE000-FFFD /
            %x10000-10FFFF

And so far, we have used these strings without further restrictions in
data models when there was something to be named.
  
> those sequences and just pass them through unevaluated.

It might not be the job of these documents to engineer a round-trip
solution if one is required.
 
> about this a while back; I don't know what current thinking is.

sysName is defined like this:

            "An administratively-assigned name for this managed
            node.  By convention, this is the node's fully-qualified
            domain name.  If the name is unknown, the value is
            the zero-length string."

Since it is a DisplayString, sysName can represent IDNs only in their
ASCII representation. The .../system/hostname leaf in the system data
model is of type inet:domain-name and RFC 6991 says in the description
of domain-name:

         Domain-name values use the US-ASCII encoding.  Their canonical
         format uses lowercase US-ASCII characters.  Internationalized
         domain names MUST be A-labels as per RFC 5890.

This lines up - you can of course argue whether this is what operators
will prefer to have in their config files since it is not cut'n'paste
friendly.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Dec 2013 14:37:43 +0100 (CET)

>             domain name.  If the name is unknown, the value is

Note that /system/hostname has different semantics - sysName is *by
convention* the *fqdn*.  For this reason, /system/hostname is not
mapped to sysName in the document.

/martin

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 12 Dec 2013 12:08:03 -0500

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
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Randy
> Presuhn
> Sent: Thursday, December 12, 2013 3:43 AM
> To: Martin Bjorklund
> Cc: [email-masked]
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 09:19:28 -0800

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 <[email-masked]> wrote:

> > > > >> > escaped charater sequences in DisplayStrings. I do not think
> that
> this
> > > > >> > document is in charge of doing this. Hence, until such a
> standard
> is

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Dec 2013 18:31:50 +0100

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 <[email-masked]> wrote:

> 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
> I think the new proposed text forces a device to limit the object to 7-bit ASCII

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 09:51:16 -0800

> DisplayString version in state data?
No.  I am OK with the proposal to force the server to constrain the objects
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.

Andy

On 12 Dec 2013, at 18:19, Andy Bierman <[email-masked]> wrote:
> > > > > >> > Anyway, for a standardized approach, someone would have to
> write
> > > a
> > > > > >> Perhaps, though that is the route to being stuck with ASCII
> until
> > the
> > > sysName (think IDN) might also be worth thinking about.  There was a
> long
> > > debate

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 12 Dec 2013 13:11:55 -0500

Hi,

Comments inline

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, December 12, 2013 12:19 PM
To: ietfdbh
Cc: Randy Presuhn; Martin Bjorklund; [email-masked]
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt

Hi,

I don't really care whether SNMP is implemented on the device or not.

I care about standardizing consistent syntax for the YANG object.

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 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. 

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

Hi,

David Harrington
[email-masked]
+1-603-828-1401
> > > >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-
<mailto:j.schoenwaelder@jacobs-%0b> 
> university.de>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 10:31:10 -0800

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 <[email-masked]> wrote:

> Hi,
>
>
>
> Comments inline
>
>
>
> David Harrington
>
> [email-masked]
>
> +1-603-828-1401
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, December 12, 2013 12:19 PM
> *To:* ietfdbh
> *Cc:* Randy Presuhn; Martin Bjorklund; [email-masked]
> *Subject:* Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
>
>
>
> Hi,
>
>
>
> I don’t really care whether SNMP is implemented on the device or not.
>
> *Absolutely not. I am saying the syntax should not be conditional. Period.
> No if-feature needed.*
>
>
>
> standard, while the old object supports the old syntax, and it doesn’t
> Allowing the objects to be separate OR mapped, and allowing side-effects
> to change the values seems especially problematic from a synchronization
> *Get rid of the optionality. Standardize the syntax of the YANG object one
> way or the other.*
>
>
>
> What does it mean
>
> If they are separate variables, they can have different values and
> different syntax. No big deal.
>
> responsibility to keep the two variables in sync, not the implementer’s
> responsibility.
>
> standard doesn’t permit that.
>
>
>
> 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.
>
> 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
>
>
>
> <j.schoenwaelder@jacobs-%0b>> university.de>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Dec 2013 21:37:09 +0100

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?
- Or do CLIs accept stuff and the agents provide strings not
  conforming to DisplayStrings?
- 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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Dec 2013 12:52:44 -0800

Hi,

If the proposal is to move beyond DisplayString, then +1 from me.
It's easy for people in the US to say "no problem" to using US-ASCII.

This thread started over the use of MAY vs. MUST wrt/ DisplayString
compatibility.  Now it has jumped to MUST use DisplayString even
if the device is capable of using UTF-8.

Perhaps the original text was good enough.  The server MAY reject values
it does not support.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Dec 2013 11:14:23 +0100

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Dec 2013 12:15:09 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Dec 2013 12:58:36 +0100

> 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.

Conversely, if "sysLocation" is set via SNMP, both "mib:sysLocation" and "location" are updated to that (DisplayString) value - "location" in state and possibly also in configuration, though the latter is IMO problematic due to possible locks or pending to-be-confirmed commits.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Dec 2013 13:55:50 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Dec 2013 14:19:14 +0100

> record this in the read-only variable mib-sys-location.

Yup.

> is necessary.  The value is available over SNMP.

Right, but performing the mapping *and* recording the result is probably the maximum of what a NETCONF server can be expected to do, unless we restrict the “location” value to a DisplayString. Of course, the mib-sys-location leaf can be only optional, either feature-dependent or defined in a separate module. I am assuming it can be useful to be able to learn the mapped value without going to SNMP.

Lada

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 13 Dec 2013 12:37:57 -0500

Hi,

I agree with the approach of treating these as separate objects, both as an
SNMP greybeard and as an (ex-)NMS developer.

Following the general philosophy of good MIB design, keep the agent simple
and let the NMS handle complexity.
That is normally seen with the following design guideline:
"Exclude objects that are simply derivable from others in this or other MIB
modules."
But would also include handling correlation/synchronization between MIB
queries and YANG queries - let the NMS handle that.

Soapbox:
[Originally the IAB recommended having one data modeling language and one
virtual database of management objects, accessible by multiple protocols.
But that approach was found to be unrealistic, because the SMI became
outdated - it cannot effectively model some aspects of real-world device
implementations, such as nested tables, and would seriously limit the
functionality of non-SNMP protocols like NETCONF and ipfix and syslog. While
it would be nice to be able to access MIB data via other protocols,
sometimes that just isn't going to be viable without hampering new models
with outdated syntax and data structures. When that is the case, I think we
need to move on and use the new, more capable DMLs.]

David Harrington
[email-masked]
+1-603-828-1401

> From: netmod [mailto:[email-masked]] On Behalf Of Martin
> Bjorklund
> Sent: Friday, December 13, 2013 6:15 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Dec 2013 20:38:39 +0100

On 13 Dec 2013, at 18:37, ietfdbh <[email-masked]> wrote:

> modules.”

In our case, derivable would mean a standardized mapping procedure, right? I think it is easier to leave it to the server and just make the result available.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 15 Dec 2013 22:57:59 +0100 (CET)

> - Do boxes reject anything at the CLI that does not conform to

One router I tried did this.

>   conforming to DisplayStrings?

One router I tried did this.

>     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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Dec 2013 10:41:54 +0100

> Right, but performing the mapping *and* recording the result is probably the maximum of what a NETCONF server can be expected to do, unless we restrict the “location” value to a DisplayString. Of c…

RFC 6643 gives you already read-only access to MIB objects.

/js