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

joel jaeggli <joelja@bogus.com> Mon, 22 August 2016 21:04 UTC

Return-Path: <joelja@bogus.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 DE01612D808 for <sidr@ietfa.amsl.com>; Mon, 22 Aug 2016 14:04:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level:
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548] 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 DyvwN6HnJFWP for <sidr@ietfa.amsl.com>; Mon, 22 Aug 2016 14:04:05 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 2ED2712B051 for <sidr@ietf.org>; Mon, 22 Aug 2016 14:04:04 -0700 (PDT)
Received: from mbp.local ([IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7ML3xLI011785 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Aug 2016 21:04:00 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:ec3e:e3ed:c827:28d4] claimed to be mbp.local
To: Declan Ma <madi@zdns.cn>
References: <dd98327d-4487-d9dc-af63-82ed5ed2f5aa@bogus.com> <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <f7b3f43c-98e4-5e0d-b48e-a11e374c70f4@bogus.com>
Date: Mon, 22 Aug 2016 14:03:59 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0
MIME-Version: 1.0
In-Reply-To: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="HWjUcU3LkbdPD847GAhlMWn3gVa0Wj9WL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/uadFedeiuFfKRdUAWQN90FcM0oE>
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: Mon, 22 Aug 2016 21:04:07 -0000

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
>