Hi,

 

Been a while since I've done one of these ;-)

A few comments:

 

This review is officially done for the OPS  AD, and the AD needs to decide
which points must be addressed.

Most of the comments should be non-controversial and easy to address.

There are a couple syntax questions.

Most technical questions are about ensuring clear and unambiguous
descriptions to ensure interoperability.

 

I noticed that a MIB is not listed in the sidr charter, but this is a sidr
document. 

I guess one could raise the point that development of an RPKI MIB has not
been "sanctioned" by the general IETF during WG charter review.

As a MIB Doctor, I of course think it's a reasonably good idea, assuming MIB
management of this routing security functionality is a good fit. 

I assume the WG does, and the IETF will.

I don't know if the OPS AD cares (or the RTG ADs care). Their business.

 

Is LAST-UPDATED "201110140000Z" still correct?

 

We've crossed a year boundary, so the 2012 copyright might need updating.

 

RpkiRtrConnectionType/other: s/non/none

 

rpkiRtrCacheServerConnectionType: to prevent any ambiguity, I think it might
be better to describe this only as the connection type, and remove the "or
transport security suite" from the object description. The fact that the
connection type might be a transport security suite can be spelled out in
the connection type T-C. Even there, I would be careful of ambiguity, to
provide clear guidance/constraints to future developers of added
enumerations.

 

rpkiRtrCacheServerPreference: would a DEFVAL be a good idea to specify the
255 default?

 

rpkiRtrCacheServerTimeToRefresh could benefit from a reference. Is the time
to refresh always decremented by 1, or can an implementation choose to only
reflect time to refresh in, say, 5 or 10 second increments? Is there a
maximum negative value that makes sense here? Is it possible to require a
wrap if no refresh is completed? Or should the value latch at the maximum
negative value?

 

rpkiRtrCacheServerId would benefit from a reference. 

 

rpkiRtrCacheServerId value is used as a relation between tables. What are
the fate-sharing requirements? Must a corresponding
rpkiRtrPrefixOriginCacheServerId  exist? Or if
rpkiRtrPrefixOriginCacheServerId  exists, must a corresponding
rpkiRtrCacheServerId exist? If one entry is deleted, must the corresponding
entry be deleted to prevent one table from reusing an identifier that is
still in use in the other table?

 

s/debuging/debugging/

 

The Errors table contains counters that represent "the number of XXX errors
received." This description seems to indicate that counters start at zero
(and implicitly reset to zero on a discontinuity). An NMS developer
certainly might interpret this text as indicating zero-based counters. I
think if there is an assumption these are zero-based, there are TC-s that
could be used to show that assumption. OTOH, counters typically are not
zero-based because if errors occur during system startup, the counter might
be initialized partway through the startup and not reflect all the errors
that occurred during the startup phase. I think this table would benefit
from a discussion of the expected initial values (zero or
unpredictable/implementation-dependent) and the nature of expected
discontinuities, so NMS developers can be sure to understand the relevant
assumptions.  (is the only discontinuity a restart of the management system?
What about rollovers? Are all these error counters not preserved across
system restarts? Or can an implementation choose to preserve them across
resets to enhance debugging history?) Some of this discussion would seem to
apply to all the error counters; if that is true of all current counters and
should be true for an potentially new counters added to this table, this
type of discussion could be captured in the Table or TableEntry description.
(including the discussion of rpkiRtrDiscontinuityTimer, which seems to apply
to the whole table).

 

The errors objects might benefit from a reference to the descriptions of
errors in RPKI specs, so NMS implementors are likely to interpret the
counters consistently.

 

And to be clear, these counters count the number of messages from the cache
server reporting a remote error, right? These counters never count an error
(found locally) in a message from the remote server? So it's not actually
the number of errors received, but the number of server-generated
error-reports received? Right? That could be made slightly clearer.

 

The comment discussing ROATable probably isn't needed in the final document,
since no official REVISION included ROATable, right?

 

s/recieved/received/

 

rpkiRtrPrefixOriginAddressType: "Only IPv4 and IPv6 are supported." - This
is an enumeration that could be extended in the future if RPKI ever supports
additional address types (like ipv7 or something); the limitation of
ipv4/ipv6 is presumably a limit set by RPKI; it should not be a limit set by
the MIB object, which could not be updated to match an updated RPKI. Each of
these objects should reference the current limit in RPKI, and allow for
future SMIv2 extensibility of the enumeration so extending it would not
involve obsoleting each object and defining a new object without limits. By
indicating that the enumeration could legally be extended at some point in
the future, NMS developers can plan accordingly; the current approach could
inadvertently encourage hard-coding support for these, and only these, two
enumeration values.

>From RFC4001:

"The InetAddressType and InetAddress objects SHOULD NOT be sub-typed

   in object definitions.  Sub-typing binds the MIB module to specific

   address formats, which may cause serious problems if new address

   formats need to be introduced.  Note that it is possible to write

   compliance statements indicating that only a subset of the defined

   address types must be implemented to be compliant."

Would putting the limit in a compliance clause rather than the object
description clause work?

 

Could RPKI ever be implemented in a non-global environment, where address
zoning might be needed?

 

rpkiRtrPrefixOriginAddress  says "The format of the address is defined by
the

                    value of the corresponding instance of

                    rpkiRtrCacheServerAddressType."

Shouldn't this be rpkiRtrPrefixOriginAddressType?

 

rpkiRtrCacheServerConnectionStateChange says: 

"                   The SNMP agent MUST throttle the generation of

                    consecutive rpkiRtrCacheServerConnectionStateChange

                    notifications such that there is at least a

                    5 second gap between them."

A MIB is theoretically separate from the protocol used to carry the
information. What happens if the notification is being reported by something
other than SNMP? Is throttling still required?

 

I am a bit concerned by the text that describes throttling generation;
should generation be throttled, or should sending be throttled? The need to
recognize a status change event and request a notification be sent (i.e.,
generation) might be handled by the underlying instrumentation, while
sending the notification would seem to be the purview of the protocol being
used (i.e., the SNMP engine). If I have a down event followed by an up event
2 seconds later, should I not generate a notification reporting the state
change? What if I have no subsequent up event to report? Should the NMS
continue to believe the state is down? Or should I just queue the up
notification for 3 seconds and then send it? 

(and I realize queuing could just push the excessive generation problem down
the road, AND lead to untimely reports). The current text is unclear about
this and I am concerned whether there might be interoperability problems
caused by differing interpretations of how to throttle these notifications.
I know we require a discussion of throttling; is this the best way to
document the throttling for these notifications? 

 

In rpkiRtrReadOnlyCompliance, s/Implemntation/Implementation/

While read-write and read-create may not be envisioned, it is probably
incorrect to state that the MIB module contains only read-only objects
without specifying that this is true for the current REVISION. I have a
concern about naming this so generically; what happens if new read-only
objects are added in the future? The new objects cannot be added to this
compliance clause, so the goal of clarity and truth in advertising will not
necessarily hold up. I recommend naming the compliance clause (possibly
using the assigned RFC#) so it is clear that this list of objects applies to
the current REVISION of the MIB module.

 

Are none of the objects in this MIB potentially sensitive to disclosure?
None are listed.

 

The MIB security boilerplate references 3414 and 3826. There has been some
discussion of whether these should be considered normative.

 

 

David Harrington

 <mailto:dbharrington@comcast.net> dbharrington@comcast.net

+1-603-828-1401