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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 08 Apr 2020 19:00:13 -0700

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.

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

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

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

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

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

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

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

---

From: Di Ma <[email-masked]>
Date: Thu, 9 Apr 2020 22:45:00 +0800

Roman,

Thanks for your review.

Please find our response in lines.

> 2020年4月9日 10:00，Roman Danyliw via Datatracker <[email-masked]> 写道：
> 

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

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

> Identifier Delegation extension …”, a pointer to this extension would be

ACK.

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

> didn’t follow the intent of this sentence.  What are principles of software

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.

> s/AuthorityKeyIndetifier/AuthorityKeyIdentifier/

ACK.

> RFC need to be consulted for specific guidance.

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

> -- Section 1.  Typo. s/This document will be update …/This document will be

ACK.

> present and the value of each extension/

ACK.

Di