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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 27 December 2012 11:50 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8452321F8855 for <gen-art@ietfa.amsl.com>; Thu, 27 Dec 2012 03:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.219
X-Spam-Level:
X-Spam-Status: No, score=-100.219 tagged_above=-999 required=5 tests=[AWL=-1.298, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_ILLEGAL_IP=1.908, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKy0iQBkb9qI for <gen-art@ietfa.amsl.com>; Thu, 27 Dec 2012 03:50:02 -0800 (PST)
Received: from mail-wg0-x229.google.com (wg-in-x0229.1e100.net [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFE721F8610 for <gen-art@ietf.org>; Thu, 27 Dec 2012 03:50:02 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id ds1so3712251wgb.2 for <gen-art@ietf.org>; Thu, 27 Dec 2012 03:50:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Eta5awe4JDXSD4CVdzOa2dfOwAkzuKXZPDqMDI91DVQ=; b=QAi9PC0TItuASIc+RSe+g6gmPp+rOyo+dAGhQft84xdAC4OL4SSBAOA4WhCGAmV+hD JVsUphRPmBFQhFpvc1xeinkSZJalVdvUdye41NyH5kOdI6nbF3RuVOwDyl66OQCBqYRw gkX7z0Np4GCD3s8sn5/sWLVdSVwCNloQnc9IMdMOoDXCah81eqaRFCBjbCnQMOR10FUI taSHMZTDaFoxV6MD/yjpkW0BkhBAxngKTHHndXvDwbhJ5NVTHoWEcUogO6yuj0U0Txzg SvAU0kfnnohzpuDIegaTqEUHlTj+Wq/XhMl366ETSpQqUWrKrUGVa3cZ6MOXCP1ypBdL pK3g==
X-Received: by 10.180.8.130 with SMTP id r2mr40337099wia.28.1356609001168; Thu, 27 Dec 2012 03:50:01 -0800 (PST)
Received: from [192.168.1.65] (host-2-102-217-137.as13285.net. [2.102.217.137]) by mx.google.com with ESMTPS id hg17sm56972842wib.1.2012.12.27.03.49.59 (version=SSLv3 cipher=OTHER); Thu, 27 Dec 2012 03:49:59 -0800 (PST)
Message-ID: <50DC35F1.5060809@gmail.com>
Date: Thu, 27 Dec 2012 11:50:09 +0000
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
References: <50DAE47F.4030704@gmail.com> <50DC18C5.5040600@bwijnen.net>
In-Reply-To: <50DC18C5.5040600@bwijnen.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-sidr-rpki-rtr-protocol-mib.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, "sidr-chairs >> SIDR Chairs" <sidr-chairs@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-sidr-rpki-rtr-protocol-mib-04.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Dec 2012 11:50:03 -0000

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
>