Re: [sidr] Proposal for next steps - chartering sidrops?

Tim Bruijnzeels <tim@ripe.net> Thu, 13 October 2016 11:47 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 4F5B31294A3; Thu, 13 Oct 2016 04:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] 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 8-vui8C07mAa; Thu, 13 Oct 2016 04:47:37 -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 3A0FD128874; Thu, 13 Oct 2016 04:47:37 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1bueTz-0004PE-Ec; Thu, 13 Oct 2016 13:47:33 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-183.ripe.net) by nene.ripe.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from <tim@ripe.net>) id 1bueTz-000406-7m; Thu, 13 Oct 2016 13:47:31 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <CAL9jLaZwxTndmzxq68aDXTrLN2wYM0kGt5S3NTSVGhASoRteBg@mail.gmail.com>
Date: Thu, 13 Oct 2016 13:47:30 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <57FF1011-597F-4B80-98C4-1CB98C81FF22@ripe.net>
References: <dd98327d-4487-d9dc-af63-82ed5ed2f5aa@bogus.com> <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> <f7b3f43c-98e4-5e0d-b48e-a11e374c70f4@bogus.com> <CAL9jLaaVeKn6prkdb+KwQXQJ=4nTRjONJcC=PMqr_sv=SesA_A@mail.gmail.com> <CAL9jLaa9rjL+Bs9YFM0fbG27zUrdhXXkCAqUCOK+9bxnqvWH5Q@mail.gmail.com> <CAL9jLaZwxTndmzxq68aDXTrLN2wYM0kGt5S3NTSVGhASoRteBg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ---------
X-RIPE-Spam-Report: Spam Total Points: -9.8 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a5fd3a9fd0c37a2363b46a54c152cad3
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/KquITf0zeaMoI0lb-gtUH0MmKpI>
Cc: "Benoit Claise \(bclaise\)" <bclaise@cisco.com>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, sidr wg list <sidr@ietf.org>, rtg-ads@tools.ietf.org
Subject: Re: [sidr] Proposal for next steps - chartering sidrops?
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, 13 Oct 2016 11:47:39 -0000

Hi all,

My apologies for being two months late with this reply, but fwiw I would like to support what Carlos and others raised in this thread about sidr-ops being inclusive to CA operators.

Tim

> On 23 Aug 2016, at 16:48, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> 
> routing-ads -> rtg-ads.
> 
> On Tue, Aug 23, 2016 at 10:32 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> (fixed sidr-chairs, don't know routing-ads alias, apparently)
> 
> On Tue, Aug 23, 2016 at 10:22 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
> The changes from Carlos seem ok to me, and declan's points about ca/rir also seem on point.
> thanks! (for fixing the clearly network centric text!)
> 
> On Mon, Aug 22, 2016 at 5:03 PM, joel jaeggli <joelja@bogus.com> wrote:
> On 8/17/16 7:43 PM, Declan Ma wrote:
> > Joel,
> >
> > When we are talking about SIDROPS,  we are referring to that BGP speakers are resorting to RPKI relying party to get verified INR authorization information, which is created by CA and maintained by repository managers.
> >
> > IMHO, network operators are not the only RPKI role that the community is going to solicit input from.  CA operators, repository operators, RP service providers all bear significance as with SIDR Operations, in identifying issues and sharing experiences.
> Yeah there are a bunch of actors who are operators of elements other
> than networks.
> 
> RIRs and CAs spring immediately to mind.
> > Although network operators could also be CA operators, repository operators, RP service providers, yet RIRs, CA and repository backend service providers, and third party RP don’t fall into the category of  ‘network operators’.
> >
> > I would suggest the “The goals of the sidr-ops working group” be adjusted slightly, with CA operators, repository operators, RP service providers involved.
> yeah I think the tent should be inclusive.
> >
> > Di
> >
> >> 在 2016年8月18日,00:46,joel jaeggli <joelja@bogus.com> 写道:
> >>
> >> Folks,
> >>
> >> Some discussion prior to the recent IETF led us to ask the ask the
> >> question about what to do now that SIDR is close to having achieved it's
> >> major milestones. One possible approach we have been looking at is to
> >> Charter a new activity associated with the deployment and operation of
> >> SIDR systems within networks. Here is an initial stab at a sidrops
> >> charter with the milestones drawn from existing SIDR discussion.
> >>
> >> https://datatracker.ietf.org/doc/charter-ietf-sidrops/
> >>
> >>
> >>  The global deployment of RPKI, Origin Validation of BGP announcements
> >>  and BGPSEC, collectively called SIDR, is underway, creating an Internet
> >>  Routing System consisting of SIDR-aware and non-SIDR-aware networks.
> >>  This deployment must be properly handled to avoid the division of
> >>  the Internet into separate networks, ensuring as secure a routing
> >>  system as possible, through encouraged deployment of the SIDR technologies.
> >>
> >>  The SIDR Operations Working Group (sidr-ops) develops guidelines for
> >>  the operation of SIDR-aware networks, and provides operational guidance
> >>  on how to deploy and operate SIDR technologies in new and existing networks.
> >>
> >>  The main focuaess of the SIDR Operations Working Group are to:
> >>    o discuss deployment and operational issues related to SIDR technologies
> >>      in networks which are part of the global routing system.
> >>    o gather and discuss deployment experiences with the SIDR technologies in
> >>      networks which are part of the global routing system.
> >>
> >>  The goals of the sidr-ops working group are:
> >>
> >>  1.  Solicit input from network operators to identify
> >>  operational issues with a SIDR-aware Internet, and determine solutions
> >>  or workarounds to those issues.
> >>
> >>  2.  Solicit input from network operators to identify
> >>  operational interaction issues with the non-SIDR-aware Internet,
> >>  and determine solutions or workarounds to those issues.
> >>
> >>  3.  Operational solutions for identified issues should be developed
> >>  in sidr-ops and documented in informational or BCP documents.
> >>
> >>  These documents should document SIDR operational experience, including
> >>  interactions with non-SIDR-aware networks, the interfaces between SIDR-aware
> >>  and non-SIDR-aware networks, and the continued operational/security impacts
> >>  from non-SIDR-aware networks.
> >>
> >>  SIDR operational and deployment issues with Interdomain Routing Protocols
> >>  are the primary responsibility of the IDR working gruop.  However, the
> >>  sidr-ops Working Group may provide input to that group, as needed, and
> >>  cooperate with that group in reviewing solutions to SIDR operational and
> >>  deployment problems.
> >>
> >>  Future work items within this scope will be adopted by the Working
> >>  Group only if there is a substantial expression of interest from
> >>  the community and if the work clearly does not fit elsewhere in the
> >>  IETF.
> >>
> >>  There must be a continuous expression of interest for the Working
> >>  Group to work on a particular work item.  If there is no longer
> >>  sufficient interest in the Working Group in a work item, the item
> >>  may be removed from the list of Working Group items.
> >>
> >>
> >> Feedback on this proposal and possible milestones above and beyond those
> >> currently present is appreciated before we circulate this for wider review.
> >>
> >> _______________________________________________
> >> 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
> 
> 
> 
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr