On Apr 30, 2013, at 7:25 AM, Benoit Claise <bclaise@xxxxxxxxx> wrote: > On 30/04/2013 13:07, Benoit Claise wrote: >> Martin, >> >> It's interesting to note that Dave came up with similar feedback as I had during my AD review. >> And you had to re-explain this again, via email. This leads me to think that we need some more background information, typically in "Operational Considerations" section. >> http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-10#section-4 could be part of that new section, but other topics could/should be addressed: >> - Failure to sync the ifIndex >> - is there a reason why "description" value MAY match IF-MIB ifAlias ***and MAY restrict the values***? >> - what should an NM application or operator do if the YANG oper-status and the IF-MIB operStatus differ? >> - persistence >> - Is it expected that counters in ietf-interfaces and counters in IF-MIB are synchronized? >> - etc... >> >> Basically addressing many points made by Dave > And I see that Carlos, part of the "Re: RtgDir review: draft-ietf-netmod-interfaces-cfg-10.txt" feedback has got some similar points. > - physical versus virtual interfaces > - location > - counter32 and counter64, and mapping to the MIB OIDs > - etc... > > That reinforces in my thinking that we need an "operational considerations" section. +1. I think that an "Operational Considerations" addressing these issues would be a most useful addition to this document. For context, full review at http://www.ietf.org/mail-archive/web/netmod/current/msg08035.html Thanks, -- Carlos. > > Regards, Benoit >> >> Regards, Benoit >>> Hi David, >>> >>> Thank you for your detailed review! Comments inline. >>> >>> David Harrington <ietfdbh@xxxxxxxxxxx> wrote: >>>> 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. >>> Actually, RFC 2863 points out that a ifIndex must not be reused until >>> after the following re-initialization of the network management >>> system. >>> >>>> 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). >>> Absolutely! That's the intention. The description for the read-only >>> leaf if-index says: >>> >>> The ifIndex value for the ifEntry represented by this >>> interface. >>> >>> >>>> 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. >>> Fully agree - this is why the if-index is present; to facilitate the >>> mapping between the models. >>> >>>> 2) ifType - can an interface be hot-swapped to use a different type? Is >>>> this discussed someplace? >>> Hot-swapping sounds like a physical property. The data model in this >>> document can handle this -- provided the system physically supports >>> it, of course. Note that the type is a writable leaf just like >>> others. You can change it, but as with any other leaf a device that >>> cannot support a particular change will reject it. >>> >>>> 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? >>> None. And since it is mandatory, in this case the NM application has >>> to explicitly provide the type. If you write a completely generic NM >>> application you would probably always provide the type, since you >>> cannot count on the server auto-initializing it. But if you *know* >>> that the server auto-initialize the type, you don't have to provide >>> it. >>> >>>> 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? >>> It is not clear to me if we can / want to require that these objects >>> share the same instrumentation. >>> >>> Some of this might be b/c ifAdminStatus is a a bit unclear in some >>> regards. For example, it talks about how >>> >>> per configuration information >>> retained by the managed system, ifAdminStatus is then >>> changed [...] >>> >>> I would assume (but this might be incorrect) that the "configuration >>> information" could be things configured through the CLI for example, >>> and this "configuration information" could thus also be the data >>> defined in this YANG model. >>> >>> So it seems RFC 2863 makes a distinction between ifAdminStatus and >>> what is actually configured. >>> >>> Also, the description of ifAdminStatus doesn't say anything about >>> persistence, so it might be impossible to map this to the persistently >>> stored configuration. >>> >>> >>>> 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? >>> The only reason the "description" leaf is mapped to ifAlias is b/c >>> this is what many implementations do. So we wanted to point out the >>> differences in the value space for these objects so that implementers >>> are aware of this. >>> >>> And of course it is not possible to actually set *ifAlias* and ignore >>> its syntax constraints. However, you can use non 7-bit ascii in >>> "description", and in this case the "description" value cannot be used >>> unmodified as ifAlias. >>> >>>> 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? >>> The draft says: >>> >>> If a NETCONF server that implements this restriction is >>> sent a value that doesn't match the restriction, it MUST >>> reply with an rpc-error with the error-tag >>> 'invalid-value'. >>> >>>> Is there a simple way for an operator to tell whether the implementation >>>> supports the restrictions (other than deliberately triggering an error)? >>> No. >>> >>>> 7) what should an NM application or operator do if the YANG oper-status >>>> and the IF-MIB operStatus differ? >>> The intention is that they share the same instrumentation. >>> >>>> IF-MIB has substantial discussion of the relationship between >>>> ifAdminStatus and ifOperStatus. The YANG module doesn't have a comparable >>>> discussion. >>> Which text in the MIB do you mean? There is some text in the >>> description of "oper-status". >>> >>>> 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"? >>> Or maybe "Controls ..."? >>> >>>> 9) persistence isn't discussed in the config object descriptions. Do they >>>> match the IF-MIB object persistences? >>> Persistence in NETCONF is different from SNMP, in general. In NETCONF, >>> the persistence is defined by the data store where you write the data. >>> >>> >>>> 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? >>> The couters are defined as yang:counter32 and yang:counter64. The >>> "yang" prefix means module "ietf-yang-types". This module is defined >>> in RFC 6021. This RFC discusses initial values and discontinuities. >>> >>> (ok, this was also suggested by yourself further below!) >>> >>>> 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) >>> I think the intention is that the instrumentation is shared. There is >>> most probably a single hw register / kernel counter for these objects, >>> and this is what will be used for these counters. >>> >>>> 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? >>> Good question! The term is not defined anywhere (as far as I know), >>> and thus there is some liberty in the interpretation of it. But I >>> don't think it matters. It seems unlikely that a >>> NM application sometimes reads a counter over SNMP and sometimes the >>> same counter from the same device over NETCONF and then compare the >>> values. >>> >>>> 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. >>> See above. There is no requirement that they MUST be synchronized, >>> but they surely can be. >>> >>>> 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? >>> No. Is there a way to force a restart of the "MIB system"? >>> >>>> 13) Some of the questions about counters might be covered in yang-types; >>>> it would help if the imports clause indicated the relevant RFCs. >>> As a comment? I will raise this issue in the WG. >>> >>>> 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. >>> In practice I don't think this is a problem. It seems unlikely that a >>> NM application sometimes reads a counter over SNMP and sometimes the >>> same counter from the same device over NETCONF and then compare the >>> values. >>> >>>> 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. >>> I was thinking we could simply reference the Security Considerations >>> section in RFC 2863 for this, but it doesn't discuss this. >>> >>>> 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. >>> Ok. >>> >>> >>> >>> /martin >>> _______________________________________________ >>> netmod mailing list >>> netmod@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/netmod >> >> >