Ballot for draft-ietf-sidrops-rp
Yes
No Objection
Abstain
Note: This ballot was opened for revision 06 and is now closed.
{Yes} [nits] S4.2.2 * This is the first time ROA is really used. Consider expanding it here one time, or up in the introduction where it first appears in the list of RFCs. S4.2.4 * I had some trouble parsing "but using the constraints applied come from ...". S4.3 * s/make decision/make decisions|make a decision/ S4.4 * s/slate/stale/
Notes for IESG reviewers: The requirements for relying party software is scattered throughout a bunch of different RFCs, and are sometimes buried and easy to overlook within these RFCs - they are generally more descriptive of how the system as a whole should work, not the responsibilities from each component's view. This has already caused a number of issues and inconsistencies between implementations, and so a document like this is needed. Like with other "Hitchhikers Guide to the XXX protocol" documents this would be a prime candidate for an "evolving document" type solution - but in the absence of such a thing, having an RFC is much better than a draft...
Section 4.3: “A Manifest can be classified as either valid or invalid, and a valid Manifest is either current and stale.” That should be “...or stale”, right?
** 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/
While this document is useful for a RPKI newcomer or implementer, I wonder whether it should become a RFC even if informal... and the "requirements" in the title is also conflicting IMHO with an informational RFC. I wonder whether the "security considerations" section is really about security considerations linked to this document or to the overall RP system. Regards -éric
I agree with Alvaro about Section 4.3.
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. 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*. 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.) 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). 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. 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/. 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? 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? 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. Section 7 The validation steps discussed throughout this document are also pretty important to the security of the system as a whole. 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!) Section 10.2 I think that RFCs 6489, 6916, and 8634 are probably better as normative.
Thanks for this - I think that this document is useful. One issue with the IETF standard format is that it can be difficult to find which RFCs need to be read to fully solve a particular problem, particularly considering that some of those RFCs may be updated or obsoleted by other RFCs. I agree with Warren's comment that it would make a good living document, if IETF had such things. In terms of reading the document, I noted that it uses quite a lot of acronyms that I was not immediately familiar with and that are not defined in the document. Perhaps the document could be improved by having a short terminology section? The acronyms that didn't appear to be defined include CRL, INR, CA, ROA. 4.2.1. Manifest To determine whether a manifest is valid, the RP is required to perform manifest-specific checks in addition to those specified in [RFC6488]. I found the above paragraph as being unclear, in that I don't know what "those" is referring to, and hence I suggest more clearly identifying “those” checks. Finally, I agree with Alvaro's comment related to section 4.3: This document probably shouldn't be giving recommendations. Perhaps better to just keep this as "However, most RP software ignores such objects.", or combine it with the previous sentence.
ABSTAIN This document presents a nice summary, but I am ABSTAINing, and not standing in the way of publication, because I don't think the contribution has enough archival value and it could cause confusion. While the document tries to provide "a single reference point", it mostly points at other RFCs, which an implementer will have to consult anyway. IOW, this document seems to add to the list. No normative language is used, which is good from the point of view that this document doesn't define a specification, but in some places the text implies a requirement level, which may cause confusion -- again, the reader will have to consult the existing RFCs... The document itself recognizes the need to maintain it up to date: "This document will be update to reflect new or changed requirements as these RFCs are updated, or new RFCs are written." (s/be update/be updated) And the difficulty in doing so is evident in the fact that one of the referenced RFCs is already obsolete, but the text doesn't reflect that. [Even though I'm ABSTAINing, I have a couple of comments.] (1) This paragraph from §4.3 caught my eye... If there are valid objects in a publication point that are not present on a Manifest, [RFC6486] does not mandate specific RP behavior with respect to such objects. However, most RP software ignores such objects and the authors of this document suggest this behavior be adopted uniformly. ...because in it the authors get away from pointing at the existing RFCs to suggest a behavior. That clearly should not be the job of this document. (2) Nits: s/RPKI make use/RPKI makes use s/one of necessary/one of the necessary s/RP is required perform/RP is required to perform s/[RFC8208]and/[RFC8208] and