Subject: [MIB-DOCTORS] MIB Doctor review of draft-ietf-sidr-rpki-rtr-protocol-mib-04

From: "David Harrington" <[email-masked]>
Date: Tue, 15 Jan 2013 10:39:39 -0500

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:[email-masked]> [email-masked]

+1-603-828-1401

---

From: Benoit Claise <[email-masked]>
Date: Mon, 21 Jan 2013 23:42:22 +0100

Hi,

On top of David's feedback, here is mine.

-
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-26 is now RFC 6810

-

                      Copyright (c) 2011 IETF Trust and the persons
                      identified as authors of the code. All rights
                      reserved.
	-> 2013

-

    rpkiRtrCacheServerPreference OBJECT-TYPE
        SYNTAX       Unsigned32 (0..255)
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION "The routers' preference for this
                     RPKI cache server.

                     A lower value means more preferred. If two
                     entries have the same preference, then the
                     order is arbitrary.

                     If no order is specified in the configuration
                     then this value is set to 255."

I don't understand the sentence:

		    If no order is specified in the configuration
                     then this value is set to 255."

Configuration of what? This is misleading as this is a non read-write 
(monitoring) MIB module.
Do you mean a config knob in RFC 6810? Please specify.

-

-
rpkiRtrCacheServerTimeToRefresh OBJECT-TYPE
        SYNTAX       Integer32
        UNITS       "seconds"
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION "The number of seconds remaining before a new
                     refresh is performed via a Serial Query to
                     this cache server over this connection.

                     A negative value means that the refresh time
                     has passed this many seconds and the refresh
                     has not yet been completed.

                     Upon a completed refresh (i.e. a successful
                     and complete response to a Serial Query) the
                     value of this attribute will be re-initialized
                     with the value of the corresponding
                     rpkiRtrCacheServerRefreshTimer attribute."

A reference to RFC 6810 section 5.3 would be useful (as flagged by David)

-
Clarifying question:
    rpkiRtrPrefixOriginTableEntry OBJECT-TYPE
        SYNTAX       RpkiRtrPrefixOriginTableEntry
        MAX-ACCESS   not-accessible
        STATUS       current
        DESCRIPTION "An entry in the rpkiRtrPrefixOriginTable.
                     This represents one announced prefix."
        INDEX       { rpkiRtrPrefixOriginAddressType,
                      rpkiRtrPrefixOriginAddress,
                      rpkiRtrPrefixOriginMinLength
                    }
        ::= { rpkiRtrPrefixOriginTable 1 }

This table gives the link to the unique ID of the connection with

    rpkiRtrPrefixOriginCacheServerId OBJECT-TYPE
        SYNTAX       Unsigned32 (1..4294967295)
        MAX-ACCESS   read-only
        STATUS       current
        DESCRIPTION "The unique ID of the connection to the cache
                     server from which this announcement was received.
                     That connection is identified/found by a matching
                     value in attribute rpkiRtrCacheServerId."
        ::= { rpkiRtrPrefixOriginTableEntry 6 }

Am I assuming correctly that we can only receive a (addressType, address, minLength) from one and only one connection?

Regards, Benoit

> This review is officially done for the OPS  AD, and the AD needs to 
> decide which points must be addressed.
>
> 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.
>
> 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 value is used as a relation between tables. What 
> are the fate-sharing requirements? 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 
> 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:
>
> 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
>
> "The SNMP agent MUST throttle the generation of
>
> information. What happens if the notification is being reported by 
> something other than SNMP? Is throttling still required?
>
> 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?
>
> 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
>
> [email-masked] <mailto:[email-masked]>
>
> +1-603-828-1401
>