Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties
draft-ietf-sidrops-rp-06

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

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.

[Ballot 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/

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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
  the 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

[Ballot comment]
{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/

[Ballot comment]
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?

[Ballot comment]
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...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-rp-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-03-20):

From: The IESG
To: IETF-Announce
CC: sidrops-chairs@ietf.org, nathalie@ripe.net, warren@kumari.net, sidrops@ietf.org, Nathalie Trenaman , draft-ietf-sidrops-rp@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties) to Informational RFC


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Requirements for Resource Public Key
Infrastructure (RPKI) Relying
  Parties'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document provides a single reference point for requirements for
  Relying Party (RP) software for use in the Resource Public Key
  Infrastructure (RPKI) in the context of securing Internet routing.
  It cites requirements that appear in several RPKI RFCs, making it
  easier for implementers to become aware of these requirements that
  are segmented with orthogonal functionalities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing.
It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities.

Working Group Summary:

The document went through several revisions and review at WGLC to include comments/suggestions/changes.
The conversation in the WG mail-list and meetings was productive and the chairs believe this document is ready to progress.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Since the first version of the document, there has been support for this draft. The two points worth noting are the concern of the WG to keep the document current and the removal of normative language because of the type of draft (Informational).  This has been addressed.

Document Quality:

The document is clear and concise. There are no nits nor is the document controversial.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Not applicable to this document.

Personnel:

Nathalie Trenaman (nathalie@ripe.net) is Document Shepherd
Warren Kumari (warren@kumari.net) is Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd read the document and reviewed comments.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Not needed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Consensus was solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No threats.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

I did not find any ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Not expected.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Reviewed, and no actions needed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document provides a single reference point for requirements for Relying Party (RP) software for use in the Resource Public Key Infrastructure (RPKI) in the context of securing Internet routing.
It cites requirements that appear in several RPKI RFCs, making it easier for implementers to become aware of these requirements that are segmented with orthogonal functionalities.

Working Group Summary:

The document went through several revisions and review at WGLC to include comments/suggestions/changes.
The conversation in the WG mail-list and meetings was productive and the chairs believe this document is ready to progress.

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Since the first version of the document, there has been support for this draft. The two points worth noting are the concern of the WG to keep the document current and the removal of normative language because of the type of draft (Informational).  This has been addressed.

Document Quality:

The document is clear and concise. There are no nits nor is the document controversial.

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Not applicable to this document.

Personnel:

Nathalie Trenaman (nathalie@ripe.net) is Document Shepherd
Warren Kumari (warren@kumari.net) is Area Director

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd read the document and reviewed comments.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Not needed.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Consensus was solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No threats.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

I did not find any ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not required.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Not expected.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

Reviewed, and no actions needed.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Not applicable.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not needed.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable.