Re: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)

Di Ma <madi@rpstir.net> Thu, 09 April 2020 14:45 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 1A95E3A0844; Thu, 9 Apr 2020 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 8MprkQ2S1hYY; Thu, 9 Apr 2020 07:45:18 -0700 (PDT)
Received: from out20-38.mail.aliyun.com (out20-38.mail.aliyun.com [115.124.20.38]) (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 B684B3A0843; Thu, 9 Apr 2020 07:45:15 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.08401275|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0133755-3.34407e-05-0.986591; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03294; MF=madi@rpstir.net; NM=1; PH=DS; RN=6; RT=6; SR=0; TI=SMTPD_---.HDdjb.6_1586443503;
Received: from 192.168.3.24(mailfrom:madi@rpstir.net fp:SMTPD_---.HDdjb.6_1586443503) by smtp.aliyun-inc.com(10.147.41.121); Thu, 09 Apr 2020 22:45:04 +0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <158639761310.14576.3625316672934417222@ietfa.amsl.com>
Date: Thu, 9 Apr 2020 22:45:00 +0800
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-rp@ietf.org, sidrops-chairs@ietf.org, sidrops@ietf.org, nathalie@ripe.net
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAD2B6C2-D200-48BF-ADD6-FB847AE49606@rpstir.net>
References: <158639761310.14576.3625316672934417222@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/g8l26LeKUTgI2jSzgqvnKxW2Wp4>
Subject: Re: [Sidrops] Roman Danyliw's No Objection on draft-ietf-sidrops-rp-06: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 09 Apr 2020 14:45:20 -0000

Roman,

Thanks for your review.

Please find our response in lines.

> 2020年4月9日 10:00,Roman Danyliw via Datatracker <noreply@ietf.org> 写道:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-sidrops-rp-06: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** In the spirit of this being a pathfinding document, provide additional
> references as follows:
> 
> -- Section 3.2.  Per “An RP is expected to support the amended procedure to
> handle with accidental over-claim.”, a pointer to these procedures would be
> helpful.

We will provide pointers to specific sections that describe these procedures as you suggest.


> -- Section 3.3.  Per “CRLs in the RPKI are tightly constrained; only the
> AuthorityKeyIndetifier and CRLNumber extensions are allowed …”, a pointer to
> these extensions would be helpful.

 ACK.

We will add pointers to AuthorityKeyIndentifier (Section 4.8.3 of RFC 6487) and CRL Number (Section 5.2.3 of RFC 5280)

> 
> -- Section 4.2.4, Per “Additionally, the certificate must contain an AS
> Identifier Delegation extension …”, a pointer to this extension would be
> helpful.


ACK.

We will add pointer to AS Identifier Delegation extension (Section 4.8.11 of RFC 6487) .


> 
> ** Section 1.  Per “Besides, software engineering calls for how to segment the
> RP system into components with orthogonal functionalities, so that those
> components could be distributed across the operational timeline of the user”. I
> didn’t follow the intent of this sentence.  What are principles of software
> engineering calling for?


By dividing RP function into some modules independent with one another, the implementation is easy to be extended. That is, one module can be evolved with another remaining unchanged.

> 
> ** Section 3.3.  Typo in the extension name. 
> s/AuthorityKeyIndetifier/AuthorityKeyIdentifier/
> 

ACK.

> ** Section 7. Please add text that this document doesn’t introduce any new
> security considerations but is a resource to implementers.  The individual RPKI
> RFC need to be consulted for specific guidance.


Good idea. We will add a sentence to that effect, at the beginning of this section.

> 
> ** Editorial Nits
> -- Section 1.  Typo. s/This document will be update …/This document will be
> updated …/


ACK.

> 
> -- Section 3.1.  Typo. s/must be present and value of each extension/must be
> present and the value of each extension/
> 
> 

ACK.

Di