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

"Carlos M. Martinez" <> Mon, 22 August 2016 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48C2612D7DF for <>; Mon, 22 Aug 2016 13:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05CTuNJbeyNA for <>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CF7012D7A1 for <>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
Received: by with SMTP id n59so209292288uan.2 for <>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=PGoPdetE91odSDA6CqDtoCYIufR3ZGd5qPpX5IdzSLg=; b=Xn0I1gvlPIqUWT1NDAdZXzgV7WKNHwZBR5xN7YrUgxrIqpX+bGHAOX+R0wK2RQ9Lfn mEiCh9MwYYOYI6Gcrz0Q+zi+TF+FdDL7AuchOYcNeKrtGG93QGlc84OPDri8hmWlSLsv 93Ab6iLRmhcw4bYeKojRkb3xqO0mTMn1TEd0XskB0sqsonYlffcM65KGyaXULvL3q8JG sj5X+Qv4U0BTFMxWa4coZSVOS1F/GqmMvByt/ztfC+76l2++qxH1cuAgUdlR4mWMTTTh Wq+5hkJjZb0TTgTlwDDzmPTIpVzmF1PtHjrqw/1CvcJh8VO3PBkoUAAiSVAzWq6DwDpk lcXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PGoPdetE91odSDA6CqDtoCYIufR3ZGd5qPpX5IdzSLg=; b=hSrL7tsWiI9+W1oq1Y7EkNcbigd4K8zS4LcdXGTlt0JGS1SXcpA5lGTIaKV5wsyTaR kAVBeQY2G3srOQc0qc/tv0xJfQEg7ZTvdUGStnM21GjQY5RimBv3kqL6jwRj014XcUH3 MZXHF5zBxVqrcxdVHeqKRSrdC7B7hGE1Gs/GXOTn04QJyLLCOAyZOcaVYVyPw2j5BwD5 Gk4Yu6VQ62Rva2aFAv1HrA0tFEhowsQEYAND/iMXdlZbpdZAlvqKhjCjgd8c2GU/TRYt 6d+K27sPs8jcSI68/2vAlPsqtq3tdlvHLTTLWN81kCdDZAsdnQceEySLV/A5gTSLPPrj AvMg==
X-Gm-Message-State: AEkoousoRXFlN6yGu6AxdPS92Be7bXT3EfvMzgCqwZS2va33nnDHQGM1CeQsI8jCDomLVg==
X-Received: by with SMTP id l137mr3599525vki.104.1471896738145; Mon, 22 Aug 2016 13:12:18 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id p2sm4508293vkd.4.2016. for <> (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 22 Aug 2016 13:12:17 -0700 (PDT)
From: "Carlos M. Martinez" <>
To: sidr wg list <>
Date: Mon, 22 Aug 2016 17:12:13 -0300
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <>
Subject: Re: [sidr] Proposal for next steps - chartering sidrops?
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: Mon, 22 Aug 2016 20:12:21 -0000

Hi Di/all,

I agree that ‘ops’ in the SIDR-ops space will encompass more than 
just network operators.

I did a little text wrangling here:




On 17 Aug 2016, at 23:43, 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.
> 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.
> Di
>> 在 2016年8月18日,00:46,joel jaeggli <> 
>> 写道:
>> 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.
>>  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 mailing list