Re: [sidr] two stranded docuemnts - stake time

Tim Bruijnzeels <tim@ripe.net> Thu, 28 July 2016 12:36 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8588A12DFC3 for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2016 05:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo9votIbNA-i for <sidr@ietfa.amsl.com>; Thu, 28 Jul 2016 05:36:44 -0700 (PDT)
Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57E012DFAE for <sidr@ietf.org>; Thu, 28 Jul 2016 05:36:43 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bSkYK-00097J-P4 for sidr@ietf.org; Thu, 28 Jul 2016 14:36:42 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-133.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bSkYK-0006V8-Ko; Thu, 28 Jul 2016 14:36:40 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <579404A8.50201@mandelberg.org>
Date: Thu, 28 Jul 2016 14:36:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DE63079-8715-439D-9DD0-F4A697DC4D1E@ripe.net>
References: <yj9oinvzi8gj.wl%morrowc@ops-netman.net> <87E65996-2ACD-4A3A-8D20-1C7911CBBB72@tislabs.com> <58c60c65-b96c-4984-4ba4-4d4e64e51538@bbn.com> <953A2A6D-FAF1-4E99-AD62-048E5A844228@zdns.cn> <579404A8.50201@mandelberg.org>
To: sidr <sidr@ietf.org>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: --------
X-RIPE-Spam-Report: Spam Total Points: -8.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 BAYES_40 BODY: Bayes spam probability is 20 to 40% [score: 0.3950]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a83b1f860d3d8199a9947d347da9f445
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/1SyF7RAEMQ3Wd1WwTzQIykFvQCQ>
Subject: Re: [sidr] two stranded docuemnts - stake time
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2016 12:36:54 -0000

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 <david@mandelberg.org> 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 <kent@bbn.com> 写道:
>>> 
>>> 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