>>> 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 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? _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
