Skip to main content

The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
draft-ietf-sidr-rpki-rtr-rfc6810-bis-09

Revision differences

Document history

Date Rev. By Action
2017-06-30
09 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-06-14
09 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-06-07
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2017-04-27
09 (System) RFC Editor state changed to EDIT from MISSREF
2017-03-08
09 (System) RFC Editor state changed to MISSREF from EDIT
2017-03-08
09 (System) RFC Editor state changed to EDIT from MISSREF
2017-03-06
09 Matthew Miller Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Matthew Miller. Sent review to list.
2017-03-02
09 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2017-02-28
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-02-27
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-02-27
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-02-24
09 (System) RFC Editor state changed to MISSREF
2017-02-24
09 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-02-24
09 (System) Announcement was received by RFC Editor
2017-02-23
09 (System) IANA Action state changed to In Progress
2017-02-23
09 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-02-23
09 Cindy Morgan IESG has approved the document
2017-02-23
09 Cindy Morgan Closed "Approve" ballot
2017-02-23
09 Alvaro Retana IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2017-02-23
09 Alvaro Retana Ballot approval text was generated
2017-02-17
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-02-17
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-02-17
09 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-09.txt
2017-02-17
09 (System) New version approved
2017-02-17
09 (System) Request for posting confirmation emailed to previous authors: "Randy Bush" , "Rob Austein"
2017-02-17
09 Rob Austein Uploaded new revision
2017-02-16
08 Alvaro Retana IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation::Revised I-D Needed
2017-02-16
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2017-02-16
08 Mirja Kühlewind
[Ballot comment]
This document should update rfc6810 as discussed with responsible AD.

Here is my old discuss for the record:

This is a general discuss …
[Ballot comment]
This document should update rfc6810 as discussed with responsible AD.

Here is my old discuss for the record:

This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it.

This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignore unknown types which is exactly what you want. There in this case I don't see that a new version necessary.

Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that duplicating all the text is the best option.

I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibility mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other clarification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice.
2017-02-16
08 Mirja Kühlewind [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss
2017-02-16
08 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2017-02-16
08 Alexey Melnikov
[Ballot comment]
Thank you for a well written document.

I share Mirja's concern about versioning, her concern is related to my comment below.

Regarding obsoleting …
[Ballot comment]
Thank you for a well written document.

I share Mirja's concern about versioning, her concern is related to my comment below.

Regarding obsoleting the original RFC: I am Ok with not doing that if both are going to be used at the same time, but I would like to hear from the WG whether this is the case.

I have one small issue I would like to discuss:

In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change.
2017-02-16
08 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2017-02-16
08 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2017-02-15
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-02-15
08 Ben Campbell
[Ballot comment]
I share Mirja's questions about versioning, and whether this updates or obsoletes 6810.

- 5, 2nd paragraph: Why is the SHOULD not a …
[Ballot comment]
I share Mirja's questions about versioning, and whether this updates or obsoletes 6810.

- 5, 2nd paragraph: Why is the SHOULD not a MUST? When might it make sense not to ignore the contents of a reserved field?

- 5.1, 6th paragraph: I'm not sure I understand the use of the word "commensurate" in this context.

- 9.2: Seems like a reference to RFC 7525 would be useful here.
2017-02-15
08 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-02-15
08 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2017-02-15
08 Stephen Farrell
[Ballot comment]

Review based on diff. [1]

[1] https://tools.ietf.org/rfcdiff?url1=rfc6810&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt

- 5.1: To get around the hard-coded-sha1 thing could we do the
same with the 20 …
[Ballot comment]

Review based on diff. [1]

[1] https://tools.ietf.org/rfcdiff?url1=rfc6810&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt

- 5.1: To get around the hard-coded-sha1 thing could we do the
same with the 20 byte SKI value as we did on some other recent
RPKI spec? (IIRC, that was to say that if actual SKI is longer
truncate left, and if shorter pad left with zero, but please
check.)

- section 9: What's the background to removing the statement
that one of TCP-AO ssh etc SHOULD be used? What is the reality
of deployments here? I assume it is not TCP-AO anyway but does
TLS or SSH get used?

- various places: I think 6810 was correct in using "that" and
not "which" in many places. I realise that's a fairly frequent
style thing that gets toggled though, but I bet the RFC editor
sets a load of those back to "that" :-)
2017-02-15
08 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2017-02-15
08 Mirja Kühlewind
[Ballot discuss]
This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it.

This document …
[Ballot discuss]
This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it.

This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignor unknown types which is exactl what you want. There in this case I don't see that a new version necessary.

Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that doublicating all the text is the best option.

I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibily mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other calrification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice.
2017-02-15
08 Mirja Kühlewind [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind
2017-02-14
08 Suresh Krishnan
[Ballot comment]
I have read through the document and I still was unable to figure out what the Max Len field for the IPvX PDUs …
[Ballot comment]
I have read through the document and I still was unable to figure out what the Max Len field for the IPvX PDUs is being used for. It is defined as

Max Length:  An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element.

but I was not able to find any processing rules for this. i.e. what it is actually used for. An example would greatly help.
2017-02-14
08 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-02-14
08 Min Ye Closed request for Last Call review by RTGDIR with state 'Withdrawn'
2017-02-14
08 Alia Atlas [Ballot comment]
This looks like it obsoletes  RFC6810 or perhaps updates it.
The draft header should show this so RFC meta-data is accurate.
2017-02-14
08 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2017-02-14
08 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2017-02-14
08 Kathleen Moriarty
[Ballot comment]
Thanks for your work on this draft.  The first question is more of a nit, the second is more important.

Section 9.1
I …
[Ballot comment]
Thanks for your work on this draft.  The first question is more of a nit, the second is more important.

Section 9.1
I suggest saying man-in-the-middle instead of monkey-in-the-middle as we use the latter typically in documents and I don't think there's anything particularly unique to a monkey-in-the-middle attack, but correct me if I am wrong.  I think it's just an alternate name for man-in-the-middle as result of Dug Song's tool sniff on monkey.org.  If monkey-in-the-middle is important for some reason, could you include a reference?

Section 9.3
Why isn't MD5 deprecated or discouraged more in this section?
2017-02-14
08 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-02-14
08 Alexey Melnikov
[Ballot comment]
Thank you for a well written document.

I have one small issue I would like to discuss:

In section 7: what are the …
[Ballot comment]
Thank you for a well written document.

I have one small issue I would like to discuss:

In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change.
2017-02-14
08 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-02-10
08 Benoît Claise
[Ballot comment]
On top of the OPS DIR feedback from Stefan at https://datatracker.ietf.org/doc/review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07/, one editorial remark.

Periodically, the router sends to the cache the …
[Ballot comment]
On top of the OPS DIR feedback from Stefan at https://datatracker.ietf.org/doc/review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07/, one editorial remark.

Periodically, the router sends to the cache the most recent Serial
  Number for which it has has received data from that cache

s/has has/has
2017-02-10
08 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2017-02-07
08 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Stefan Winter.
2017-02-03
08 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2017-02-03
08 Alvaro Retana Ballot has been issued
2017-02-03
08 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2017-02-03
08 Alvaro Retana Created "Approve" ballot
2017-02-03
08 Alvaro Retana Ballot writeup was changed
2017-01-30
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2017-01-26
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-01-26
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the rpki-rtr-pdu subregistry of the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

the entire registry is to be modified with a new field (protocol version). The newly updated registry will be:

Protocol PDU
Version Type Description Reference
---------+------+----------------+--------------------------
0-1 0 Serial Notify [ RFC6810, [ RFC-to-be ] ]
0-1 1 Serial Query [ RFC6810, [ RFC-to-be ] ]
0-1 2 Reset Query [ RFC6810, [ RFC-to-be ] ]
0-1 3 Cache Response [ RFC6810, [ RFC-to-be ] ]
0-1 4 IPv4 Prefix [ RFC6810, [ RFC-to-be ] ]
0-1 6 IPv6 Prefix [ RFC6810, [ RFC-to-be ] ]
0-1 7 End of Data [ RFC6810, [ RFC-to-be ] ]
0-1 8 Cache Reset [ RFC6810, [ RFC-to-be ] ]
0 9 Reserved [ RFC-to-be ]
1 9 Router Key [ RFC-to-be ]
0-1 10 Error Report [ RFC6810, [ RFC-to-be ] ]
0-1 255 Reserved [ RFC6810, [ RFC-to-be ] ]

The registration rule for this registry remains RFC Required as defined by RFC 5226.

Second, in the rpki-rtr-error subregistry also in the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

a single new registration is to be made as follows:

Error Code: [ TBD-at-Registration ]
Description: Unexpected Protocol Version
Reference: [ RFC-to-be ]

We note that the authors have suggested a value of 8 for the above registration.

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2017-01-19
08 Jean Mahoney Request for Last Call review by GENART is assigned to Lucy Yong
2017-01-19
08 Jean Mahoney Request for Last Call review by GENART is assigned to Lucy Yong
2017-01-19
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matthew Miller
2017-01-19
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Matthew Miller
2017-01-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2017-01-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Stefan Winter
2017-01-16
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2017-01-16
08 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Resource Public Key Infrastructure (RPKI) to Router Protocol) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'The Resource Public Key Infrastructure (RPKI) to Router Protocol'
  as Proposed Standard

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 2017-01-30. 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


  In order to verifiably validate the origin Autonomous Systems and
  Autonomous System Paths of BGP announcements, routers need a simple
  but reliable mechanism to receive Resource Public Key Infrastructure
  (RFC 6480) prefix origin data and router keys from a trusted cache.
  This document describes a protocol to deliver them.

  This document describes version 1 of the rpki-rtr protocol.  RFC 6810
  describes version 0.


Downref:
Normative reference is made to an Obsolete document: RFC2385 (Protection of BGP Sessions via the TCP MD5 Signature Option).
The text is clear about the Status, but the reference is used due to the lack of general availability of a preferred option.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ballot/


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




2017-01-16
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2017-01-15
08 Min Ye Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli
2017-01-15
08 Min Ye Request for Last Call review by RTGDIR is assigned to Emmanuel Baccelli
2017-01-14
08 Alvaro Retana Requested Last Call review by RTGDIR
2017-01-14
08 Alvaro Retana Placed on agenda for telechat - 2017-02-16
2017-01-14
08 Alvaro Retana Last call was requested
2017-01-14
08 Alvaro Retana Ballot approval text was generated
2017-01-14
08 Alvaro Retana Ballot writeup was generated
2017-01-14
08 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2017-01-14
08 Alvaro Retana Last call announcement was changed
2017-01-14
08 Alvaro Retana Last call announcement was generated
2017-01-07
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-01-07
08 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt
2017-01-07
08 (System) New version approved
2017-01-07
08 (System) Request for posting confirmation emailed to previous authors: "Randy Bush" , "Rob Austein"
2017-01-07
08 Rob Austein Uploaded new revision
2016-04-22
07 Alvaro Retana
=== AD Review -07 ===
Hi!

I have a couple of Major comments related to the existence/co-existence of two versions of the protocol.  I would …
=== AD Review -07 ===
Hi!

I have a couple of Major comments related to the existence/co-existence of two versions of the protocol.  I would like to see the comments discussed/addressed before starting the IETF Last Call.

Thanks!!

Alvaro.


Major:

1.RFC6810.

* Section 1.2. (Changes from RFC 6810):  "The protocol described in this document is largely compatible with [RFC6810]."  What does "largely compatible" mean?  It either is compatible or it isn't.  From Section 7. (Protocol Version Negotiation), it looks like there's no way for a router that only supports version 0 to talk a cache that only supports version 1, and viceversa.  Even though the PDUs are mostly the same, that doesn't seem to matter…in the end it looks like the versions
are not compatible and in reality version 1 is simply an update to version 0.

* This document is marked as obsoleting rfc6810, but it mandates its use in section 7 ("…the cache MUST downgrade to protocol version 0 [RFC6810]…").  There are a couple of paths forward:
1. It seems to me that this document should simply be called "RPKI to Router Protocol version 1" and not change the status of rfc6810 — we can always declare version 0 historic later.
2. If you really want to obsolete version 0, then an alternative is to eliminate the normative language when it refers to it...  For example,

    * OLD> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."
    * NEW> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache SHOULD send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."


2. Section 7. (Protocol Version Negotiation)  Related to the points above…  Are other versions of this protocol expected?  I know the answer may come from a crystal ball at this point…but can the process defined here be generalized?


Minor:

1. Implementation

* In Section 1. (Introduction) you reference rfc7128 for an implementation report, but that RFC reports on the implementation of rfc6810, and not this new version. 
* It would be nice to include a section according to rfc6982 about implementations of this version.


2. Section 9. (Transport)  I think this sentence is superfluous: "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPSec transport.", because a couple of paragraphs later the text also says "…caches and routers MUST use one of the following more protected protocols" (and the same protocols are revisited).
2016-04-22
07 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2016-04-22
07 Alvaro Retana Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>, aretana@cisco.com from "Chris Morrow" <morrowc@ops-netman.net>
2016-03-25
07 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2016-03-05
07 Chris Morrow
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 …
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?

  The RFC is to be Standards Track

(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

  In order to verifiably validate the origin Autonomous Systems and
  Autonomous System Paths of BGP announcements, routers need a simple
  but reliable mechanism to receive Resource Public Key Infrastructure
  (RFC 6480) prefix origin data and router keys from a trusted cache.
  This document describes a protocol to deliver validated prefix origin
  data and router keys to routers.

Working Group Summary

  This document is an update to RFC6810.  It adds support for
  a new PDU to carry router key information, new timing
  values, and a version negotiation.  As it is an update to
  a protocol currently in use, the working group discussion
  was focused on the additional features.

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?

  There are three different implementations of the server side
  of this protocol.  Three router vendors have implemented the
  client side.  Four other implementations of the client side
  are also known.

  Richard Hansen did a particularly meticulous review.

  There was no need for an expert review.

Personnel

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

  Document Shepherd: Chris Morrow
  Responsible Area Director: Alvaro Retana

(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 has read the document and believes the document
  is ready for a publication request.

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

  No.  Several reviews were detailed and in depth.

(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 need for a review from a broader perspective.

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

  The document shepherd has no concerns.

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

  Each author has confirmed that they know of no needed IPR
  disclosures.

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

  No, no IPR disclosures have been filed.

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

  This document has been discussed in the wg since Apr 2014.
  This is an update to rfc64810 with a limited number of changes
  to discuss, and there was solid agreement on the changes.

(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 appeal has been threatened or filed.

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

  The nits tool finds the following errors:

  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

  This is true of RFC6810 as well.  Both RFC2385 and RFC6925 were/are
  mentioned in the draft as alternatives, RFC2385 is a "MAY".


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

  There is no nothing in the document that requires a formal review.

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

  Yes, the list of references is separated into normative and informative.

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

  The reference draft-ietf-sidr-bgpsec-algs  has passed wglc but
  is waiting on a referenced document.

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

  The nits tools reports no downrefs.

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

    This document obsoletes RFC6810.  That is listed in the header
    on the first page.  The changes are listed in the Introduction
    section, in section 1.2.


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

  This document extends the IANA registries established in RFC6810.
  This document defines a new protocol version, and retains the
  original registered values for the rpki-rtr-pdu and rpki-rtr-error
  registries, duplicating the registered values for the new protocol
  version.  A new value is added to the rpki-rtr-pdu registry and
  a new value is added to the rpki-rtr-error registry.  This is
  consistent with the text.

  The registries are clearly identified, the values are consistent
  with the text, all extensions are noted for registration in the
  proper registries.  No new IANA registries are created.

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

  No new IANA registries are created by this document.

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

  There are no formal languages used in this document.

2016-03-05
07 Chris Morrow Responsible AD changed to Alvaro Retana
2016-03-05
07 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2016-03-05
07 Chris Morrow IESG state changed to Publication Requested
2016-03-05
07 Chris Morrow IESG process started in state Publication Requested
2016-03-05
07 Chris Morrow Changed consensus to Yes from Unknown
2016-03-05
07 Chris Morrow Intended Status changed to Proposed Standard from None
2016-03-05
07 Chris Morrow Changed document writeup
2016-03-05
07 Chris Morrow Notification list changed to "Chris Morrow" <morrowc@ops-netman.net>
2016-03-05
07 Chris Morrow Document shepherd changed to Chris Morrow
2016-03-03
07 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-07.txt
2015-10-07
06 Sandra Murphy back filling wg process history:
wglc started 2015-03-06
new (minor) issues raised: 2015-07-16
2015-10-07
06 Sandra Murphy IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2015-10-06
06 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-06.txt
2015-08-03
05 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.txt
2015-06-15
04 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt
2015-04-01
03 Sandra Murphy This document now replaces draft-austein-sidr-rpki-rtr-rfc6810bis instead of None
2015-03-05
03 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.txt
2014-08-29
02 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-02.txt
2014-04-04
01 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt
2014-03-12
00 Rob Austein New version available: draft-ietf-sidr-rpki-rtr-rfc6810-bis-00.txt