Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)
draft-ietf-sidr-cps-04

1) Changes to the draft based on IESG comments will have to be done during AUTH48.  (Sorry for the good comments and email threads that I missed that the draft hadn't been updated before handing to the RFC Editor.)

2) A way of handing the copyright issues is to have the authors submit an IPR claim granting free copyright for modification.  This has not yet been done.  I'm investigating with the authors as
to whether this will happen or whether the RFC will have to wait until the IETF Trustees have
done a different plan.

The issue of copyright permission for duplication and modification as a template is being discussed.  The two options are for the IETF Trust to post a notice giving permission or for the authors to post an IPR declaration giving permission.  This is being resolved.

[Ballot comment]
Thanks to all (including the IETF Trustees) who helped to discuss my Discuss.
As I understand it, the document should not change to address my copyright concerns, but the Trust will post something along the lines of...
  In addition to the rights granted under the TLP with respect to
  RFC XXX (the Template RFC), a non-exclusive, perpetual
  license is also granted to all interested persons to make,
  reproduce and distribute modifications to the text of the
  Template RFC solely as expressly indicated in the Template
  RFC (i.e., to insert specific information where it is called for in
  the Template RFC).

I am happy to support this document, and hope that the Trust will follow through.

[Ballot comment]
Thanks to all (including the IETF Trustees) who helped to discuss my Discuss.
As I understand it, the document should not change to address my copyright concerns, but the Trust will post something along the lines of...
  In addition to the rights granted under the TLP with respect to RFC XXX
  (the Template RFC), a non-exclusive, perpetual license is also granted to
  all interested persons to make, reproduce and distribute modifications to
  the text of the Template RFC solely as expressly indicated in the Template
  RFC (i.e., to insert specific information where it is called for in the Template
  RFC).

I am happy to support this document, and hope that the Trust will follow through.

[Ballot comment]
Thanks to all (including the IETF Trustees) who helped to discuss my Discuss.
As I understand it, the document should not change to address my copyright concerns, but the Trust will post something along the lines of...
  In addition to the rights granted under the TLP with respect to RFC XXX (the Template RFC), a non-exclusive,
  perpetual license is also granted to all interested persons to make, reproduce and distribute modifications to the text
  of the Template RFC solely as expressly indicated in the Template RFC (i.e., to insert specific information where it is
  called for in the Template RFC).

I am happy to support this document, and hope that the Trust will follow through.

[Ballot comment]
My brain stumbled on the following text in 1.3:
  Describe how the registration authority function is handled for the
  CA(s) that you operate.  The RPKI does not require establishment or
  use of a separate registration authority (RA) in conjunction with the
  CA function.

What is the second sentence intended to address?  I read it as meaning something like "The RPKI allows the RA to be operated either in conjunction with the CA function, or through a separate registration entity."  But the subsequent sentences suggest that this is incorrect.  So if it means the opposite of what I read, it should be stated directly so that it's clear what it means.  E.g., "The RPKI does not allow for the establishment or use of a separate RA in conjunction with the CA function."

In 3.1.5:
  Although it is desirable that these
  subject names be unique throughout the PKI, to facilitate certificate
  path discovery, such uniqueness is neither mandated nor enforced
  through technical means.

I think you mean the two clauses at the end of the sentence to be distinct, but they read as expressing a single meaning.  It might be clearer to say it this way:

  Although it is desirable that these
  subject names be unique throughout the PKI, to facilitate certificate
  path discovery, such uniqueness is not required, nor is it enforced
  through technical means.

In 4.4.1:
  Any subscriber in good standing who holds INRs distributed by  is for "in good standing," it would be good to make that explicit, since at least my tendency is to take it as having a common global meaning.

In 8:

  List here any audit and other assessments used to ensure the
  security of the administration of INRs. These are sufficient for the
  RPKI systems.

Does the second sentence mean that what is stated in the first sentence is all that is required, or that what is stated must be sufficient for RPKI systems?  I can't come up with a clear meaning for this sentence.

Despite my carping, this is a great document, and I'm glad to see it go by.  Thanks for doing it!

[Ballot comment]

- 1.4.2:  Why do we need this?  I see the same is in 6484 (and
would have commented simlarly on that had I been on the IESG
then). I do not see any need for that at all but I expect that
even if I'm right you probably want it so as to be consistent
with 6484.

[Ballot comment]
Having written an extensive CP and CPS for an organization, this template looks very good and appears to meet the expectations of users for a template such as this.  Thank you for your effort on this draft.

[Ballot comment]
Preface:

When someone uses this document to produce a CPS, what will the normative language mean once the reference to RFC 2119 is omitted? E.g., this text in Section 2.1 is not in angle brackets, so I assume it will be reproduced in every CPS: "As per the CP, certificates, CRLs and RPKI-signed objects MUST be made available for downloading by all relying parties, to enable them to validate this data." What is this kind of requirement supposed to mean when published in a CPS? (Similar question for 3.1.3).

s/employed in the RFC/employed in that RFC/

Section 1.6:
"An RPKI signed object is a digitally signed data object (other than a certificate or CRL) declared to be such by a standards track RFC"

I find the "such" here ambiguous. Something is declared to be an object by a standards track RFC? Or declared to be a digitally signed object? Or declared to be an RPKI-signed object?

[Ballot comment]
I think I got a bout of denseness (density?) when I read this.  It is an odd document, what with a preface that tells people to do a bunch of surgery to the document and then publish their own sorta-version of it and all.

Many thanks to the document shepherd, Chris Morrow, for explaining the bits that I found odd or confusing.  I wondered why it's a BCP.  That was easy to explain.  I wondered where these things would be published, if not RFCs, and I wondered why the huge amount of invariant text isn't just referenced, rather than being included in every CPS.  In the end, I think a small bit of explanation in the preface would have done a lot for me, so let me suggest this, as a non-blocking comment.  No need to respond to this, and do what you think best:

OLD
  This document contains a template to be used for creating a
  Certification Practice Statement (CPS) for an Organization that is
  part of the Resource Public Key Infrastructure (RPKI). (Throughout
  this document the term "organization" is used broadly, e.g., the
  entity in question might be a business unit of a larger
  organization.) The user of this document should:

    1. substitute a title page for page 1 saying, e.g., " Certification Practice Statement for the Resource
        Public Key Infrastructure (RPKI)" with date, author, etc. There
        is no expectation that a CPS will be published as an RFC.
NEW
  This document contains a template to be used for creating a
  Certification Practice Statement (CPS) for an Organization that is
  part of the Resource Public Key Infrastructure (RPKI). (Throughout
  this document the term "organization" is used broadly, e.g., the
  entity in question might be a business unit of a larger
  organization.)

  There is no expectation that a CPS will be published as an RFC.
  Instead, the CPS will be published in ways similar to how such
  things as privacy policies and terms of service are published: as
  pages on the organization's web site and the like.  Organizations
  are expected to use this template as a best current practice,
  rather than creating their own from scratch -- this document
  contains both invariant text that will appear in all Certification
  Practice Statements and places to fill in text that's specific to
  the CPS being created.

  The user of this document should:

    1. substitute a title page for page 1 saying, e.g., " Certification Practice Statement for the Resource
        Public Key Infrastructure (RPKI)" with date, author, etc.
END

Of course, if you choose to accept this suggestion you should tweak the text of that paragraph appropriately: I'm sure I didn't get everything exactly right.

[Ballot discuss]
I hope that someone more skilled in the art than I can explain how we handle copyright issues under TLP 4 Section 3.c.ii.  Maybe Section 3.e covers us. Maybe the Trust can give us a paragraph to include in this document.

I very much hope that this issue does not get in the way of progressing this work.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sidr-cps-04, which is currently in Last Call, and has the following comments:

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

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

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

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)) to Best Current Practice


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Template for a Certification Practice Statement (CPS) for the Resource
  PKI (RPKI)'
  as Best Current Practice

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
ietf@ietf.org mailing lists by 2014-07-03. 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 contains a template to be used for creating a
  Certification Practice Statement (CPS) for an Organization that is
  part of the Resource Public Key Infrastructure (RPKI), e.g., a
  resource allocation registry or an ISP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-cps/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-cps/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 24 February 2012.

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

BCP


(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 contains a template to be used for creating a
  Certification Practice Statement (CPS) for an Organization that is
  part of the Resource Public Key Infrastructure (RPKI), e.g., a
  resource allocation registry or an ISP.

Working Group Summary

This document is a simple template to be used by a relevant CA in the SIDR system.
It is based off: RFC 3647, and is by and large straight forward. There was no significant heated discussion on this document in the WG.

Document Quality

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

Since this is a template, which is based on RFC 3647, there are no more 'implementations'.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

shephard: chris morrow
AD: Alia Atlas

(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 shephard reviewed the document, during the discussion period, during the WGLC and at the end of the LC period. The document should be ready for publication at this point.

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

I don't believe the document needs external review from specialists.

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

n/a

(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, each author confirmed no IPR claims were pending.

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

N/A

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

The consensus was fairly 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 appeals.

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

There is one id-nit to be dealt with, which will be dealt with before publication (it's not relevant for further review)

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

N/A

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

No.

(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 5226).

There are no IANA requirements in this document.

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

N/A

(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, etc.

No automated checks were made, nor required.