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 ----- Original Message ----- From: "David Harrington" <ietfdbh@xxxxxxxxxxx> To: "IETF Discussion List" <ietf@xxxxxxxx> Sent: Monday, April 22, 2013 9:21 PM > 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. > > > > > > >