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

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

Return-Path: <carlosm3011@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 48C2612D7DF for <sidr@ietfa.amsl.com>; Mon, 22 Aug 2016 13:12:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
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: 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 05CTuNJbeyNA for <sidr@ietfa.amsl.com>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 5CF7012D7A1 for <sidr@ietf.org>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id n59so209292288uan.2 for <sidr@ietf.org>; Mon, 22 Aug 2016 13:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.31.254.143 with SMTP id l137mr3599525vki.104.1471896738145; Mon, 22 Aug 2016 13:12:18 -0700 (PDT)
Received: from [192.168.99.1] ([200.7.87.24]) by smtp.gmail.com with ESMTPSA id p2sm4508293vkd.4.2016.08.22.13.12.16 for <sidr@ietf.org> (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 22 Aug 2016 13:12:17 -0700 (PDT)
From: "Carlos M. Martinez" <carlosm3011@gmail.com>
To: "sidr wg list" <sidr@ietf.org>
Date: Mon, 22 Aug 2016 17:12:13 -0300
Message-ID: <843C3F5F-7946-46E7-9A41-176E50925B16@gmail.com>
In-Reply-To: <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn>
References: <dd98327d-4487-d9dc-af63-82ed5ed2f5aa@bogus.com> <71D7D3ED-BC1C-408C-BB56-832C6E27E37A@zdns.cn>
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: <https://mailarchive.ietf.org/arch/msg/sidr/-V0z_oHn0W5-8ZYNLjBC-VvnkWc>
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 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:

[https://www.dropbox.com/s/fg0x3mywc2wcxk5/sidr-ops-charter-00-carlosm.docx?dl=0]

cheers!

-Carlos

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