Re: [GROW] FW: New Version Notification for draft-manderson-routing-intent-00.txt

Arturo Servin <aservin@lacnic.net> Wed, 29 June 2011 11:53 UTC

Return-Path: <aservin@lacnic.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9C221F867C for <grow@ietfa.amsl.com>; Wed, 29 Jun 2011 04:53:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.62
X-Spam-Level:
X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
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 iuXHc9ajjX-Z for <grow@ietfa.amsl.com>; Wed, 29 Jun 2011 04:53:04 -0700 (PDT)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3B21F867A for <grow@ietf.org>; Wed, 29 Jun 2011 04:53:04 -0700 (PDT)
Received: from [192.168.1.103] (r186-48-230-228.dialup.adsl.anteldata.net.uy [186.48.230.228]) by mail.lacnic.net.uy (Postfix) with ESMTP id 54F54308432; Wed, 29 Jun 2011 08:52:54 -0300 (UYT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Arturo Servin <aservin@lacnic.net>
In-Reply-To: <CA30AFA4.16F62%terry.manderson@icann.org>
Date: Wed, 29 Jun 2011 08:52:53 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E40782C0-E53F-464A-94EE-A0EE9A78BA62@lacnic.net>
References: <CA30AFA4.16F62%terry.manderson@icann.org>
To: Terry Manderson <terry.manderson@icann.org>
X-Mailer: Apple Mail (2.1084)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
Cc: "grow@ietf.org" <grow@ietf.org>
Subject: Re: [GROW] FW: New Version Notification for draft-manderson-routing-intent-00.txt
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grow>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2011 11:53:05 -0000

Benson,

	I agree with Terry.

	When the proposal was sent to the IETF the environment was different. We still have v4 addresses in IANA's pool and I think that the feeling was "we do not want to give that precious space for a shared pool because there is one already". Now things are different, there are no more addresses in the central pool, v4 address are more scarce, ISPs claim that need space for transition technologies to v6, and the ARIN community is willing to give some space for that purpose (this last one is the important one IMHO).

	I cannot speak for others, but in my view a new I+D similar to the last one (I think it was sent to OPSWAG WG) with some amendments would have more opportunities to be adopted.

Regards,
.as



On 28 Jun 2011, at 21:32, Terry Manderson wrote:

> Hi Benson,
> 
> Not speaking to the utility of that particular proposal, but I would think
> that the policy (ARIN Draft Policy 2011-5) might also need to be reposted as
> an IETF RFC to modify the IANA address registry. (in much the same way
> rfc3849 came from the APNIC allocation)
> 
> If that were the case then the IANA address registry would reflect it.
> 
> Otherwise, I am not aware of any provision for an individual RIR to set a
> particular prefix's status without some global policy work being done.
> 
> Cheers
> Terry
> 
> 
> On 24/06/11 10:27 AM, "Benson Schliesser" <bschlies@cisco.com> wrote:
> 
>> 
>> 
>> On 6/23/11 6:54 PM, "Terry Manderson" <terry.manderson@icann.org> wrote:
>> 
>>> The obvious example (and please - I don't care to buy into the brouhaha of
>>> 6to4 going historic) is "192.88.99.0/24 reserved for 6to4 Relay Anycast"
>>> 
>>> The designated status is reserved, but it is routable.
>> 
>> Thanks for the clarification, Terry.  Your explanation makes sense.
>> 
>> Out of curiosity:  In the event that an RIR sets aside a block to be Non
>> Routable (such as ARIN Draft Policy 2011-5) would the PRI designation be
>> ALLOCATED Non Routable, or something else?
>> 
>> Cheers,
>> -Benson
>> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow