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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 23 August 2016 14:54 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 78B8B12DA5E; Tue, 23 Aug 2016 07:54:06 -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 SPDPjQq1xRRn; Tue, 23 Aug 2016 07:54:02 -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 E439F12DA60; Tue, 23 Aug 2016 07:32:47 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id z190so108139867qkc.0; Tue, 23 Aug 2016 07:32:47 -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=5CZCJxlwp8Yu3UU7HEk6883CMx3SEVLkcNpu0JPmld8=; b=cWHXTh9N0sppJNtQijAZxOF5eZrG0IEjc5VP6GTrLP2TLflQRsOt1wccBC15BEXPs7 QKl5x3TyheLEu1SDjSWF5Akfbz6O4GftySJD7pztk7n4QCv3T4ABTI6ni8KpM4jhOFvx QPjQKIIXHUjriPBUzHGTe4uEg0KcIzsBDguGJbI5lLL0W/8yS4HWaapeKnUcUaM+ZkGH oAUQCnntbBjcR5vWeWeEKjBizfClTZzAunSl8hlcU1/lAzxE4N0fN+6rze0orccek+RL szlXtl9cM2CdEHk/pAdQVZH/70ZRgbkXtcg61BP0sVaGwF/hLN2gQFko9f1VYGz/2iFz U1Yg==
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=5CZCJxlwp8Yu3UU7HEk6883CMx3SEVLkcNpu0JPmld8=; b=mCy4YlVXzrlKZCdaC2NMbqokdH+MQpH9VofQvzds8WA5SV2q8cI344ynTh37ght5lF jKrqc4GnB6rsjADpPKbHFflNz7Ta+K2/x0JtizDb4/TZ1lD2CKmNJHgwDvvWfan1fTuY 58kjCpdw+GNyQP3fd/RK+4WtYGY3Zx2Ps/ORDa8z5TlB6PnUzTQQ8hnEWrGjEuoJ6JE8 hl+qVMNcj9DcpP2GS/DdHKqPYAqxQbVrkkw0jvrZi7M6C8WJJQb3iOnOTRGrpOnJTmUu vS1nLVb5ykddiUvsw9xTQGllGODmmyKsVhTOFIox3We2FOcJOsrrdYW/SncVVFp2YFvv jy8w==
X-Gm-Message-State: AEkoousxDptkXevBEZtV7B19boZG3uKOpAtsSK7bT4epHXtKp4bQ9R9aecq17XCQf/STJ4GTBxZpLxTyP5JcPw==
X-Received: by 10.55.120.2 with SMTP id t2mr29244661qkc.62.1471962762073; Tue, 23 Aug 2016 07:32:42 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.85.116 with HTTP; Tue, 23 Aug 2016 07:32:41 -0700 (PDT)
In-Reply-To: <CAL9jLaaVeKn6prkdb+KwQXQJ=4nTRjONJcC=PMqr_sv=SesA_A@mail.gmail.com>
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>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 23 Aug 2016 10:32:41 -0400
X-Google-Sender-Auth: dCVu9rdGGkZl1lxXzlH7N-rqUcs
Message-ID: <CAL9jLaa9rjL+Bs9YFM0fbG27zUrdhXXkCAqUCOK+9bxnqvWH5Q@mail.gmail.com>
To: joel jaeggli <joelja@bogus.com>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c05dd8c8e650c053abe09bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/Mv7bfjzpWseAha15a0m6rbIjh7A>
Cc: "Benoit Claise (bclaise)" <bclaise@cisco.com>, routing-ads@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:54:06 -0000

(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
>>
>>
>