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

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.

This looks like it obsoletes  RFC6810 or perhaps updates it.
The draft header should show this so RFC meta-data is accurate.

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.

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

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?

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.

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" :-)

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.