Re: [sidr] two stranded docuemnts - stake time
> 在 2016年7月28日，22:32，Tim Bruijnzeels 写道： > > Hi, > >> On 22 Jul 2016, at 17:48, Stephen Kent wrote: >> >> It seems preferable to describe the first motivating case without reference >> to a specific RIR. > > Although I appreciate that Randy is trying to explain the case in terms > anyone can understand, it would be preferable to keep it general. And adverse actions I-D offers expressions to support the example. Sections of it might be cited as well. Di ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] I-D Action: draft-ietf-sidr-lta-use-cases-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing of the IETF. Title : Use Cases for Localized Versions of the RPKI Author : Randy Bush Filename: draft-ietf-sidr-lta-use-cases-07.txt Pages : 5 Date: 2016-07-28 Abstract: There are a number of critical circumstances where a localized routing domain needs to augment or modify its view of the Global RPKI. This document attempts to outline a few of them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-lta-use-cases/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-lta-use-cases-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-lta-use-cases-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] two stranded docuemnts - stake time
Hi, > On 22 Jul 2016, at 17:48, Stephen Kent wrote: > > It seems preferable to describe the first motivating case without reference > to a specific RIR. Although I appreciate that Randy is trying to explain the case in terms anyone can understand, it would be preferable to keep it general. > (Including a parenthetical note about the historical precedent of a Dutch > court order involving RIPE is relevant and might be included.) If there was such a precedent, but there isn't. I have raised this before, but again... The incident you refer to is in fact a case where the FBI asked the Dutch police to enforce an order issued by a US court, which would demand that the RIPE NCC take all measures to ensure that the suspect’s IP address registration was not transferred or amended. And while the RIPE NCC initially carried out this order (to freeze, not remove/modify etc) it also immediately sought legal advice, and following that advice it was concluded that there was no legal basis for the order. So, as far as precedents go, this is a different case altogether (freeze contact information, not remove/modify routing information), and actually points in the opposite direction. More details here: https://www.ripe.net/publications/news/about-ripe-ncc-and-ripe/summons-of-the-ripe-ncc-against-the-state-of-the-netherlands Tim ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] two stranded docuemnts - stake time
Hi all, I believe SLURM is useful work. I know that RPSTIR has an implementation, but the RIPE NCC RPKI Validator (yes, we need a cool name..) has been implementing the same semantics for a long time (years) - using a different format. I do not know whether rcynic has implemented similar. Rob? Two implementation have implemented similar behaviour independently. In any case I think there is benefit in having a common format and semantics defined, and I supported adoption. But.. I do have concerns and questions about the *current* format defined in the document. It represents the RPSTIR implementation. I have been meaning to discuss and comment as an RP implementor but unfortunately have not been able to do so, due to other priorities. Going forward I appreciate that Declan Ma volunteers to take on the work as author, but I think it would be best to have author representatives of each of the three RPs to ensure that the resulting configuration file and semantics are understood by all and feasible to implement by all. In short I would like to volunteer to co-author and would kindly ask Rob if he would be willing. I have no problems with moving this to sidr-ops and having the discussion on content then and there. Tim > On 24 Jul 2016, at 01:58, David Mandelberg wrote: > > Di, enjoy. You have my permission to take over SLURM. Let me know if > there's anything I can do to help. > > On 07/22/2016 05:48 AM, Declan Ma wrote: >> Sandy & Chris, >> >> Thank Steve for recommending me to take over SLURM. >> >> With David’s permission, I would be happy to assume responsibility for SLURM. >> >> I think SLURM is quite important to RPKI operation in term of local network. >> >> SLURM provides a simple way to enable INR holders to establish a local, >> customized view of the RPKI, by overriding RPKI repository data if needed. >> >> In particular, I was exchanging notes with David earlier on the use of >> multiple SLURM files among others, which I believe is worth more text in the >> next version of SLURM. >> >> Di >> >>> 在 2016年7月21日，19:42，Stephen Kent 写道： >>> >>> Sandy & Chris, >>> >>> I believe Chris' declaration is premature. >>> >>> I anticipate that Dr. Ma may want to take over slurm, with David's >>> permission. >>> >>> With a few minor tweaks the use cases doc can be done. >>> >>> Steve >>> >>> >>> ___ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> >> >> >> >> >> ___ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] adverse actions -01 posted
Hi Steve, > On 26 Jul 2016, at 20:41, Stephen Kent wrote: > >> As I said earlier there are circumstances where we as RIPE NCC are bound to >> reclaim resources from holders against their will. And however "unwanted" >> this may be by the holder of the resources, this is not because we bear >> these holders any ill will (and actually in most cases there is no dispute). >> Reclaiming resources is based on policy discussed in a bottom-up policy >> development process in our address policy working group. Calling this >> "adverse" implies that the holder is "right", and RIPE NCC is "wrong" in >> these cases. > Use of the term does not imply that the INR holder is right and the CA is > wrong. The fact that you keep using RIPE as the example CA suggests, to me, > that you are biased and very defensive, in your interpretation of the term. I keep using RIPE as an example because I am speaking out of my own experience - an experience that I believe is relevant to this discussion. And while I expect that others who act as parent CA, at any level, might share my concern, I don't presume to speak on their behalf. Tim ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] adverse actions -01 posted
> On 28 Jul 2016, at 02:10, Randy Bush wrote: > Tim offered no suggestion for a different term, which is not helpful. >>> the suggestion was "unwanted". >> I reread Tim's message; I don't interpret it as having suggested >> "unwanted" as an alternative. > > that is clear. others, such as matthias and i, did. but this is not > productive. > > to be clear, i hereby suggest s/adverse/unwanted/ To be clear, that was my intended suggestion Tim > > randy > > ___ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
