Hi Bert, inline again...
On 27/12/2012 09:45, Bert Wijnen (IETF) wrote:
> Thanks for your review Brian,
> inline
>
> On 12/26/12 12:50 PM, Brian E Carpenter wrote:
>> Please see attached review.
>>
>> Brian
>>
>>
>>
>>
>> draft-ietf-sidr-rpki-rtr-protocol-mib-04-carpenter.txt
>>
>>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2012-12-26
>> IETF LC End Date: 2013-01-14
>> IESG Telechat date:
>>
>> Summary: In good shape, two open issues
>> --------
>>
>> Comment:
>> --------
>>
>> I see a note in the tracker that the MIB Doctor review "still needs to
>> happen".
>> Since I'm not competent as a MIB doctor, I hope this has been done.
>>
>> Major issue:
>> ------------
>>
>> In draft-ietf-sidr-rpki-rtr-26 the list of caches is stated to include
>>
>> Name: The IP Address or fully qualified domain name of the cache.
>>
>> I find no way to represent the FQDN option in the MIB module. We state
>> explicitly in the 6renum documents that it should be possible to
>> configure
>> network elements using names in preference to addresses, so I think
>> this is
>> a problem. Of course, at run time, the FQDN will have been resolved into
>> an address, but why isn't there also an FQDN object in the MIB module?
>> It seem like there should be rpkiRtrCacheServerFQDN.
>>
>
> It would not be an extra object I think.
I wondered about that. Is there a case where the operator might want
to know both the FQDN (as configured) and the IP address (as found
in DNS)? In that case it would need to be an extra object. However,
your proposal is completely logical.
One more comment below.
> It states IP address OR FQDN, so in order to catch that, the current
>
> rpkiRtrCacheServerAddressType OBJECT-TYPE
> SYNTAX InetAddressType { ipv4(1), ipv6 (2) }
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION "The network address type of the connection
> to this RPKI cache server.
>
> Only IPv4 and IPv6 are supported."
> ::= { rpkiRtrCacheServerTableEntry 1 }
>
> rpkiRtrCacheServerRemoteAddress OBJECT-TYPE
> SYNTAX InetAddress (SIZE(4|16))
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION "The remote network address for this connection
> to this RPKI cache server.
>
> The format of the address is defined by the
> value of the corresponding instance of
> rpkiRtrCacheServerAddressType."
> ::= { rpkiRtrCacheServerTableEntry 2 }
>
>
>
> Could be changed to include dns:
>
> rpkiRtrCacheServerAddressType OBJECT-TYPE
> SYNTAX InetAddressType { ipv4(1), ipv6 (2), dns(16) }
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION "The network address type of the connection
> to this RPKI cache server.
>
> Only IPv4 and IPv6 are supported."
> ::= { rpkiRtrCacheServerTableEntry 1 }
>
> rpkiRtrCacheServerRemoteAddress OBJECT-TYPE
> SYNTAX InetAddress
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION "The remote network address for this connection
> to this RPKI cache server.
>
> The format of the address is defined by the
> value of the corresponding instance of
> rpkiRtrCacheServerAddressType."
> ::= { rpkiRtrCacheServerTableEntry 2 }
>
> Note that the Remote address can now have a size of up to 255 octets.
> And we need to specify WHEN the dns name will be resolved.
> I'd have to rely on the RPKI-RTR protocol gurus to tell me when
> that would happen. This is the TC definition for a DNS name in
> this field:
> InetAddressDNS ::= TEXTUAL-CONVENTION
> DISPLAY-HINT "255a"
> STATUS current
> DESCRIPTION
> "Represents a DNS domain name. The name SHOULD be fully
> qualified whenever possible.
>
> The corresponding InetAddressType is dns(16).
>
> The DESCRIPTION clause of InetAddress objects that may have
> InetAddressDNS values MUST fully describe how (and when)
> these names are to be resolved to IP addresses.
>
> The resolution of an InetAddressDNS value may require to
> query multiple DNS records (e.g., A for IPv4 and AAAA for
> IPv6). The order of the resolution process and which DNS
> record takes precedence depends on the configuration of the
> resolver.
>
> So that is what we need to describe. I guess we'd have to
> bring this to teh SIDR WG if we want to add that functionality.
>
>> Minor issue:
>> ------------
>>
>> In draft-ietf-sidr-rpki-rtr-26 the preference is defined as
>>
>> Preference: An unsigned integer denoting the router's preference to
>> connect to that cache, the lower the value the more preferred.
>>
>> That doesn't specify a range. The MIB specifies the range as 0..255:
>>
>> rpkiRtrCacheServerPreference OBJECT-TYPE
>> SYNTAX Unsigned32 (0..255)
>>
>> Is this an oversight in draft-ietf-sidr-rpki-rtr? If not, it seems
>> necessary to state what should be in the MIB object if preference>255.
>>
>
> Since the MIB module specifies the range, a value >255 would be return
> a "wrongValue" error. I.e. a value that according to the MIB Syntax
> can never be set.
>
> Now.. it might be good if the protocol document would specify this too.
> But I do not think it is a fatal flaw.
Agreed. It might be a bit frustrating for the operator though. Maybe
you should add a comment in the MIB module that this might happen.
Brian
>
>> Nit:
>> ----
>>
>> "Two Notification have been defined..."
>> s/Notification/Notifications/
>
> OK, we can easily fix that, otherwise I am sure RFC-Editor will fix it.
>
> Bert
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
