Subject: Re: [Gen-art] Gen-ART telechat review of draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt

From: Michael Baer <[email-masked]>
Date: Thu, 7 Feb 2013 13:43:44 -0800

Hi Brian,

We submitted an update draft earlier I have changes in the update
related to your comments inline below.

>>>>> On Sat, 19 Jan 2013 17:11:02 +0000, Brian E Carpenter <[email-masked]> said:

    BC> I have been selected as the General Area Review Team (Gen-ART)
    BC> reviewer for this draft (for background on Gen-ART, please see
    BC> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

    BC> Please wait for direction from your document shepherd or AD
    BC> before posting a new version of the draft.

    BC> Document: draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt Reviewer:
    BC> Brian Carpenter Review Date: 2013-01-19 IETF LC End Date:
    BC> 2013-01-14 IESG Telechat date: 2013-01-24

    BC> Summary: In good shape, two open issues pending from LC
    BC> review.  --------

    BC> Comment: --------

    BC> I see a note in the tracker that the MIB Doctor review "still
    BC> needs to happen".  However, one of the authors is a MIB doctor.

    BC> Major issue: ------------

    BC> In draft-ietf-sidr-rpki-rtr-26 the list of caches is stated to
    BC> include

    BC>   Name: The IP Address or fully qualified domain name of the
    BC> cache.

    BC> I find no way to represent the FQDN option in the MIB module. We
    BC> state explicitly in the 6renum documents that it should be
    BC> possible to configure network elements using names in preference
    BC> to addresses, so I think this is a problem. Of course, at run
    BC> time, the FQDN will have been resolved into an address, but why
    BC> isn't there also an FQDN object in the MIB module?  I had a
    BC> reply on this topic from one of the authors, but there has been
    BC> no updated draft:
    BC> http://www.ietf.org/mail-archive/web/gen-art/current/msg08031.html

We changed the InetAddressType objects in the draft.  They are no longer
limited by this MIB as to what they can support.  The compliance
statement was also changed to required support for ipv4, ipv6 and dns
types for the InetAddressType objects, i.e. a FQDN can be represented
now.

    BC> Minor issue: ------------

    BC> In draft-ietf-sidr-rpki-rtr-26 the preference is defined as

    BC>  Preference: An unsigned integer denoting the router's
    BC> preference to connect to that cache, the lower the value the
    BC> more preferred.

    BC> That doesn't specify a range. The MIB specifies the range as
    BC> 0..255:

    BC>    rpkiRtrCacheServerPreference OBJECT-TYPE SYNTAX Unsigned32
    BC> (0..255)

    BC> Is this an oversight in draft-ietf-sidr-rpki-rtr? If not, it
    BC> seems necessary to state what should be in the MIB object if
    BC> preference>255.

This object was changed to not have the 255 limit (just the inherit max
value for its Unsigned32 type now).

    BC> "Two Notification have been defined..."
    BC> s/Notification/Notifications/

Missed this fix in the update.

Thanks,
Mike

-- 
Michael Baer
Senior Research Scientist
SPARTA National Security Sector
[email-masked]
C:530.902.3131

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Feb 2013 07:59:06 +0000

Hi Michael, yes thanks, that fixes my issues.

I guess the authors of RFC 4001 knew what they were doing when they wrote:

         To support future extensions, the InetAddressType textual
         convention SHOULD NOT be sub-typed in object type definitions.
         It MAY be sub-typed in compliance statements in order to
         require only a subset of these address types for a compliant
         implementation.

Regards
   Brian Carpenter