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

From: Benoit Claise <[email-masked]>
Date: Mon, 09 Dec 2013 17:11:13 +0100

Dear authors,

Here is my AD review.

-
exactly like indraft-ietf-netmod-interfaces-cfg  <https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/>, which contains a summary table with MIB variable table, this document should contain a similar mapping table
For example
       +--rw system
       |  +--rw contact?          string
       |  +--rw hostname?         inet:domain-name
       |  +--rw location?         string
       +--ro system-state
          +--ro platform
             +--ro os-name?       string
             +--ro os-release?    string
             +--ro os-version?    string
             +--ro machine?       string

This maps to the system group MIB variables. Some leavs definitions already refer to some MIB variables: sysContact, sysLocation, etc.
I understand the MIB variables don't map 1:1, but telling that
             os-name        part of the sysDescr MIB variable
             os-release     part of the sysDescr MIB variable
             os-version     part of the sysDescr MIB variable
             machine?       part of the sysDescr MIB variable
... is also useful info.

Considering that NETCONF is now also used for monitoring, and that people were used to SNMP, such mapping tables would be a good practice in all NETMOD documents to help SNMP people/NMS make the transition.
There might be some read-only MIB variables in the following RFCs:
RFC 4668 RADIUS Authentication Client MIB
RFC 4669 RADIUS Authentication Server MIB
RFC 5907 Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4)
...

So it needs a little bit of research, but shouldn't be too hard.

-
   leaf location {
          type string;
          description
            "The system location. The server MAY restrict the size
             and characters in order to maintain compatibility with
             the sysLocation MIB object.";
          reference
            "RFC 3418  <http://tools.ietf.org/html/rfc3418>: Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysLocation";
        }

Question: do we want to be aligned with the leaf name logic inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/  ?

leaf name {
    ...
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as a DisplayString [RFC2579] which uses a
    7-bit ASCII character set.  An implementation that performs this
    mapping MUST restrict the allowed values for "name" to match the
    restrictions of ifName.

So basically
NEW:
   leaf location {
          type string;
          description
            "The system location. In most cases, the "location" of an "interface" entry
            is mapped to sysLocation. sysLocation is defined as a DisplayString [RFC2579]
            which uses a 7-bit ASCII character set. An implementation that performs this
            mapping MUST restrict the allowed values for "location" to match the
            restrictions of sysLocation.";
          reference
            "RFC 3418  <http://tools.ietf.org/html/rfc3418>: Management Information Base (MIB) for the
                       Simple Network Management Protocol (SNMP)
                       SNMPv2-MIB.sysLocation";
        }

-
+--rw system
       |  +--rw clock
       |  |  +--rw (timezone)?
       |  |     +--:(timezone-location)
       |  |     |  +--rw timezone-location?     ianatz:iana-timezone
       |  |     +--:(timezone-utc-offset)
       |  |        +--rw timezone-utc-offset?   int16
       |  +--rw ntp!
       |     +--rw enabled?   boolean

  leaf enabled {
            type boolean;
            default true;
            description
              "Indicates that the system should attempt
               to synchronize the system clock with an
               NTP server from the 'ntp/server' list.";
          }

How come that enabled is marked as optional while there is a default value?
Aren't they slightly conflicting statements?
Disclaimer: no strong feeling about that one.
  
-
Do we need the NTP version, 3 or 4, as a config field?

Regards, Benoit (OPS AD)

---

From: Benoit Claise <[email-masked]>
Date: Mon, 09 Dec 2013 17:21:51 +0100

Dear all,

And one last I forgot.

I was confused by

      leaf-list search {
            type inet:domain-name;
            ordered-by user;
            description
              "An ordered list of domains to search when resolving
               a host name.";
          }

I could not get the link between the "search" and  "An ordered list of 
domains to search when resolving a host name."
I would have called that "domain" or "search-domain". I had to be 
pointed to the "search" keyword in the resolv.conf as a hint!
Might be worth changing the name or adding a sentence: "the search name 
comes from the search keyword in resolv.conf type in UNIX-like operating 
systems"

Regards, Benoit
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Dec 2013 12:42:23 +0100

Dear all,

Answering my own question:
- Do we need the NTP version, 3 or 4, as a config field?

Did some investigations.
Apparently it's not needed because there is an indication of the version 
during the NTP message exchange.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Dec 2013 13:18:38 +0100 (CET)

Benoit Claise <[email-masked]> wrote:
> Dear authors,
> 
> Here is my AD review.
> 
> -
> exactly like indraft-ietf-netmod-interfaces-cfg
> <https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/>,
> which contains a summary table with MIB variable table, this document
> should contain a similar mapping table
> For example
>       +--rw system
>       |  +--rw contact?          string
> This maps to the system group MIB variables. Some leavs definitions
> already refer to some MIB variables: sysContact, sysLocation, etc.

For the 1-1 mapped object, we'll have this table:

                  +----------------+-------------------+
                  | YANG data node | SNMPv2-MIB object |
                  +----------------+-------------------+
                  | contact        | sysContact        |
                  | location       | sysLocation       |
                  +----------------+-------------------+

> Considering that NETCONF is now also used for monitoring, and that
> people were used to SNMP, such mapping tables would be a good practice
> in all NETMOD documents to help SNMP people/NMS make the transition.

Our model provides parameters for configuring the radius client; this
MIB has objects for read-only monitoring.   The config objects affect
what is operationally used, but there is no 1-1 mapping.  The "related"
objects are:

 radius/server/transport/udp/udp/address
                 radiusAuthServerInetAddressType
                 radiusAuthServerInetAddress

 radius/server/transport/udp/udp/authentication-port
                 radiusAuthClientServerInetPortNumber

But I am not sure that listing these adds any value...?

> RFC 4669 RADIUS Authentication Server MIB

This is not applicable; we don't have any parameters for RADIUS
servers.

> RFC 5907 Definitions of Managed Objects for Network Time Protocol

Same situation as for the radius client.

> Question: do we want to be aligned with the leaf name logic
> inhttps://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ ?
> 
> leaf name {
>    ...

As Randy pointed out, the text above has some copy&paste errors.

OLD:

         The server MAY restrict the size and characters in
         order to maintain compatibility with the sysContact
         MIB object.";

NEW:

         This leaf MAY be mapped to the sysContact MIB object by an
         implementation.  Such an implementation MUST restrict the
         allowed values for this leaf so that it matches the
         restrictions of sysContact."

... but I am not convinced the new text is better than the old.  If
you think it is, I am fine with adding it.

(and same for location).

> Disclaimer: no strong feeling about that one.

It is optional to set for the client.

> Do we need the NTP version, 3 or 4, as a config field?

I saw that you answered this one yourself!

/martin

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Dec 2013 17:20:19 +0100

Martin,
> For the 1-1 mapped object, we'll have this table:
If there is no 1:1 mapping, that's different.
Up to you to mention a sentence such as:

    The YANG module provides parameters for configuring the radius client; the
    RFC 4668 RADIUS Authentication Client MIB has objects for read-only monitoring.
    There is no 1-1 mapping between the YANG module and MIB module objects.
    The "related" objects are:

> you think it is, I am fine with adding it.
Let's follow up in the other email thread.
> It is optional to set for the client.
ok

Regards, Benoit
> .