Return-Path: 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 32CC512DA10; Tue, 23 Aug 2016 08:13:58 -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 8MV-gFZjBVRB; Tue, 23 Aug 2016 08:13:55 -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 480E912DA13; Tue, 23 Aug 2016 07:48:02 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id v123so108499458qkh.2; Tue, 23 Aug 2016 07:48:02 -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=zSoU5FxVo3IRqVIPI29QW7NHo2uX9uep7rHKV46SMzg=; b=TXxFjX3wfIlJBs3eTbyUVli9A+VwOjdQvlQIoEEKzepc5h/QhTLvO9GDnVGf/AxuMT 0P1EbfYpNYrDWojpsxd0+1wKjetOMQ7pmDJCm3ycBrWFJq7iGdlDgfWffCcNhfDkFPbB HxrFjsM5mzC+XRRpHJCfpKdwcq12jXfMtrf5RpBEWSUXv1jffJ5iqXfxkimiiMCF1jPP O3uZa9yzx5tjTDwb93O1qFAJ+HTEgI5ffpT6zgEO9Tn6IZ0AGVaGr3YeBKcnenxoQ6fQ I/DRyN1Ug2NgEEEn1E8L43l1vV7xI10cvQpQE2m6pWjQyFjZdEU2Ioap+jol5nJtHEtv HlOQ== 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=zSoU5FxVo3IRqVIPI29QW7NHo2uX9uep7rHKV46SMzg=; b=P5l2myvQsoizp4mRm8r78ROMogZQfnpPNksa5lHInufHxkBwuA+ySVtbLlhx5nupTj J9bwrhDr6Fbe+JSXPRk9C4sgqbf6FxsGbTEi2HqxBnhYoa0gOgIEFmYNTA79//m3I1bk VInXoQy05jsh3buSFwMHSfaGfQCKaEHY6+7qtJvbO6vjTDfyj3KMlAlQ0kU1D5eWY9Ah D11YE6Zr7BRDYVKNeM0y1xm7LT2sD2LuvlxLex0/UB8r7LUK5FQk5kTFT1COhHeZlGzF k9SODUvg1cbPMi25rBkmQvXuwDyq+N4g39Xno30//lTbPyiH7n4wGg704sSfuyV0LOb0 W6mQ== X-Gm-Message-State: AEkoouuunglJCDsE7tiSQYCf8TD/JojYFZKLdqHf3YxXFxnpSFvYpkpfY3XqSMnYuAt2h+KhgQ0a/db/VwfpjQ== X-Received: by 10.233.222.133 with SMTP id s127mr31487731qkf.166.1471963681313; Tue, 23 Aug 2016 07:48:01 -0700 (PDT) MIME-Version: 1.0 Sender: christopher.morrow@gmail.com Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:48:00 -0700 (PDT) In-Reply-To: References: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn> From: Christopher Morrow Date: Tue, 23 Aug 2016 10:48:00 -0400 X-Google-Sender-Auth: UfIdQE33i_9K1VOACi5g2bFA15g Message-ID: To: joel jaeggli , "sidr-chairs@ietf.org" , rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary=94eb2c0438f858da0c053abe4094 Archived-At: Cc: "Benoit Claise \(bclaise\)" , sidr wg list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:13:58 -0000 --94eb2c0438f858da0c053abe4094 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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=E2=80=99t fall into the categ= ory of >>> =E2=80=98network operators=E2=80=99. >>> > >>> > I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be >>> adjusted slightly, with CA operators, repository operators, RP service >>> providers involved. >>> yeah I think the tent should be inclusive. >>> > >>> > Di >>> > >>> >> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC=8Cj= oel jaeggli =E5=86=99=E9=81=93=EF=BC=9A >>> >> >>> >> 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 t= o >>> >> 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 announcemen= ts >>> >> 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 fo= r >>> >> 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 operationa= l >>> 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 >>> >>> >> > --94eb2c0438f858da0c053abe4094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
routing-ads -> rtg-ads.

On Tue, Aug 23, 2016 at 10:32 AM, Christoph= er 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 chan= ges from Carlos seem ok to me, and declan's points about ca/rir also se= em 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, Dec= lan Ma wrote:
> Joel,
>
> When we are talking about SIDROPS,=C2=A0 we are referring to that BGP = speakers are resorting to RPKI relying party to get verified INR authorizat= ion information, which is created by CA and maintained by repository manage= rs.
>
> IMHO, network operators are not the only RPKI role that the community = is going to solicit input from.=C2=A0 CA operators, repository operators, R= P service providers all bear significance as with SIDR Operations, in ident= ifying 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, repositor= y operators, RP service providers, yet RIRs, CA and repository backend serv= ice providers, and third party RP don=E2=80=99t fall into the category of= =C2=A0 =E2=80=98network operators=E2=80=99.
>
> I would suggest the =E2=80=9CThe goals of the sidr-ops working group= =E2=80=9D be adjusted slightly, with CA operators, repository operators, RP= service providers involved.
yeah I think the tent should be inclusive.
>
> Di
>
>> =E5=9C=A8 2016=E5=B9=B48=E6=9C=8818=E6=97=A5=EF=BC=8C00:46=EF=BC= =8Cjoel jaeggli <j= oelja@bogus.com> =E5=86=99=E9=81=93=EF=BC=9A
>>
>> 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 achieve= d it's
>> major milestones. One possible approach we have been looking at is= to
>> Charter a new activity associated with the deployment and operatio= n 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/
>>
>>
>>=C2=A0 The global deployment of RPKI, Origin Validation of BGP anno= uncements
>>=C2=A0 and BGPSEC, collectively called SIDR, is underway, creating = an Internet
>>=C2=A0 Routing System consisting of SIDR-aware and non-SIDR-aware n= etworks.
>>=C2=A0 This deployment must be properly handled to avoid the divisi= on of
>>=C2=A0 the Internet into separate networks, ensuring as secure a ro= uting
>>=C2=A0 system as possible, through encouraged deployment of the SID= R technologies.
>>
>>=C2=A0 The SIDR Operations Working Group (sidr-ops) develops guidel= ines for
>>=C2=A0 the operation of SIDR-aware networks, and provides operation= al guidance
>>=C2=A0 on how to deploy and operate SIDR technologies in new and ex= isting networks.
>>
>>=C2=A0 The main focuaess of the SIDR Operations Working Group are t= o:
>>=C2=A0 =C2=A0 o discuss deployment and operational issues related t= o SIDR technologies
>>=C2=A0 =C2=A0 =C2=A0 in networks which are part of the global routi= ng system.
>>=C2=A0 =C2=A0 o gather and discuss deployment experiences with the = SIDR technologies in
>>=C2=A0 =C2=A0 =C2=A0 networks which are part of the global routing = system.
>>
>>=C2=A0 The goals of the sidr-ops working group are:
>>
>>=C2=A0 1.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational issues with a SIDR-aware Internet, and determine= solutions
>>=C2=A0 or workarounds to those issues.
>>
>>=C2=A0 2.=C2=A0 Solicit input from network operators to identify >>=C2=A0 operational interaction issues with the non-SIDR-aware Inter= net,
>>=C2=A0 and determine solutions or workarounds to those issues.
>>
>>=C2=A0 3.=C2=A0 Operational solutions for identified issues should = be developed
>>=C2=A0 in sidr-ops and documented in informational or BCP documents= .
>>
>>=C2=A0 These documents should document SIDR operational experience,= including
>>=C2=A0 interactions with non-SIDR-aware networks, the interfaces be= tween SIDR-aware
>>=C2=A0 and non-SIDR-aware networks, and the continued operational/s= ecurity impacts
>>=C2=A0 from non-SIDR-aware networks.
>>
>>=C2=A0 SIDR operational and deployment issues with Interdomain Rout= ing Protocols
>>=C2=A0 are the primary responsibility of the IDR working gruop.=C2= =A0 However, the
>>=C2=A0 sidr-ops Working Group may provide input to that group, as n= eeded, and
>>=C2=A0 cooperate with that group in reviewing solutions to SIDR ope= rational and
>>=C2=A0 deployment problems.
>>
>>=C2=A0 Future work items within this scope will be adopted by the W= orking
>>=C2=A0 Group only if there is a substantial expression of interest = from
>>=C2=A0 the community and if the work clearly does not fit elsewhere= in the
>>=C2=A0 IETF.
>>
>>=C2=A0 There must be a continuous expression of interest for the Wo= rking
>>=C2=A0 Group to work on a particular work item.=C2=A0 If there is n= o longer
>>=C2=A0 sufficient interest in the Working Group in a work item, the= item
>>=C2=A0 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 wide= r 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




--94eb2c0438f858da0c053abe4094--