Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04

Nick Hilliard <> Sat, 12 January 2019 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 690001310F6; Sat, 12 Jan 2019 14:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G_D3ByLVVzbN; Sat, 12 Jan 2019 14:20:13 -0800 (PST)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69B571310FC; Sat, 12 Jan 2019 14:20:12 -0800 (PST)
Received: from crumpet.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x0CMK9el025791 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jan 2019 22:20:09 GMT (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be crumpet.local
To: Warren Kumari <>
Cc: Chris Morrow <>, SIDROps Chairs <>,, IESG_Secretary <>
References: <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Sat, 12 Jan 2019 22:20:07 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.9
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Sidrops] Publication has been requested for draft-ietf-sidrops-lta-use-cases-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Jan 2019 22:20:20 -0000

Warren Kumari wrote on 12/01/2019 18:49:
> I'm returning this document to the Working Group because I do not see 
> sufficient evidence of consensus.
> With no hats - I personally believe that documenting the use cases is 
> useful, and would like to see this / a document describe the operational 
> practices of having a local TA.

this is likely to be useful from the point of view of dealing with long 
term concerns about centralisation of control of the global routing 
infrastructure, that have been aired from time to time in various fora, 
both private and public.  The three example cases are realistic (cf: 
RIPE NCC court order regarding registration of resources in 2011).

It would also be important to note that the local trust anchor mechanism 
suggested here could also be created to override legitimate 
announcements, e.g. states who wish to control the routing tables of 
service providers in their legal jurisdiction.  Knives make no judgement 
about what they cut through.

I support publication of the draft.  It may need more content, e.g. 
description of methods to implement the ideas that it suggests.