Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]

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

Hi,

I am starting a new thread for this issue.  We need to resolve this
pretty soon.

We have a couple of YANG leafs that the current documents (interface
and system) specify that an implementation MAY map to corresponding
SMIv2 objects.  The YANG leafs allow XML 1.0 characters (unicode w/
exceptions), and have no hard length limits, whereas the SMIv2 objects
are DisplayStrings - nvt-ascii of size max 255.

The current documents say that if an implementation map the YANG leaf
to the SMIv2 object, it MUST restrict the YANG values to match the
SMIv2 restrictions.

One (theoretical?) problem that is not handled in the documents is
that some C0 control codes are valid in DisplayStrings but not valid
in a YANG string (e.g. BEL and VT).

The mappings are:

   /interfaces/interface/description - ifAlias
   /interfaces-state/interface/name  - ifName
   /system/contact                   - sysContact
   /system/location                  - sysLocation

Note that the interfaces document is in IETF Last Call.

Here are some options:

  1.  Do nothing; keep current text.

      NOTE: not clear how we handle DisplayString characters
      that are not legal YANG string characters.

  2.  Say that implementations MAY map, but that they need to do some
      vendor-specific translation procedure to handle the difference
      in character sets and lengths.

  3.  Like 2 + add an additional config false leaf in the YANG model
      to inform the YANG client about the resulting value.  (NOTE:
      this value is of course already available over SNMP).

  4.  Make the YANG leafs and SMIv2 objects separate, i.e., do not
      specify that there is a mapping between them.

Comments?

My preference is 4, followed by 2.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 15 Dec 2013 15:53:27 -0800

Hi -

To Martin's helpful summary I'd add this chart that I hope makes
it a little easier to see the differences between the two SMI
textual conventions (relevant to the system management and
SNMP configuration documents) and the RFC 6020 string type,

Codepoints    | SnmpAdminString    | DisplayString    | RFC 6020 string
--------------+--------------------+------------------+-----------------
0x00 (NUL)    | allowed, but       | specific usage(s)| illegal
              | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x01-0x06     | allowed, but       | allowed, but no  | illegal
              | should be avoided  | standard meaning |
--------------+--------------------+------------------+-----------------
0x07-0x09     | allowed, but       | specific usage(s)| illegal
(BEL, BS, HT) | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x0A (LF)     | recommended usage  | recommended usage| allowed
              | as part of CR LF   | as part of CR LF |
--------------+--------------------+------------------+-----------------
0x0B (VT)     | allowed, but       | specific usage(s)| illegal
0x0C (FF)     | should be avoided  | described        |
--------------+--------------------+------------------+-----------------
0x0D (CR)     | recommended usage  | allowed in the   | allowed
              | as part of CR LF   | sequence CR LF or|
              |                    | CR NUL. Any other|
              |                    | CR xx sequence   |         
              |                    | is illegal,      |
              |                    | including as last|
              |                    | character in a   |
              |                    | string           |
--------------+--------------------+------------------+-----------------
0x0E..0x1F    | allowed, but       | allowed, but no  | illegal
(SO-US)       | should be avoided  | standard meaning |
--------------+--------------------+------------------+-----------------
0x20-0x7F     | allowed            | allowed          | allowed
--------------+--------------------+------------------+-----------------
0x80-0x9f     | allowed, but       | illegal          | allowed
              | should be avoided  |                  |
--------------+--------------------+------------------+-----------------
0xa0-0xff     | allowed            | illegal          | allowed
--------------+--------------------+------------------+-----------------
0x100-0xD7FF  | allowed            | illegal / really | allowed
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xD800-0xDFF  | allowed            | illegal / really | illegal
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xE000-0xFFFD | allowed            | illegal / really | allowed
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0xFFFE-0xFFFF | allowed            | illegal / really | illegal
              |                    | impossible       |
--------------+--------------------+------------------+-----------------
0x10000-      | allowed            | illegal / really | allowed
0x10FFFF      |                    | impossible       |
--------------+--------------------+------------------+-----------------
0x110000-     | allowed by RFC 3411| illegal / really | illegal
0x7fffffff    | RFC 3629 later     | impossible       |
              | restricted UTF-8 to|                  |
              | exclude this range |                  |
--------------+--------------------+------------------+-----------------

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 15 Dec 2013 16:00:02 -0800

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Sent: Sunday, December 15, 2013 1:58 PM
> Subject: [netmod] mapping to snmp strings [Was: AD review of draft-ietf-netmod-system-mgmt]
...
>       specify that there is a mapping between them.

I'd add an option:

5) Implementations MUST map in both directions using a *standardized*
mapping, with provision for pathological cases due to length constraints
and the inherent limitations of superimposing escape schemes onto existing
methods.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Dec 2013 08:01:48 +0100 (CET)

Randy,

Do you have a preference?

/martin

"Randy Presuhn" <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Dec 2013 11:00:48 +0100

> My preference is 4, followed by 2.

Speaking as technical contributor, my preference is 2. I do not see
how 4 would work (if I change the name of an interface, I assue this
name change will eventually become visible via other interfaces such
as SNMP - hence 4 practically seems to lead to 2 anyway, no?).

/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: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Dec 2013 11:15:12 +0100 (CET)

> as SNMP - hence 4 practically seems to lead to 2 anyway, no?).

This is a special case for ifName.  The SNMP object says that this is
the name used at the "console", and assumes that the "console" can
only have ascii.  So what happens when the "console" can do unicode?
As you pointed out the device will do whatever it does, and the SNMP
agent will have to deal with it somehow.  The addition of the YANG
module doesn't change this situation.

Note that arbitrary unicode names are applicable to user-controlled
interfaces only.  system-controlled interfaces will be called whatever
name the system assigns to them.

Did you mean that 4 will be a problem for contact, location and
interface/description as well?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Dec 2013 11:19:06 +0100

> interface/description as well?

For contact and location, you could treat them different but I doubt
it increases user experience by treating them different at the end of
the day. As a customer, I want to configure a contact only once and
not multiple times and hence even then, I suspect that implementations
will find reasons to actually do 2.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 16 Dec 2013 16:33:36 +0100

> module doesn't change this situation.

Right, I think we have to make sure that the *system* can use the configured names.

> name the system assigns to them.

Hmm... I can assign a juicy unicode name to eth0 in an init script and then from the NETCONF point of view the name is assigned by the system.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Dec 2013 17:14:07 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hmm... I can assign a juicy unicode name to eth0 in an init script and then
> from the NETCONF point of view the name is assigned by the system.

Yes.  Is this a problem?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 16 Dec 2013 17:18:15 +0100

>> from the NETCONF point of view the name is assigned by the system.

Probably not, but it is not true that “... arbitrary unicode names are applicable to user-controlled interfaces only.”

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 17 Dec 2013 08:38:16 +0100

> and the inherent limitations of superimposing escape schemes onto existing

In regard to the current set of documents, I prefer #4. Anything else should be potentially addressed in a separate document. The problem actually appears to be broader than just the system module and just the interaction with SMIv2 objects.

Lada

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Dec 2013 17:53:35 +0100

Dear all,

[I read all emails in this thread till now, but selected this email for 
my answer as it contains the 5 proposals]

We should be solving this issue once for all, for the current and future 
YANG modules.
For the ones who not provided feedback yet, it's about time now.

As a contributor, here are my preferences.
- 5 would be ideal. However, we don't have this standardized mapping 
now. We should not delay this work further.
This standardized mapping work could be developed and apply later.
- Next: 2 and 4.
I agree with Jürgen S. that the 2 solutions are linked.
So basically, it means in my mind:
     the YANG leafs and SMIv2 objects are separate objects.
     reason: string internalization
     the following objects may map depending on the characters set selected
         /interfaces/interface/description - ifAlias
         /interfaces-state/interface/name - ifName
         /system/contact - sysContact
         /system/location - sysLocation
    However, mapping rules are outside the scope of this document.

Regards, Benoit
> .

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Dec 2013 09:00:50 -0800

On Tue, Dec 17, 2013 at 8:53 AM, Benoit Claise <[email-masked]> wrote:

> Dear all,
>
> [I read all emails in this thread till now, but selected this email for my
> answer as it contains the 5 proposals]
>

Slight variant:

  SHOULD (5); if not implemented then MAY (2)

> - 5 would be ideal. However, we don't have this standardized mapping now.
> We should not delay this work further.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Dec 2013 19:36:33 +0100 (CET)

Hi,

It seems to me that alternative 2 can be accepted by most people.

Here's a proposal for text to put into system/contact.  The others
would be similar:

    leaf contact {
      type string;
      description
        "The administrator contact information for the system.

         A server implementation MAY map this leaf to the sysContact
         MIB object.  Such an implementation MUST use some mechanism
         to handle the differences in size and characters allowed
         between this leaf and sysContact.  The definition of such
         a mechanism is outside the scope of this document.";
      reference
        "RFC 3418: Management Information Base (MIB) for the
                   Simple Network Management Protocol (SNMP)
                   SNMPv2-MIB.sysContact";
    }

/martin