Re: [Idr] Thoughts on

"Susan Hares" <> Tue, 21 March 2017 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25900129B83 for <>; Tue, 21 Mar 2017 09:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NwunzszfWdKH for <>; Tue, 21 Mar 2017 09:26:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3331A129B44 for <>; Tue, 21 Mar 2017 09:26:32 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'Robert Raszuk' <>, 'Eric C Rosen' <>
Cc: 'idr wg' <>
References: <048701d29cd9$15204b80$3f60e280$> <022201d29ce6$ffb2ba40$ff182ec0$> <> <>
In-Reply-To: <>
Date: Tue, 21 Mar 2017 12:04:56 -0400
Message-ID: <02e901d2a25c$e29e45c0$a7dad140$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EA_01D2A23B.5B8F8BF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHgLJVhftftdlZ2OeQGM5dxbx7ZtQIfusEjApalZLoCoxIrnaFJkpMQ
Content-Language: en-us
Archived-At: <>
Subject: Re: [Idr] Thoughts on
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Mar 2017 16:26:34 -0000



Please see my post to Eric responding to politics and delay.  


What you are describing is a FCFS.  Rather than a wiki, why not IANA?  IANA can provide and maintains these numbers.  IANA’s response time on FCFS allocations is quick.   If you believe a FCFS is appropriate for BGP attributes and AFI/SAFs,  I encourage you to write a draft on that topic.  




From: Idr [] On Behalf Of Robert Raszuk
Sent: Tuesday, March 14, 2017 4:35 PM
To: Eric C Rosen
Cc: Susan Hares; idr wg
Subject: Re: [Idr] Thoughts on



I very much agree with Eric here. 


All what needs to be done to prevent squatting is a public wiki page in IETF (across WGs) with pool of available BGP attribute code points as well as AFI/SAFIs where whoever has a draft and is implementing it ahead of IETF politics takes next available code and links it with a draft name. Then she or he may come to WG with proven implementation at hand.


By default considering how fast IETF moves such self registration could be valid for 5 years. After that either the spec is dead and it is ok to free up the code or draft becomes RFC. Submitter can free up the code earlier too. 


All committees, designated experts, tiger/design teams will just have opposite effect and granted will scare folks who need to implement something for their internal use or for their dedicated customers resulting in much more squatting. Does anyone really believes that if "expert" tells  "NO" then the given implementation will get abandoned ? 


The same should apply to other protocols .. however BGP is the lowest hanging fruit so one could start with that.




On Tue, Mar 14, 2017 at 8:38 PM, Eric C Rosen <> wrote:

I don't think we need any more procedural hurdles that will slow down the allocation process or that will introduce more politics into it.

The draft does not seem to be a solution to any problem, it just adds process and politics.  It claims to have the goal of "increasing the pace of early allocation", and proposes to do this by requiring allocations to be approved by a committee of WG chairs or other designated "experts".  It neglects to say how having more committees will increase the pace.

No doubt the designated experts will make their decisions "soon", as that term is defined in draft-farrel-soon.

Adoption of this draft will result in more squatting rather than less.

Furthermore, a number of the mentioned registries were not established by the IDR WG, and I don't see that the IDR WG has any standing to request changes in the registration policies of those registries.

Idr mailing list