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
On 07/02/2013 21:43, Michael Baer wrote:
> 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
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
