Re: [sidr] Proposal for next steps - chartering sidrops?
Christopher Morrow <morrowc.lists@gmail.com> Tue, 23 August 2016 14:42 UTC
Return-Path: <christopher.morrow@gmail.com>
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 C0C6812DAF5 for <sidr@ietfa.amsl.com>; Tue, 23 Aug 2016 07:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 V2v-N_ES3djX for <sidr@ietfa.amsl.com>; Tue, 23 Aug 2016 07:42:00 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61BA12DAFF for <sidr@ietf.org>; Tue, 23 Aug 2016 07:22:52 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id z190so107831554qkc.0; Tue, 23 Aug 2016 07:22:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3edLKXCOi2E2aOwq/gQEPqdU2n/taJmMgMZubdy0W8I=; b=cTY9ye8J+ObiPzoF94JLF3cf/LBgNekxTnMUfvh4Lc0MmsEzwWSTK09pV42mAVd4rh CS8PHv1x0uSuUbp/nd40R8O2jMbt3xf0ikojM5O0Qqkmw37rEzoeOJLNdNd/pgEAtD6B CCinSq/acVccT2i2F4pRPmr5ScBA35S/iXxl5jeyhKkZsnjySdb/u9AqrCdHNnNHaee+ MEUhDGIP2pCV8Xh1GFrUW/lnQloiw2hKOtysp5Y30b7JOJqCyPYRkt0iWVHKdiOXzhcm fQJnZvNY0yDiFTGZdAIpBU4DGxtycEnqQLF+ogVACf0TIR84RSbMXIMSmVIwzXTMbFQJ O5og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3edLKXCOi2E2aOwq/gQEPqdU2n/taJmMgMZubdy0W8I=; b=T2bZfiP1YlCcnoK+4QDy2mnW5rgUXKFN8knWQn+TWTwA3XqXFBfVy1YOkKLtF/8VhE s9aVEOAgFwzg/HV+1JMHUnBX2z8dNAW4wJhA0w/MpBcuHi1R2TolQXAaXas45rQDXmBu 3zDoHc1NYWVEv7yrplKaP8Sb6ps8beBJXHGGcYKea7dV8nriZNxeRc4F4zBF6jYUI2du 9mi9suPG4FdbBcW6OkPqlUED6XKJ+lpxBo3ObzsQ43m1wIktGHldEaEbNA6Ixuyy4NV7 dHMm+TgBWnF9XXFE2XLcRLowHuyLNE5kiG/pUREOlAsdATKgkZRCR35xkMU7ELVvqehP jR/w==
X-Gm-Message-State: AEkoousTSfmuhc2qJ5NLdVqkvWCvz9VbeqOmUBXmwdSHiPnJggeNLpEK/COkU8HztHZQXmkV5MLGaEO0Q4+wbQ==
X-Received: by 10.55.120.2 with SMTP id t2mr29185602qkc.62.1471962166916; Tue, 23 Aug 2016 07:22:46 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:22:46 -0700 (PDT)
In-Reply-To: <f7b3f43c-98e4-5e0d-b48e-a11e374c70f4@bogus.com>
References: <dd98327d-4487-d9dc-af63-82ed5ed2f5aa@bogus.com> <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> <f7b3f43c-98e4-5e0d-b48e-a11e374c70f4@bogus.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 23 Aug 2016 10:22:46 -0400
X-Google-Sender-Auth: x8OZ1JJGOUPv_SGTh8uwF2V2Mxg
Message-ID: <CAL9jLaaVeKn6prkdb+KwQXQJ=4nTRjONJcC=PMqr_sv=SesA_A@mail.gmail.com>
To: joel jaeggli <joelja@bogus.com>
Content-Type: multipart/alternative; boundary="94eb2c05dd8c152436053abde6f0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/gHmaXsHfMWCqxlLfFv9i3Z3IU80>
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, routing-ads@ietf.org, sdir-chairs@ietf.org, sidr wg list <sidr@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: Tue, 23 Aug 2016 14:42:05 -0000
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 > >
- Re: [sidr] Proposal for next steps - chartering s… Declan Ma
- [sidr] Proposal for next steps - chartering sidro… joel jaeggli
- Re: [sidr] Proposal for next steps - chartering s… Carlos M. Martinez
- Re: [sidr] Proposal for next steps - chartering s… joel jaeggli
- Re: [sidr] Proposal for next steps - chartering s… Christopher Morrow
- Re: [sidr] Proposal for next steps - chartering s… Christopher Morrow
- Re: [sidr] Proposal for next steps - chartering s… Christopher Morrow
- Re: [sidr] Proposal for next steps - chartering s… Sean Turner
- Re: [sidr] Proposal for next steps - chartering s… Tim Bruijnzeels