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

[Di Ma <[e-mail]>]

Roman,

Thanks for your review.

Please find our response in lines.

> 2020年4月9日 10:00，Roman Danyliw via Datatracker <[e-mail]> 写道：
> 
> 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