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

[Benoit Claise <[e-mail]>]

Martin,
> Benoit Claise <[e-mail]> 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
>>        |  +--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.
> 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.
>> There might be some read-only MIB variables in the following RFCs:
>> RFC 4668 RADIUS Authentication Client MIB
> 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...?
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:

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

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


>
>> 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
>> Version 4 (NTPv4)
> Same situation as for the radius client.
>
>> ...
>>
>> 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";
>>         }
> 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).
Let's follow up in the other email thread.
>
>
>
>> +--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.
> It is optional to set for the client.
ok

Regards, Benoit
>
>>   -
>> Do we need the NTP version, 3 or 4, as a config field?
> I saw that you answered this one yourself!
>
>
> /martin
> .
>