Subject: [netmod] AD review of draft-ietf-netmod-interfaces-cfg-09

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Mar 2013 23:28:30 +0100

Dear all,

Disclaimer:
- If any of those points have been discussed on the mailing list, don't 
hesitate to let me know.
- I probably should have mentioned some of these documents during the 
last call. Sorry. After a year in the new position, I'm still playing 
catch up mode.

_CLARIFYING QUE__STION__S_

- Section 3.1 The interface List

    The data model for interfaces presented in this document uses a flat
    list of interfaces.  Each interface in the list is identified by its
    name.  Furthermore, each interface has a mandatory "type" leaf, and a
    "location" leaf.  The combination of "type" and "location" is unique
    within the interface list.

First time I read this, I thought the location was mandatory.
However, it's not:

       +--rw interfaces
          +--rw interface [name]
             +--rw name                        string
             +--rw description?                string
             +--rw type                        ianaift:iana-if-type
             +--rw location?                   string

Proposal:
OLD:
	
    Furthermore, each interface has a mandatory "type" leaf, and a
    "location" leaf.

NEW:
    Furthermore, each interface has a mandatory "type" leaf, and an optional
    "location" leaf.

When I understood that the location is optional, I have some 
difficulties to understand the following sentence
"The combination of "type" and "location" is unique within the interface 
list." when the location is an optional field.

- How does the mechanism above apply to subinterfaces? example: 
Interface Ethernet 0.1?
I believe it deserves some explanation. Now, it's true that the RFC 2863 
doesn't mention the notion of subinterface, and I believe that the 
notion of sub-layer (in RFC 2863) and interface layering (in 
draft-ietf-netmod-interfaces-cfg) notions don't apply to subinterfaces? 
I would be happy to stand corrected.
For example, how should I understand the following sentence, if we speak 
about an subinterface

    The "location" leaf is a string.  It is optional in the data model,
    but if the type represents a physical interface, it is mandatory.

Does the subinterface really _represent _a physical interface?

-

The "if-index" leaf contains the value of the corresponding ifEntry's ifIndex.

Shouldn't we stress this sentence with a MUST?
Let's face it, we still have many MIB modules for monitoring. We can use 
NETCONF/YANG for interface management, but we need the link to the 
ifIndex, to access the corresponding entries in the existing MIB modules

- One of the real pain point of RFC 2863 is the ifIndex non persistence.

       "Its value ranges between 1 and the value of ifNumber.  The
       value for each interface must remain constant at least from
       one re-initialization of the entity's network management
       system to the next re-initialization."

Can we assume that the leaf name will remain constant after a 
"re-initialization of the entity's network management system", and that 
only the leaf if-index could change.
Or we can't assume anything, and the NMS must rediscover everything. So 
same pain point as SNMP?
Or should the NMS compare the config (which contains the 
ifName/leaf-name), and if they're unchanged after a reboot, the NMS just 
have query leaf if-index for the mapping to the MIB module?
Could/should we say a few words about this in the draft?

_EDITORIAL:_

- Section 2

    o  It is recognized that existing implementations will have to map
       the interface data model defined in this memo to their proprietary
       native data model.  The new data model should be simple to
       facilitate such mappings.

What does new refer to? The YANG module in this document, or the 
extensions, referred by the text seen in the introduction

    It is expected that interface type specific
    data models augment the generic interfaces data model defined in this
    document.

I guess the YANG module in this document. So removing "new" would solve 
the confusion.

- You might to stress in the section 4 that the non HC counters are not 
modeled.

        | in-octets                        | ifHCInOctets           |
        | in-unicast-pkts                  | ifHCInUcastPkts        |
        | in-broadcast-pkts                | ifHCInBroadcastPkts    |
        | in-multicast-pkts                | ifHCInMulticastPkts    |

Btw, could this be a problem for sensors?

-

        leaf last-change {
            type yang:date-and-time;
            config false;
            description
              "The time the interface entered its current operational
               state.  If the current state was entered prior to the
               last re-initialization of the local network management
               subsystem, then this node is not present.";
            reference
              "RFC 2863  <http://tools.ietf.org/html/rfc2863>: The Interfaces Group MIB - ifLastChange";
          }

 From the date-and-time definition in RFC 6021, do I understand 
correctly that the date-and-time are absolute time (and not the 
equivalent of the sysUpTime, as mentioned in ifLastChange).
What if the device doesn't have any absolute time, but simply the sysUpTime?
Same question for leaf discontinuity-time

-  I discovered the following feature in the YANG module

      feature arbitrary-names {
        description
          "This feature indicates that the server allows interfaces to
           be named arbitrarily.";
      }

The only information I can find is

      If the device allows arbitrarily named interfaces, the
      feature 'arbitrary-names' is advertised.
   
      This leaf MAY be mapped to ifName by an implementation.
      Such an implementation MAY restrict the allowed values for
      this leaf so that it matches the restrictions of ifName.

As an implementor, I don't have much idea what is meant by this 
'arbitrary-names' feature. Some explanatory text outside of the YANG 
module would be welcome.
Note: it's only when I read the appendix E that I finally got the 
information I was after. Not sure why this is in the appendix... Up to you.
At least, I would make it clear in which of the E.X examples, the 
"feature arbitrary-names" is advertised. I guess, from the title, E2 and E5

Regards, Benoit