On Aug 5, 2012, at 4:47 PM, Fred Baker (fred) wrote: >>>> At a minimum, we need to fix the fact that ospfv3RestartAge and >>>> ospfv3NbrRestartHelperAge are defined as Ospfv3UpToRefreshIntervalTC which >>>> is Unsigned32 (1..1800). This poses a problem of what to return when >>>> these MIB variables are not applicable since 0 is invalid. >>>> We may find some other additions and corrections now that we have some >>>> implementation experience. Speaking as OSPF WG co-chair, we'd be happy if >>>> you would be willing to take on this task. >>> >>> If the object is inapplicable, why would it not be treated as if it didn't >>> exist in the scenario? On a GET, return noSuchObject, and on a GET-NEXT or >>> GET-BULK, skip it? Both objects are read-only. Do we have an erratum on >>> these? >> >> This is not an option since these are mandatory objects in the MIB >> compliance. > > Mandatory to implement. I didn't say "don't implement them", I said "don't > respond with them when they are inappropriate". By your argument, they can > never be zero, because they will always have a value in 1..1800, because they > are mandatory.
I discussed this with one MIB expert in Vancouver and their opinion was that if they are mandatory, a value must be returned as well. > >> I can poll the implementation that reported the problem. I suspect it was >> just a matter of supplanting their MIB tools to allow 0 to be returned. > > "Just"… > > If the objects can have a value that is not in 1..1800, their range must > include the other value. We can create a new TC or simply use 0..1800, but we > have to somehow explain what zero means. If we change the TC that the two > objects use right now, that also affects a number of ReadCreate objects: > under what circumstances may they be created with the value zero? My comment was based on the fact that short of a MIB respin, there didn't appear to be a viable option. Thanks, Acee
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
