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

[Di Ma <[e-mail]>]

Benjamin,

Thanks for your review.

Please find our response in lines.

> 2020年4月9日 14:12，Benjamin Kaduk via Datatracker <[e-mail]> 写道：
> 
> Benjamin Kaduk 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:
> ----------------------------------------------------------------------
> 
> Section 2
> 
>   RP software uses synchronization mechanisms supported by targeted
>   repositories (e.g., [rsync], RRDP [RFC8182]) to download all RPKI
>   changed data objects in the repository system and cache them locally.
> 
> nit(?): perhaps "changed" requires a bit more explanation.


How about:

RP software uses synchronization mechanisms supported by targeted repositories (e.g., [rsync], RRDP [RFC8182]) to download RPKI data objects in the repository system in order to update the local cache. These mechanisms download only those objects that have been added, or replaced with new versions, since the time when the RP checked the repository. 


> 
> Section 2.1
> 
>   TAL acquisition and processing are specified in Section 3 of
>   [RFC8630].
> 
> I'm not really convinced that the referenced section discusses
> specifically TAL *acquisition*.
> 

Good catch.

"TAL configuration” fits well here. 

> Section 2.2
> 
>   by using the SIA and AIA extensions.  Detailed specifications of SIA
>   and AIA extensions in a resource certificate are described in
>   Section 4 of [RFC6487].
> 
> (Subsections thereof, though I trust that the reader should be able to
> figure this out.)


ACK.

We will add more specific pointers to SIA and AIA extensions.

> 
> Section 3.1
> 
>   established by Section 4 of [RFC6487].  This means that all
>   extensions mandated by Section 4.8 of [RFC6487] must be present and
>   value of each extension must be within the range specified by this
>   RFC.  Moreover, any extension excluded by Section 4.8 of [RFC6487]
> 
> nit: s/this/that/ ("this RFC" is the thing that draft-ietf-sidrops-rp
> will become, in this context).


ACK.

We will use “this document” instead of “this RFC”.

> 
>   Section 7.1 of [RFC6487] gives the procedure that the RP should
>   follow to verify resource certificate and syntax.
> 
> "verify resource certificate and syntax" seems a little broad; the
> referenced section seems specific to validating the extension defined in
> RFC 3779.

Yes.

We will say: 

Section 7.1 of [RFC6487] specifies the procedure that the RP should follow to verify the RCF 3779  extension.

> 
> Section 3.2
> 
>   Certificate Authorities that want to reduce aspects of operational
>   fragility will migrate to the new OIDs [RFC8360], informing the RP of
>   using an alternative RPKI validation algorithm.  An RP is expected to
>   support the amended procedure to handle with accidental over-claim.
> 
> nit: I suggest s/with accidental over-claim/accidental overclaim/.

ACK

> 
> Section 3.3
> 
>   Processing of a CRL that is not consistent with a manifest is a
>   matter of local policy, as described in the fourth paragraph of
>   Section 6.6 of [RFC6486].
> 
> Is the fifth paragraph relevant, also?

Yes. Good catch.

> 
> Section 4.1
> 
>   Note that these checks are necessary, but not sufficient.  Additional
>   validation checks must be performed based on the specific type of
>   signed object.
> 
> These additional validations are covered in the following sections, it
> seems -- should we mention that here?

Note that these checks are necessary, but not sufficient.  Additional validation checks must be performed based on the specific type of signed object as described in Section 4.2. 

> 
> Section 4.2.4
> 
>   contain an IP Address Delegation extension.  The validation procedure
>   used for BGPsec Router Certificates is identical to the validation
>   procedure described in Section 7 of [RFC6487], but using the
>   constraints applied come from specification of Section 7 of
>   [RFC8209].
> 
> nit: if it does something differently, it's no longer "identical"; maybe
> "analogous" or it's following the validation procedure [...] with
> additional constraints"?
> That said, Section 7 of RFC 8209 is the IANA considerations, so I'm not
> sure what the "constraints applied come from" is intended to say.
> 

proposed new text:
  The validation procedure used for BGPsec Router Certificates is analogous to the validation
  procedure described in Section 7 of [RFC6487], but it uses the constraints defined in Section 3 of  [RFC8209].


> Section 7
> 
> The validation steps discussed throughout this document are also pretty
> important to the security of the system as a whole.

Good point. We'll add a final sentence:

This document highlights many validation actions applied to RPKI signed objects, an essential element of secure operation of RPKI security.


> 
> Section 10.1
> 
> I'm not sure that RFC 5280 actually is normative here.  (That might be
> the first time I've ever said that!)

We cite 5280 because it  it the IETF profile for X.509; the various RPKI RFCs further profile that RFC.


> 
> Section 10.2
> 
> I think that RFCs 6489, 6916, and 8634 are probably better as normative.

OK, we'll move them up to 10.1

Di