Re: [sidr] Current document status && directionz

Rob Austein <> Tue, 06 September 2016 22:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8BF9012B18E for <>; Tue, 6 Sep 2016 15:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.409
X-Spam-Status: No, score=-3.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id emzO59yKVsta for <>; Tue, 6 Sep 2016 15:02:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AF3912B0D7 for <>; Tue, 6 Sep 2016 15:02:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (not verified)) by (Postfix) with ESMTPS id A69C813994 for <>; Tue, 6 Sep 2016 22:02:00 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id F1005420823A for <>; Tue, 6 Sep 2016 18:00:00 -0400 (EDT)
Date: Tue, 06 Sep 2016 18:00:00 -0400
From: Rob Austein <>
In-Reply-To: <>
References: <> <> <> <> <>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Subject: Re: [sidr] Current document status && directionz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2016 22:02:04 -0000

I guess one question here is the purpose of publishing this document:

a) If the purpose of asking the WG to publish is a hope that the WG
   will agree that this is a good idea, then I'm with Randy and Steve
   in the "hell no" camp.

b) If the purpose is to document something that the RIRs have
   unilaterally decided to do whether the IETF likes it or not, I
   guess we should thank them for documenting their intentions, and
   publish it with a big IETF / IESG disclaimer saying that it's a
   really bad idea but not something the IETF can prevent.  I suppose
   we could refuse to publish entirely in this case, but suspect that
   just makes it harder for newcomers to understand what happened.

My understanding was that we were already well into case (b) territory.

Carlos et al, please correct me if I'm wrong and the RIRs are willing
to back down on this.