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

From: Chris Morrow <[email-masked]>
Date: Thu, 03 Jan 2019 17:43:55 -0800

Chris Morrow has requested publication of draft-ietf-sidrops-lta-use-cases-04 as Informational on behalf of the SIDROPS working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2019 16:58:12 -0500

Chris,

All of the issues I raised with the prior version apply to this version, 
as there have been no substantive changes. This doc should cite SLURM, 
and note that the solution presented there does not require creating new 
TAs, but does enable creation of a local view of the RPKI.

Steve
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops
>

---

From: Warren Kumari <[email-masked]>
Date: Sat, 12 Jan 2019 13:49:38 -0500

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.

W

On Thu, Jan 3, 2019 at 8:43 PM Chris Morrow <[email-masked]> wrote:

> Chris Morrow has requested publication of
> draft-ietf-sidrops-lta-use-cases-04 as Informational on behalf of the
> SIDROPS working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 12 Jan 2019 22:20:07 +0000

> 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.

Nick

---

From: Di Ma <[email-masked]>
Date: Sun, 13 Jan 2019 06:43:35 +0800

Nick,

> 在 2019年1月13日，06:20，Nick Hilliard <[email-masked]> 写道：
> 
>> 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.

There is a standardized way to do so, as specified by RFC 8416, called SLURM, which by the way has been supported by some RP software such as Routinator and RPSTIR.

I agree with what Steve suggested, draft-ietf-sidrops-lta-use-cases should cite SLURM.

Di