Subject: FW: Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

From: David Harrington <[email-masked]>
Date: Mon, 22 Apr 2013 16:21:14 -0400

Hi,

I have reviewed this document and feel that is almost ready for approval.
This document defines a new data model in YANG format, based on the same
information model as the Interfaces MIB module (IF-MIB).
Effectively, the YANG model is a second (duplicative) standard for much of
the same information.
It is expected that devices may implement both the MIB and the YANG data
models.

My primary concern regards co-existence and synchronization across data
models.
I think this document would benefit from an Operational Considerations
section that discusses synchronization, or an explanation why they might
reasonably be out-of-sync.
Here are a few points to consider:

1) the ifIndex of an interface is used within the YANG model, matching the
ifIndex in IF-MIB. 
RFC2863 discusses the fact that ifIndex numbering might change during
hot-swaps.
This document does not discuss the need to ensure that IF-MIB ifIndex
changes need to be reflected in the YANG model.
The ifIndex in the YANG module must match that in IF-MIB (really, that in
the underlying instrumentation).
Failure to sync the ifIndex could lead NM applications to confuse which
already-retrieved data records are related to which interface.
This could cause an NM application to misinterpret/corrupt gathered
trending information, and possibly to apply changes to the wrong
interfaces.

2) ifType - can an interface be hot-swapped to use a different type? Is
this discussed someplace?

3) ifType - the description says the value of this mandatory object MAY be
initialized. What value should an NM application expect if it is NOT
initialized?

4) enabled - "Systems that implement the IF-MIB use the value of this leaf
to set IF-MIB.ifAdminStatus ..."; should this be a MAY/SHOULD/MUST? How
will this coexist with SNMP-based NM applications? Is there potential for
conflict? What if NETCONF sets this as enabled, then an operator sets it
to disabled via SNMP?
Does NETCONF know that its "enable" value (adminStatus) is out of date?
(does it matter? See note 7).
What if the NETCONF system directky changes the underlying instrumentation
for adminstatus without going through the MIB?

5) is there a reason why "description" value MAY match IF-MIB ifAlias
***and MAY restrict the values***?
Is there a particular use case for this lack of standardization of
restrictions across data models?
The persistence is a pretty important restriction related to the
functionality of ifAlias, and the dynamism of ifIndex.
If NETCONF is used to set the value, ignoring IF-MIB restrictions, what
happens to IF-MIB ifAlias as a persistent "handle" to the interface?

6) What error is returned via NETCONF if YANG attempts to set a value that
violates the SNMP agent implementation restrictions, and the SNMP agent
refuses the requested SET operation to ifAlias?
Is there a simple way for an operator to tell whether the implementation
supports the restrictions (other than deliberately triggering an error)?

7) what should an NM application or operator do if the YANG oper-status
and the IF-MIB operStatus differ?
IF-MIB has substantial discussion of the relationship between
ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable
discussion.
Given that there could e additional delay incurred between setting enable,
updating ifAdminStatus, the change to ifOperStatus, and the update to
oper-status, I recommend some mention in the description of enable and/or
oper-status of the detailed description in RFC2863, and applicability to
ietf-interfaces.

8) link-up-down-trap-enable: The text says this "indicates" whether traps
should be generated for the interface; shouldn't this be "configures"?

9) persistence isn't discussed in the config object descriptions. Do they
match the IF-MIB object persistences?

10) IF-MIB counters do not typically start at zero; a delta must be
calculated. This is a common misunderstanding for new MIB developers and
users.
I don't see any comparable discussion related to ietf-interfaces counters.
Where should one look for a discussion of YANG counter initialization
values?
Where should one look for a discussion of YANG counter rollover?
It would help to have a discussion of how to utilize discontinuity_time
and counters, especially for implementers not familiar with SNMP (and not
implementing IF-MIB).

11) Is it expected that counters in ietf-interfaces and counters in IF-MIB
are synchronized? Can an NM application reasonably compare two readings -
one of in-octets and one of ifHCInOctets? If not, I think that should be
made clear. (The reference clauses seem to link them)

12) From IF-MIB: "Discontinuities in the value of this counter can occur
at re-initialization of the management system, and at other times as
indicated by the value of ifCounterDiscontinuityTime."
>From ietf-interfaces: "Discontinuities in the value of this counter can
occur at re-initialization of the management system, and at other times as
indicated by the value of 'discontinuity-time'."
I think it is ambiguous as to whether both sets of text refer to the same
"management system". Is the IF-MIB management-system the SNMP agent? And
the YANG management-system the YANG server? Or are both based on the
underlying (e.g, hardware or native) management system?
Are ifCounterDiscontinuityTime and discontinuity-time synchronized or
independent? If they are independent, then the YANG counters and MIB
counters could contain very different values; it might help operators to
have this pointed out. It might help implementers to know whether to try
to synchronize them or not.
Can an operator force restart of both YANG and MIB systems to force
synchronization of counters?

13) Some of the questions about counters might be covered in yang-types;
it would help if the imports clause indicated the relevant RFCs.

14) IF-MIB has both 32-bit and 64-bit counters; YANG only duplicates the
64-bit counters, generally. It might be good to discuss this in an
Operations Considerations section, to explain some potential anomalies at
the NM application side.

15) ietf-interfaces can modify the SNMP trap-enable settings; enabling
lots of traps could impact denial of service, disabling could hide
interface changes made by an attacker; it should probably be mentioned in
security considerations.

16) Many operators/developers may have experience with IF-MIB, and some
applications might be rewritten to utilize ietf-interfaces rather than (or
to supplement) IF-MIB. Not all IF-MIB objects are reflected in
ietf-interfaces; it might be helpful to show which IF-MIB objects are not
mapped to ietf-interfaces, and discuss why, and whether comparable info
can be derived using other YANG approaches.

17) The copyright in the module description clause needs updating.

Hope this helps,
--
David Harrington
[email-masked]
+1-603-828-1401

On 4/19/13 9:25 AM, "The IESG" <[email-masked]> wrote:

>
>The IESG has received a request from the NETCONF Data Modeling Language
>WG (netmod) to consider the following document:
>- 'A YANG Data Model for Interface Management'
>  <draft-ietf-netmod-interfaces-cfg-10.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-05-03. Exceptionally, comments may be
>sent to [email-masked] instead. In either case, please retain the
>beginning of the Subject line to allow automated sorting.
>
>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 file can be obtained via
>http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/
>
>IESG discussion can be tracked via
>http://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg/ballot/
>
>
>No IPR declarations have been submitted directly on this I-D.
>
>

---

From: t.p. <[email-masked]>
Date: Tue, 23 Apr 2013 12:19:45 +0100

David

A thoughtful assessment, and what it brings out for me is that we do not
have an Information Model:-(  That is, we could have reverse engineered
an Information Model from the IF-MIB and then produced a data model in
YANG, but that did not happen.  Rather, there is a new and different
(implicit) Information Model underlying the data model in YANG, as
opposed to the one for the IF-MIB, and that has surfaced a number of
times on the netmod list, not just for this module but equally for the
routing, system and ip modules.  The differences are not great, but they
are there.

So the question is, should we have the same Information Model in YANG as
in MIBs, or do we let them diverge?  and if they diverge, then do we
need to record that in some standard way?  I don't know, but think that
it needs discussing.  It may not be a big issue in the IETF but I am
sure that it will be for those who operate networks!

Tom Petch

---

From: Benoit Claise <[email-masked]>
Date: Tue, 30 Apr 2013 12:47:37 +0200

Thanks Dave for your thorough review.
You have some very valid points.

I've not seen any replies from the author. Maybe he doesn't monitor this 
list. So, including some extra mailing lists.
Martin, NETMOD WG, can you please address David's points.

Note: there is also a reply from Tom Petch on this email. See 
http://www.ietf.org/mail-archive/web/ietf/current/msg78808.html

Regards, Benoit