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 protected]> 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 protected] C:530.902.3131 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
