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