IETF Logo Mail Archive

Re: [Sidrops] WG Adoption call for draft-madi-sidrops-rp-adoption

Di Ma <madi@rpstir.net> Wed, 11 October 2017 05:24 UTC

Return-Path: <madi@rpstir.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6C13239C for <sidrops@ietfa.amsl.com>; Tue, 10 Oct 2017 22:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 zJlfs77-KAGx for <sidrops@ietfa.amsl.com>; Tue, 10 Oct 2017 22:24:28 -0700 (PDT)
Received: from out20-1.mail.aliyun.com (out20-1.mail.aliyun.com [115.124.20.1]) (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 41DA2124B17 for <sidrops@ietf.org>; Tue, 10 Oct 2017 22:24:27 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2814213|-1; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03280; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.963mywv_1507699430;
Received: from 192.168.218.249(mailfrom:madi@rpstir.net ip:124.17.24.252) by smtp.aliyun-inc.com(10.147.44.145); Wed, 11 Oct 2017 13:24:20 +0800
Content-Type: text/plain; charset="gb2312"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <m2d15ud00u.wl-randy@psg.com>
Date: Wed, 11 Oct 2017 13:23:50 +0800
Cc: Keyur Patel <keyur@arrcus.com>, SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4061543-4293-4416-8F4B-19558CFEC596@rpstir.net>
References: <CB3C3CD7-AE5E-4267-9E56-C55229D8BADA@arrcus.com> <m2d15ud00u.wl-randy@psg.com>
To: Randy Bush <randy@psg.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/x9KTQ6MxaLTsENu5HSV6mlvh1sw>
Subject: Re: [Sidrops] WG Adoption call for draft-madi-sidrops-rp-adoption
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 05:24:30 -0000

Randy,

Thanks for your review.

See my comment in lines. 

> 在 2017年10月11日，08:02，Randy Bush <randy@psg.com> 写道：
> 
>> The authors have requested SIDROPS working group adoption call of
>> draft-madi-sidrops-rp-adoption, “Requirements for Resource Public Key
>> Infrastructure (RPKI) Relying Parties”. Please send your comments to
>> the list.
> 
> the actual name of the draft in my rsynced repo is
> 
>   draft-madi-sidrops-rp-00.txt
> 
> while i have no strong objection to discussing this draft in the wg, all
> it does is two things
> 
>  o points to the documents with the protein
> 
>  o and any place it tries to have actual protein, it risks
>    contradicting or confusing the real documents

This document is intended to help concerned readers to find where a specific RP requirement is normatively defined.

And it also offers a framework through which the RP requirements with orthogonal functionalities are categorized.

> 
> the sidr* wgs chose not to publish the bgpsec overview draft.  this
> seems analogous.
> 

I think the bgpsec overview draft is helpful.

Although it is not published, people are still able to learn BGPSEC by getting started with RFC 8205.

Granted, the authors of draft-madi-sidrops-rp hope this document provides glues for real RP requirements that are scatted in other RFCs.

Di

v2.23.0 | Report a Bug | By Email