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

From: Benoit Claise <[email-masked]>
Date: Wed, 04 Dec 2013 17:41:50 +0100

Dear all,

This draft came a long way since my previous AD review some months ago. 
Thanks.

-
 From http://tools.ietf.org/html/rfc6241

    o  state data: The additional data on a system that is not
       configuration data such as read-only status information and
       collected statistics.

However, the document makes a difference between the state data and counters

Abstract

    This document defines a YANG data model for the management of network
    interfaces.  It is expected that interface type specific data models
    augment the generic interfaces data model defined in this document.
    The data model includes configuration data, state data and counters
    for the collection of statistics.

Introduction

    The data model includes configuration data, state data and counters
    for the collection of statistics.

Maybe the solution is to change "state data" in the above two sections 
to "state information", and to use "state data" when you mean both state 
data and counters. Note that all "state data" instance must be checked.

-

    If the device supports arbitrarily named user-controlled interfaces,
    the NETCONF server advertises the feature "arbitrary-names".  If the
    device does not advertise this feature, the names of user-controlled
    interfaces MUST match the device's naming scheme.  How a client can
    learn the naming scheme of such devices is outside the scope of this
    document.

I had to look in the appendix to understand this concept:
      E.1  <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-E.1>.  Router with Restricted Interface Names . . . . . . . . . .38  <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#page-38>
      E.2  <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-E.2>.  Router with Arbitrary Interface Names  . . . . . . . . . .39  <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#page-39>
(and it does make sense after reading the appendices)

You should explain with an example:
    E1: The name of a vlan interface is restricted to the form
    "<physical-interface-name>.<subinterface-number>".

	versus

    E2: The implementation does not restrict the user-controlled interface
    names.

And refer the appendices for the examples.	
    For a more complete example, seeAppendix E.2  <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-B>.

-
OLD:
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as an DisplayString [RFC2579  <http://tools.ietf.org/html/rfc2579>] which uses a
    7-bit ASCII character set.  An implementation MUST restrict the
    allowed values for "name" to match the restrictions of ifName.
NEW:
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as an DisplayString [RFC2579  <http://tools.ietf.org/html/rfc2579>] which uses a
    7-bit ASCII character set.  If the device implements IF-MIB [RFC2863  <http://tools.ietf.org/html/rfc2863>],
    and the mapping is supported, an implementation MUST restrict the allowed
    values for "name" to match the restrictions of ifName.

However, I see later on:
               When a configured user-controlled interface is created by
               the system, it is instantiated with the same name in the
               /interface-state/interface list.  Since the name in that
               list MAY be mapped to ifName by an implementation, such an
               implementation MUST restrict the allowed values for this
               leaf so that it matches the restrictions of ifName.
So it seems that my "NEW" is wrong.
NEW NEW:
    In most cases, the "name" of an "interface" entry is mapped to
    ifName. ifName is defined as an DisplayString [RFC2579  <http://tools.ietf.org/html/rfc2579>] which uses a
    7-bit ASCII character set.  Since the "name" MAY be mapped to ifName [RFC2863  <http://tools.ietf.org/html/rfc2863>],
    an implementation MUST restrict the allowed values for "name" to match
    the restrictions of ifName.

-
   There are a number of counters in the IF-MIB that exist in two
    versions; one with 32 bits and one with 64 bits.  The YANG module
    contains the 64 bits counters only.

NEW:
    There are a number of counters in the IF-MIB that exist in two
    versions; one with 32 bits and one with 64 bits.  Amongst those, the YANG module
    contains the 64 bits counters only.

-

        +----------------------------------+------------------------+
        | YANG data node                   | IF-MIB object          |
        +----------------------------------+------------------------+
        | /interfaces-state/interface      | ifEntry                |
        | /interfaces-state/name           | ifName                 |
        | description                      | ifAlias                |
        | type                             | ifType                 |
        | enabled / admin-status           | ifAdminStatus          |
        | oper-status                      | ifOperStatus           |
        | last-change                      | ifLastChange           |
        | if-index                         | ifIndex                |
        | link-up-down-trap-enable         | ifLinkUpDownTrapEnable |
        | phys-address                     | ifPhysAddress          |
        | higher-layer-if / lower-layer-if | ifStackTable           |
        | speed                            | ifSpeed                |
        | in-octets                        | ifHCInOctets           |
        | in-unicast-pkts                  | ifHCInUcastPkts        |
        | in-broadcast-pkts                | ifHCInBroadcastPkts    |
        | in-multicast-pkts                | ifHCInMulticastPkts    |
        | in-discards                      | ifInDiscards           |
        | in-errors                        | ifInErrors             |
        | in-unknown-protos                | ifInUnknownProtos      |
        | out-octets                       | ifHCOutOctets          |
        | out-unicast-pkts                 | ifHCOutUcastPkts       |
        | out-broadcast-pkts               | ifHCOutBroadcastPkts   |
        | out-multicast-pkts               | ifHCOutMulticastPkts   |
        | out-discards                     | ifOutDiscards          |
        | out-errors                       | ifOutErrors            |
        +----------------------------------+------------------------+

You should say a few words:
- why /interfaces-state/interface and /interfaces-state/name only?
- why type is both of them? (Btw, that's my guess that it applies to both them)

One easy fix is to always prepend /interfaces/ and /interfaces-state/

        +----------------------------------+------------------------+
        | YANG data node                   | IF-MIB object          |
        +----------------------------------+------------------------+
        | /interfaces-state/interface      | ifEntry                |
        | /interfaces-state/name           | ifName                 |
        | /interfaces/description          | ifAlias                |
        | /interfaces/type                 | ifType                 |
        | /interfaces-state/type           | ifType                 |
        ...

-
I wondered about the correlation between the entries in /interface/ and /interfaces-state/ ?
In the section 3.1, an extra paragraph would help, explaining the correlation of entries in/interfaces/  and/interfaces-state/
* In the normal case, ie, if all interfaces are configured, entries in/  //interface/  = entries in/interfaces-state/
* On top of that, if some interfaces are pre-provisioned, extra entries will appear in the/interfaces/
* However, it could also happen that not all interfaces are configured:
   in this case, all existing interfaces would appear in/  //interfaces-state/  while only the configured ones appear in/interface/

-
Looking (only) at the figure at the beginning of section 3:
   +--ro interfaces-state
          +--ro interface* [name]
             +--ro higher-layer-if*   interface-state-ref
             +--ro lower-layer-if*    interface-state-ref

I wondered if I could have interface layering for pre-provisioned interfaces (like a VLAN on soon-to-inserted line card).
My first reaction was no, because I could not see under /interfaces/ :
             +--ro higher-layer-if*   interface-ref
             +--ro lower-layer-if*    interface-ref

However, it's possible. While all the text is there in section 3.3, it might be stressed that two different mechanisms are used.
OLD:

    Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
    represent a read-only view of the interface layering hierarchy.

NEW:

    While the layering mechanism is configured with a new type
    (identityref), two state data leaf-lists, "higher-layer-if"
    and "lower-layer-if", represent a read-only view of the interface
    layering hierarchy (interface-state-ref).

Note: I trust you on the English and correctness.

-      feature pre-provisioning {
        description
          "This feature indicates that the device supports
           pre-provisioning of interface configuration, i.e., it is
           possible to configure an interface whose physical interface
           hardware is not present on the device.";

I wondered whether an OIR (Online Insertion and Removal) feature should advertise this pre-provisioning feature?
I guess it depends whether the configuration is kept and visible or not.
Anyway, I don't want to delay this document any further.
So maybe something to consider in the future, potentially with a new OIR feature.

-
   o  Symbols after data node names: "?" means an optional node, "!"
       means a presence container, and "*" denotes a list and leaf-list.

At first glance, I thought you missed 3 !, after each container.
Until I realize that you speak about "presence container".
Please make clear: for example, add the term to the terminology.

-
   description
            "The list of configured interfaces on the device.

             The operational state of an interface is available in the
             /interfaces-state/interface list.  If the configuration of a
             system-controlled interface cannot be used by the system
             (e.g., the interface hardware present does not match the
             interface type), then the configuration is not applied to
             the system-controlled interface shown in the
             /interfaces-state/interface list.  If the the configuration
             of a user-controlled interface cannot be used by the system,
             the configured interface is not instantiated in the
             /interfaces-state/interface list.";

s/the the/the

-
               If the device supports pre-provisioning of interface
               configuration, the feature 'pre-provisioning' is
               advertised.

               If the device allows arbitrarily named user-controlled
               interfaces, the feature 'arbitrary-names' is advertised.

Is this common practice to repeat this within a leaf, while the features are specified at the beginning of the YANG document.
I could understand for the first entry because it makes the link with the previous paragraph, but the second comes out of the blue.
I'm simply trying to understand what the conventions are.

Once we agree on the changes, post a new version, and I'll progress the 
draft to IETF LC.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Dec 2013 12:32:10 +0100 (CET)

Hi Benoit,

Benoit Claise <[email-masked]> wrote:
> Dear all,
> 
> This draft came a long way since my previous AD review some months
> ago. Thanks.
> 
> -
> to "state information", and to use "state data" when you mean both
> state data and counters. Note that all "state data" instance must be
> checked.

So the issue is that in 6241 state data is defined as:

   state data = status information + statistics

And here we say:

   state data + statistics

which doesn't make sense if "state data" already includes statistics.

Proposal:

OLD:

NEW:

    The data model includes configuration data, status information and
    counters for the collection of statistics.

(in the Abstract and Introduction).

>      E.1
>      <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-E.1>.
>      Router with Restricted Interface Names . . . . . . . . . .38
>      <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#page-38>
>      E.2
>      <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-E.2>.
>      Router with Arbitrary Interface Names . . . . . . . . . .39
>      <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#page-39>
>    For a more complete example, seeAppendix E.2
>    <http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-13#appendix-B>.
> 
> 

Proposal:

OLD:

NEW:

   interfaces MUST match the device's naming scheme.  How a client can
   learn the naming scheme of such devices is outside the scope of this
   document.  See Appendix E.1 and Appendix E.2 for examples.

>    ifName. ifName is defined as an DisplayString [RFC2579
>    <http://tools.ietf.org/html/rfc2579>] which uses a
>    ifName. ifName is defined as an DisplayString [RFC2579
>    <http://tools.ietf.org/html/rfc2579>] which uses a
>    ifName. ifName is defined as an DisplayString [RFC2579
>    <http://tools.ietf.org/html/rfc2579>] which uses a
>    7-bit ASCII character set.  Since the "name" MAY be mapped to ifName
>    [RFC2863 <http://tools.ietf.org/html/rfc2863>],

Proposal:

OLD:

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

NEW:

   In most cases, the "name" of an "interface" entry is mapped to
   ifName. ifName is defined as an 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.

>    contains the 64 bits counters only.

Ok.

Note that the first sentence in section 4 is:

   If the device implements IF-MIB [RFC2863], each entry in the
   "/interfaces-state/interface" list is typically mapped to one
   ifEntry.

So the mapping is from /interfaces-state/interface to ifEntry.

> - why type is both of them? (Btw, that's my guess that it applies to
> - both them)

See below.

> In the section 3.1, an extra paragraph would help, explaining the
> correlation of entries in/interfaces/ and/interfaces-state/
> * In the normal case, ie, if all interfaces are configured, entries in/
> * //interface/ = entries in/interfaces-state/
> * On top of that, if some interfaces are pre-provisioned, extra entries
> * will appear in the/interfaces/
>   in this case, all existing interfaces would appear in/
>   //interfaces-state/ while only the configured ones appear
>   in/interface/

Adding the prefix to all of them makes the table look bad (too long
rows...)  I propose that we add the prefix in all cases where there's
a conflict, but do not use the prefix where there is no conflict.
Specifically, this means that the "type" node gets a prefix:

Proposal:

OLD:

NEW:

> I wondered if I could have interface layering for pre-provisioned
> interfaces (like a VLAN on soon-to-inserted line card).
> However, it's possible. While all the text is there in section 3.3, it
> might be stressed that two different mechanisms are used.
> OLD:
> 

Proposal:

NEW:

  While the interface layering is configured in type specific models,
  two generic state data leaf-lists, "higher-layer-if" and
  "lower-layer-if", represent a read-only view of the interface
  layering hierarchy.

> I wondered whether an OIR (Online Insertion and Removal) feature
> should advertise this pre-provisioning feature?

Ok.

> Please make clear: for example, add the term to the terminology.

Ok; specifically I suggest we add the term "presence container" to
the list in section 1.1, under:

   The following terms are defined in [RFC6020] and are not redefined

>             /interfaces-state/interface list.";

Ok.

> Is this common practice to repeat this within a leaf, while the
> features are specified at the beginning of the YANG document.
> I could understand for the first entry because it makes the link with
> the previous paragraph, but the second comes out of the blue.

There are no such conventions; we're just trying to make the
description text as clear as possible.  I think this helps in this
case, but if people think it makes the text confusing we can remove
it.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Dec 2013 12:42:03 +0100 (CET)

"Jonathan Hansford" <[email-masked]> wrote:
> A VERY small point, but it frustrates me each time I read it:
> 
> s/an DisplayString/a DisplayString

Fixed!

/martin

---

From: "ietfdbh" <[email-masked]>
Date: Thu, 5 Dec 2013 11:57:38 -0500

Comments inline

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

> (in the Abstract and Introduction).

Why not simply:
     The data model includes configuration data and state data.

Let me ask a question. The WG has decided that config data and state data
should be in separate trees.
If there is config data + status information + counters, does that imply a
separate tree for the counters? If so, why?

There has been some discussion that, if state data was mixed with config
data in the same tree, that the volatility of counters would make it harder
to query for changes to config data. Would this also be true of status
information? If so, then maybe a separate tree for counters would make
sense. When I worked on NMS code, we frequently queried the counters, but
less frequently needed to check for changes to config or status information,
and while LastChanged objects were helpful to drive when config/status
information needed to be updated on the NMS-side, LastChanged objects simply
wouldn't work for most counters.

[...]

How about:
> NEW NEW NEW ;-):
    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.  For interoperability reasons, an
implementation MUST restrict the
    allowed values for "name" to match the restrictions of ifName.

I recommend you REQUIRE DisplayString syntax, to ensure interoperability
between clients and servers.
If this is left as an implementation choice, then you probably should
identify the different requirements for servers and clients.
If servers are allowed to implement using non-DisplayString semantics, the
standard should place some restrictions on what is allowed, so client
implementers know what they need to accommodate. 

Can a server choose to implement using an 8-bit or 16-bit character set? How
should a client determine that this is the case?
Can a server choose to ignore the special meanings of NUL, LF, CR, BEL, BS,
HT, VT and FF? If an NMS expects servers to abide by those special meanings,
it could misinterpret data, and mislead operators.
Can a server choose to implement names that exceed 255 characters? If so,
what is an NMS that allocates a 255-character buffer REQUIRED to do with the
excess? Throw it away and ignore it? How should subsequent matching
algorithms deal with that truncation?
If a server implements names > 255, MUST/SHOULD/MAY a client dynamically
allocate larger buffers to accommodate whatever size a server chooses to
send? How should the NMS know how big a buffer is needed, if the delimiters
of the name are implementation-specific?

These questions of interoperability are important whether the server
implements IF-MIB or not.
The processing would be much less complex, and more interoperable, if
implementations were **standardized** to use consistent size and character
set constraints, regardless of the presence of IF-MIB.

> >    contains the 64 bits counters only.

It might be helpful to explain why:
NEW:
There are a number of counters in the IF-MIB that are duplicated in two
versions; Counter32s, for backwards compatibility with SNMPv1, and
Counter64s, to support high capacity devices.  
Since SNMPv1 has been declared Historic, the YANG module
contains only the 64 bit counters.

>        | /interfaces-state/type           | ifType                 |

I think it is less ambiguous to include the prefix consistently.
In a standard, avoiding ambiguity is more important than avoiding looking
bad (long rows).

> case, but if people think it makes the text confusing we can remove

I'm a little concerned about the use of "arbitrary-names".
You don't have any **useful** definition of what arbitrary means.
The definition of arbitrary names uses arbitrary in the definition (usually
considered a bad thing).
I think, but am not sure, that what you mean is that the "arbitrary"
constraints on naming are implementation-specific.

For reasons I mentioned above, I think "arbitrary constraints" are a bad
thing.
At a minimum, I think the document should standardize some constraints on
the naming, even if those constraints are not DisplayString, otherwise it
can be difficult for implementations to interoperate.

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

---

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

Hi David,

> [email-masked]

Ok, that's better.

> to query for changes to config data.

In this particular case this was not the reason for the separation.
(the reason for separation was that the configured interfaces and the
interfaces actually in use on the device are really separate entities).

> Would this also be true of status

Agreed.

> between clients and servers.

Agreed.  That's what we have both in the current text, and in the
proposed clarified text.  I.e., if you map to ifName, then you MUST
match its restrictions.

> set constraints, regardless of the presence of IF-MIB.

The leaf "name" is of type string.  So whatever is a valid string is
acceptable.  See RFC 6020 for a definition of valid strings.

> contains only the 64 bit counters.

Ok, make sense.

> I think it is less ambiguous to include the prefix consistently.

What is the ambiguity?

> In a standard, avoiding ambiguity is more important than avoiding

I certainly agree.

> You don't have any **useful** definition of what arbitrary means.

The feature is currently described like this:

      "This feature indicates that the device allows user-controlled            
       interfaces to be named arbitrarily.";

How about NEW:

      "This feature indicates that the device allows user-controlled            
       interfaces to be named arbitrarily by the client.";

(since it is 'user-controller', adding "by the client" is kind of
redundant, but might help to make it more clear).

> constraints on naming are implementation-specific.

No, it means that there are no constraints.  The client can put an
arbitrary name there.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Dec 2013 10:31:18 +0100

Hi Martin,

Here are some answers.
I removed some points on which we agree. And I left some others, to be 
answered with the latest email.
>     document.  See Appendix E.1 and Appendix E.2 for examples.
ok
>     mapping MUST restrict the allowed values for "name" to match the
ok
>    //interfaces-state/ while only the configured ones appear
You don't consider this one above as a useful piece of information for 
the draft?
>    "lower-layer-if", represent a read-only view of the interface
ok
Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Dec 2013 10:32:29 +0100

>>       The data model includes configuration data and state data.
I would go for
     The data model includes configuration data and state data (status 
information and counters)

People will get this key message without the need to look up the "state 
data" definition in the other RFC.

>> contains only the 64 bit counters.
yes, even better
>> I think it is less ambiguous to include the prefix consistently.
As Dave, I have a small preference for the consistent addition of prefix.
> redundant, but might help to make it more clear).
If it helps, fine.
> .
Thanks and regards, Benoit

---

From: Jonathan Hansford <[email-masked]>
Date: Fri, 06 Dec 2013 10:25:54 +0000

On 06/12/2013 09:32, Benoit Claise wrote:
> People will get this key message without the need to look up the 
> "state data" definition in the other RFC.

+1

>>>>>     versions; one with 32 bits and one with 64 bits. Amongst 
>>>>> those, the
>>>>>     YANG module

+1

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Dec 2013 11:36:36 +0100

> > contains only the 64 bit counters.

I am not sure this design decision had something to do with SNMPv1
officially been labeled Historic by the IETF.

As far as I recall, when the WG discussed this, the point was made
that today's implementations (~20 years after the introduction of
64-bit counters in RFC 1573) generally support 64-bit counters and
NETCONF does fine shipping 64-bit counters - so there is no need to
have additional 32-bit counters.  Perhaps instead of discussing SNMP's
history, we should write down why those counters are 64-bit only:

NEW:

  To support high-speed interfaces with a data rate greater than
  20,000,000 bits/second, RFC 1573 (published in 1994) added 64-bit
  counters to the IF-MIB. Today's implementations generally support
  such high-speed interfaces and hence only 64-bit counters are
  provided in this data model.

/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: Fri, 06 Dec 2013 15:13:35 +0100 (CET)

Hi,

> You don't consider this one above as a useful piece of information for

Sorry I missed this one.

I don't think we can say that the normal case is that all interfaces
are configured.  This might be different in different situations.

I think the current text, which has been discussed for some time on
the ML, explains the relationship between the two lists.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Dec 2013 15:17:19 +0100

> the ML, explains the relationship between the two lists.
Ok then.

Please publish a new draft version.

Regards, Benoit

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Dec 2013 15:23:08 +0100 (CET)

> "state data" definition in the other RFC.

Ok with me.

> >> contains only the 64 bit counters.

Benoit, do you think Juergen's newer propsal is ok?

> As Dave, I have a small preference for the consistent addition of

This is what the table would look like:

   +------------------------------------------+------------------------+
   | YANG data node                           | IF-MIB object          |
   +------------------------------------------+------------------------+
   | /interfaces-state/interface              | ifEntry                |
   | /interfaces-state/interface/name         | ifName                 |
   | /interfaces/interface/description        | ifAlias                |
   | /interfaces-state/interface/type         | ifType                 |
   | /interfaces-state/interface/admin-status | ifAdminStatus          |
   | /interfaces-state/interface/oper-status  | ifOperStatus           |
   | /interfaces-state/interface/last-change  | ifLastChange           |
   | /interfaces-state/interface/if-index     | ifIndex                |
   | /interfaces-state/interface/             | ifLinkUpDownTrapEnable |
   | link-up-down-trap-enable                 |                        |
   | /interfaces-state/interface/phys-address | ifPhysAddress          |
   | /interfaces-state/interface/             | ifStackTable           |
   | higher-layer-if                          |                        |
   | /interfaces-state/interface/             | ifStackTable           |
   | lower-layer-if                           |                        |
   | /interfaces-state/interface/speed        | ifSpeed                |
   | /interfaces-state/interface/in-octets    | ifHCInOctets           |
   | /interfaces-state/interface/             | ifHCInUcastPkts        |
   | in-unicast-pkts                          |                        |
   | /interfaces-state/interface/             | ifHCInBroadcastPkts    |
   | in-broadcast-pkts                        |                        |
   | /interfaces-state/interface/             | ifHCInMulticastPkts    |
   | in-multicast-pkts                        |                        |
   | /interfaces-state/interface/in-discards  | ifInDiscards           |
   | /interfaces-state/interface/in-errors    | ifInErrors             |
   | /interfaces-state/interface/             | ifInUnknownProtos      |
   | in-unknown-protos                        |                        |
   | /interfaces-state/interface/out-octets   | ifHCOutOctets          |
   | /interfaces-state/interface/             | ifHCOutUcastPkts       |
   | out-unicast-pkts                         |                        |
   | /interfaces-state/interface/             | ifHCOutBroadcastPkts   |
   | out-broadcast-pkts                       |                        |
   | /interfaces-state/interface/             | ifHCOutMulticastPkts   |
   | out-multicast-pkts                       |                        |
   | /interfaces-state/interface/out-discards | ifOutDiscards          |
   | /interfaces-state/interface/out-errors   | ifOutErrors            |
   +------------------------------------------+------------------------+

                YANG data nodes and related IF-MIB objects

Personally, I think it is harder to read, and doesn't solve anything,
since there was no ambiguity.

/martin

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Dec 2013 15:50:58 +0100

Martin,
> Benoit, do you think Juergen's newer propsal is ok?
Yes.
> This is what the table would look like:
Well, there was one ambiguity, with the type, which I assumed was 
/interfaces/interface/type AND /interfaces-state/interface/type. Now 
,there is only one under /interfaces/interface/, description
If you believe that's unreadable, make it two tables

    +----------------------------------------------+------------------------+
    | YANG data node (/interfaces/interface/)      | IF-MIB object          |
    +----------------------------------------------+------------------------+
    | description                                  | ifAlias                |
    +----------------------------------------------+------------------------+

    +----------------------------------------------+------------------------+
    | YANG data node (/interfaces-state/interface) | IF-MIB object          |
    +----------------------------------------------+------------------------+
    | interface                                    | ifEntry                |
    | name                                         | ifName                 |
    | description                                  | ifAlias                |
    | type                                         | ifType                 |
    | admin-status                                 | ifAdminStatus          |
    | oper-status                                  | ifOperStatus           |
    | last-change                                  | ifLastChange           |
    | if-index                                     | ifIndex                |
    | link-up-down-trap-enable                     | ifLinkUpDownTrapEnable |
    | phys-address                                 | ifPhysAddress          |
    | higher-layer-if                              | ifStackTable           |
    | lower-layer-if                               | ifStackTable           |
    | speed                                        | ifSpeed                |
    | in-octets                                    | ifHCInOctets           |
    | in-unicast-pkts                              | ifHCInUcastPkts        |
    | in-broadcast-pkts                            | ifHCInBroadcastPkts    |
    | in-multicast-pkts                            | ifHCInMulticastPkts    |
    | in-discards                                  | ifInDiscards           |
    | in-errors                                    | ifInErrors             |
    | in-unknown-protos                            | ifInUnknownProtos      |
    | out-octets                                   | ifHCOutOctets          |
    | out-unicast-pkts                             | ifHCOutUcastPkts       |
    | out-broadcast-pkts                           | ifHCOutBroadcastPkts   |
    | out-multicast-pkts                           | ifHCOutMulticastPkts   |
    | out-discards                                 | ifOutDiscards          |
    | out-errors                                   | ifOutErrors            |
    +----------------------------------------------+------------------------+

Regards, Benoit

---

From: Jonathan Hansford <[email-masked]>
Date: Fri, 06 Dec 2013 15:05:42 +0000

On 06/12/2013 14:50, Benoit Claise wrote:
>>>>>>          | description                      | 
>>>>>> ifAlias                |
>>>>>>          | type                             | 
>>>>>> ifType                 |
>>>>>>          | description                      | 
>>>>>> ifAlias                |
>    | description                                  | 
> ifAlias                |
>    | interface                                    | 
> ifEntry                |
>    | name                                         | 
> ifName                 |
>    | description                                  | 
> ifAlias                |
>    | type                                         | 
> ifType                 |
>    | if-index                                     | 
> ifIndex                |
>    | speed                                        | 
> ifSpeed                |

+1

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 06 Dec 2013 16:24:04 +0100 (CET)

>   provided in this data model.

How about this (complete paragraphs):

OLD:

   There are a number of counters in the IF-MIB that exist in two
   versions; one with 32 bits and one with 64 bits.  The YANG module
   contains the 64 bits counters only.  Note that NETCONF and SNMP may
   differ in the time granularity in which they provide access to the
   counters.  For example, it is common that SNMP implementations cache
   counter values for some time.

NEW:

  There are a number of counters in the IF-MIB that exist in two
  versions; one with 32 bits and one with 64 bits.  The 64-bit
  versions were added to support high-speed interfaces with a data
  rate greater than 20,000,000 bits/second.  Today's implementations
  generally support such high-speed interfaces and hence only 64-bit
  counters are provided in this data model.  Note that NETCONF and
  SNMP may differ in the time granularity in which they provide access
  to the counters.  For example, it is common that SNMP
  implementations cache counter values for some time.

(or did you want the 1573 reference and the 1994 date?)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Dec 2013 18:12:17 +0100

> (or did you want the 1573 reference and the 1994 date?)

The year was added to make it clear that almost 20 years have passed
since the introduction of 64-bit counters. The year does not have to
be in the final text - the 20 Mbps also make it kind of clear what
high-speed interface meant back then.

/js

---

From: "ietfdbh" <[email-masked]>
Date: Fri, 6 Dec 2013 14:48:50 -0500

I think Juergen's proposal is fine.

David Harrington
[email-masked]
+1-603-828-1401
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Friday, December 06, 2013 9:23 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] AD review draft-ietf-netmod-interfaces-cfg-13
> 
those, the
> > >>>         | description                      | ifAlias
|
> > >>>         | type                             | ifType
|
> > >>>         | description                      | ifAlias
|