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 Ietfdbh@xxxxxxxxxxx +1-603-828-1401 On 4/19/13 9:25 AM, "The IESG" <noreply@xxxxxxxx> 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 >ietf@xxxxxxxx mailing lists by 2013-05-03. Exceptionally, comments may be >sent to iesg@xxxxxxxx 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. > >