The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2
draft-ietf-sidrops-8210bis-12

Document was removed from RFC Editor queue, and returned to WG. See: https://mailarchive.ietf.org/arch/msg/sidrops/H-CHWjdH0W08a0IrLN9FOCyryWA/

Hopefully this can very soon be resolved, but will unfortunately need another WLGC, IETF LC and IESG Eval (these should note that the document had previously been approved)

https://mailarchive.ietf.org/arch/msg/sidrops/E7sFSTUgHaAaR9idTyF387SjGnk/


I am asking the SIDROPS chairs to determine consensus on the AFI Flags handling issues. The document remains with the RFC Editor at the moment, but may need to be returned.

[Ballot comment]
Many thank's for the update that addresses my previous discuss, I appreciate the willingness of the authors to work to resolve the issues that have been seen so expeditiously.

As such, am clearing the discuss.

[Ballot comment]
[Updated ballot to clear my Discuss - thanks for accommodating my concern.]

1.
I also support Martin's Discuss - I don't understand why publishing v2 of this protocol wouldn't obsolete v1 (on the assumption that new deployments should use v2 in preference to v1).

2. Section 5.1:
      Using persistent storage for the Session ID or a clock-based
      scheme for generating Session IDs should avoid the risk of Session
      ID collisions.

      The Session ID might be a pseudorandom value, a strictly
      increasing value if the cache has reliable storage, et cetera.  A
      seconds-since-epoch timestamp value such as the POSIX time()
      function makes a good Session ID value.
     
Given that session-id is only 16 bits, it feels like both pseudorandom and using POSIX time() could quite reasonably cause occasional collisions.  Using persistent storage to generate the session-id would likely decrease the frequency of collisions.  Another idea could be to also randomly generate the starting serial number, since this would seem to greatly increase the entropy and reduce the chance for a collision.

3.  Section 5.10.  Router Key

I found the "Router Key" PDU hardest to understand what it is and what it is for.  I would suggest having a bit more text before the packet field diagram to indicate what this PDU is.

4. Section 8.3:
  When a router receives this kind of error, the router SHOULD attempt
  to connect to any other caches in its cache list, in preference
  order.  If no other caches are available, the router MUST issue
  periodic Reset Queries until it gets a new usable load from the
  cache.

Are these periodic Reset Queries still expected to be "once per 2 hours" (as per section 6)?


5. section: 7.  Protocol Version Negotiation

  downgrade to protocol version Q [RFC6810] or [RFC8210] or send a
  version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and terminate the connection; in which case the Arbitrary
  Text field of the ERROR Report PDU MUST be a list of one octet binary
  integers indicating the version numbers the cache supports.

My reading of this text is it is overwriting what a client would expect to be a text field with binary data.  At best, an peer supporting an older version wouldn't understand this and more plausibly it would regard it as being badly formed.

Why not encode the supported versions in a comma separated values in the error string?  Alternatively you could just keep a simpler versioning strategy of the client trying earlier versions in decreasing sequence until it finds a version that both are compatible with.
 
6. Section 9.  Transport

  *  Caches and routers MAY use TCP MD5 transport [RFC5925] using the
      rpki-rtr port.  Note that TCP MD5 has been obsoleted by TCP-AO
      [RFC5925].
     
Since this is describing version 2 of the protocol, why not remove this option to reduce the list of "more protected protocols".  In fact, given this is a new protocol version, I was wondering whether it would be feasible to reduce this list further, but perhaps that puts too much burden on implementations.

7. Is there any YANG configuration model, or plans to generate one, to manage the required device configuration?  Perhaps this is being done as part of the BGP YANG model?

Nit:

      RPKI data.  While a cache is receiving updates, new incoming data
      and implicit deletes are associated with the new serial but MUST
      NOT be sent until the fetch is complete.
     
new serial => new serial number

Regards,
Rob

[Ballot comment]
I've lifted the DISCUSS about Updates vs. Obsoletes -- my personal preference would be for this to obsolete v1 and v0, as v2 is a strict improvement on those, and make it very clear in the abstract and introduction that v0/v1 are likely to persist for a long time. This would be clearest to the wider IETF community about what is happening -- observers do not expect that devices that run obsoleted protocol versions are immediately thrown in the dumpster, but that new deployments will use the latest version.

However, I now understand that this community understands the term differently, unfortunately. So if they feel very strongly that it should be "Updates", I'm not going to block the document over it.

Older commments:

Thanks to Michael Tuexen for the TSVART review.

(Section 6) "Caches MUST set Expire Interval to a value larger than either Refresh Interval or Retry Interval."

This would seem to allow a configuration where Refresh > Expire > Retry, which would result in records constantly timing out without a refresh, no?

[Not a DISCUSS because it's a holdover from 8210]

Nits:
(Section 4) s/twoo/too

(Section 10) s/server/cache

[Ballot discuss]
Following discussions and Martin indicating that he is clearing his discuss - I'm raising a discuss on the same text. I may clear this discuss after some more thoughts, but I have concerns here that this is not backward compatible and not obsoleting may need to some confusion.

Martin's original discuss text:

One item that I'd briefly like clarification on:

While I recognize that this fits the pattern of RFC8210 and RFC6810, I don't see why this document doesn't "obsolete" 8210 instead of merely "updating" it.

[Ballot comment]
# GEN AD review of draft-ietf-sidrops-8210bis-09

CC @larseggert

Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/XAvuQVjZUdo06MI1SBmOKlCSHy8).

## Comments

### "Abstract", paragraph 2
```
    This document describes version 2 of the RPKI-Router protocol.  RFC
    6810 describes version 0, and RFC 8210 describes version 1.  This
    document updates and replaces RFC 8210.
```
Agree with Martin's DISCUSS and Roman's comment. The document relationships are
unclear.

### Section 5.11, paragraph 6
```
    If the error is associated with a PDU of excessive length, i.e., too
    long to be any legal PDU other than another Error Report, or a
    possibly corrupt length, the Erroneous PDU field MAY be truncated.
```
Would it be useful to make this truncation explicit to the receiver of the error
report?

### Section 8.1, paragraph 1
```
    When a transport connection is first established, the router MUST
    send either a Reset Query or a Serial Query.  A Serial Query would be
    appropriate if the router has significant unexpired data from a
    broken session with the same cache and remembers the Session ID of
    that session, in which case a Serial Query containing the Session ID
```
How can a router tell if the unexpired data from a broken session with the same
cache it still holds is "significant"?

### Section 9, paragraph 6
```
    If unprotected TCP is the transport, the cache and routers MUST be on
    the same trusted and controlled network.
```
Do we really need to allow unencrypted TCP as a transport for this in 2022? This
seems risky even on a "trusted and controlled network", even if the protocol
wasn't used for disseminating sensitive information.

### Section 9, paragraph 9
```
    *  Caches and routers MAY use TCP MD5 transport [RFC2385] using the
        rpki-rtr port if no other protected transport is available.  Note
        that TCP MD5 has been obsoleted by TCP-AO [RFC5925].
```
Do we really still need to allow TCP MD5, which has been obsoleted for over a
decade and has had known issues for much longer than that?

### DOWNREFs

DOWNREF `[I-D.ietf-sidrops-aspa-profile]` from this Proposed Standard to
`draft-ietf-sidrops-aspa-profile` of unknown standards level. (Chairs should
indicate the standards level of draft-ietf-sidrops-aspa-profile in
the datatracker, since the one in its text is under author control.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 4, paragraph 10
```
-    with twoo many failed requests.
-          -
```

#### Section 5.5, paragraph 5
```
-    This PDU carries an [RFC6811] Vidated ROA Payload (VRP) for an IPv4
+    This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv4
+                                  ++
```

#### Section 5.7, paragraph 2
```
-    This PDU carries an [RFC6811] Vidated ROA Payload (VRP) for an IPv6
+    This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv6
+                                  ++
```

#### Section 7, paragraph 2
```
-    The router MUST choose the highest mutally supported version.  If
+    The router MUST choose the highest mutually supported version.  If
+                                          +
```

### Section 5.1, paragraph 2
```
    Protocol Version:  An 8-bit unsigned integer, currently 2, denoting
        the version of this protocol.
```
"Currently 2" reads a bit odd. Maybe "2 for this version of the protocol"?

### Uncited references

Uncited references: `[RFC8126]`.

### Outdated references

Reference `[RFC2385]` to `RFC2385`, which was obsoleted by `RFC5925` (this may
be on purpose).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
I am supporting Martin's discuss position.

Having reviewed this before reading the other comments and discuss positions, I also picked up what John saw in 5.1 regarding the length of the SKI, and would agree that it seems this should be either 20 octets or 160bits.

in 5.12 where it reads "The router should see at most...", based on the context I would question if this should not be a MUST.

[Ballot comment]
I support Martin's DISCUSS.

The shepherd writeup, in question one, asks "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?"  Only the first of these questions is answered.  Also the answer to the question on document quality describes what this document does, but appears not to answer directly the question about existing implementations of the extension/update.

The SHOULD at the end of Section 4 is bare; why would one not try to reestablish a connection?  I think there ought to be some guidance here, or change it to a MUST or MAY.

Nit:

* Section 5.1: s/epoc/epoch/

[Ballot comment]
Thanks for this document. Note, I reviewed only the diff between RFC 8210 and draft-ietf-sidrops-8210bis-09, not the full text.

I have a few comments on the parts I reviewed.

1. RFC 8210 said the SKI was 20 octets. This spec in §5.1 says it’s 20 bits:

  Subject Key Identifier:  The 20-bit Subject Key Identifier (SKI)
      value of a router key, as described in [RFC6487].

I think RFC 8210 was right. Here is what RFC 6487 says about SKIs:

4.8.2.  Subject Key Identifier

  This extension MUST appear in all resource certificates.  This
  extension is non-critical.

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  Subject Public Key, as described in Section 4.2.1.2 of [RFC5280].

That ain’t no 20 bits.

2. In §5.12,

                                                            This is to
  avoid a race condition when a BGP announcement is received between a
  withdrawn ASPA PDU and a newly announced ASPA PDU.  Therefore, the
  cache MUST deliver the complete data of an ASPA record in a single
  ASPA PDU.

I found this to be more confusing than helpful. Maybe it’s just the BGP implementor in me, but the implicit withdraw semantics specified earlier in the paragraph are as natural as breathing; breaking in to justify them makes me briefly strip a gear. IMO these sentences could be removed (but do as you will).

3. Again in §5.12, next paragraph,

  The router should see at most one ASPA for a given AFI from a cache
  for a particular Customer Autonomous System Number active at any
  time.

Isn’t it considerably stronger than “should”? In the previous paragraph you say ASPAs have implicit-withdraw semantics, so if that’s properly implemented it’s not physically possible to see more than one ASPA for a given (AFI, Customer ASN) from a cache at any given time.

So depending on what you’re trying to do with this sentence, you could write it something like “Because of the semantics defined above, the router can see at most…”

3. You introduce a new field (the AFI Flags field of the ASPA PDU) with reserved bits, but don’t define a registry for allocating those bits. I suppose this is on purpose, given the practice in this WG of issuing whole new protocol specs instead of piecemeal extensions?

4. A bit picky perhaps (who, ME?), but (still in §5.12) in

  The Customer Autonomous System Number is the 32-bit Autonomous System
  Number of the customer which authenticated the PDU.  For a given AFI,
  there MUST be one and only one ASPA for a Customer Autonomous System
  Number active in the router at any time.

I don’t think the customer authenticated the *PDU* per se, did they? They signed something in the RPKI, I guess, which the cache scraped up and turned into a PDU. The customer has no direct connection with the PDU.

5. It seems as though this, in §7, could be tightened up:

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210] or send a
  version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and terminate the connection; in which case the Arbitrary
  Bytes field of the ERROR Report PDU MUST be a list of one octet
  binary integers indicating the version numbers the cache supports.
  The router MUST choose the highest mutally supported version.  If
  there are none, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version").

Perhaps something like

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210]. If version
  Q is not supported, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and Arbitrary Bytes field a list of one octet
  binary integers indicating the version numbers the cache supports.

6. In §13, “Reliable transport protocols (i.e. not raw TCP)” kind of bugged me, since TCP is the canonical exemplar of a reliable transport. Do you want some adjective other than “reliable”?

Nits:

s/epoc/epoch/

s/      specified address family other ASes./      specified address family to other ASes./ (you’re missing a “to”)

s/Vidated/Validated/ (2 places)

S/mutally/mutually/

I favor the pluralization “ASes” over “ASs”, not for juvenile reasons but because “AS” is typically read “ay ess” and “ess” is pluralized “esses”. Anyway I’m sure the RFC Editor has their own opinions about this, do as you will.

[Ballot comment]
Thanks for this document. Note, I reviewed only the diff between RFC 8210 and draft-ietf-sidrops-8210bis-09, not the full text.

I have a few comments on the parts I reviewed.

1. RFC 8210 said the SKI was 20 octets. This spec in §5.1 says it’s 20 bits:

  Subject Key Identifier:  The 20-bit Subject Key Identifier (SKI)
      value of a router key, as described in [RFC6487].

I think RFC 8210 was right. Here is what RFC 6487 says about SKIs:

4.8.2.  Subject Key Identifier

  This extension MUST appear in all resource certificates.  This
  extension is non-critical.

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  Subject Public Key, as described in Section 4.2.1.2 of [RFC5280].

That ain’t no 20 bits.

2. In §5.12,

                                                            This is to
  avoid a race condition when a BGP announcement is received between a
  withdrawn ASPA PDU and a newly announced ASPA PDU.  Therefore, the
  cache MUST deliver the complete data of an ASPA record in a single
  ASPA PDU.

I found this to be more confusing than helpful. Maybe it’s just the BGP implementor in me, but the implicit withdraw semantics specified earlier in the paragraph are as natural as breathing; breaking in to justify them makes me briefly strip a gear. IMO these sentences could be removed (but do as you will).

3. Again in §5.12, next paragraph,

  The router should see at most one ASPA for a given AFI from a cache
  for a particular Customer Autonomous System Number active at any
  time.

Isn’t it considerably stronger than “should”? In the previous paragraph you say ASPAs have implicit-withdraw semantics, so if that’s properly implemented it’s not physically possible to see more than one ASPA for a given (AFI, Customer ASN) from a cache at any given time.

So depending on what you’re trying to do with this sentence, you could write it something like “Because of the semantics defined above, the router can see at most…”

3. You introduce a new field (the AFI Flags field of the ASPA PDU) with reserved bits, but don’t define a registry for allocating those bits. I suppose this is on purpose, given the practice in this WG of issuing whole new protocol specs instead of piecemeal extensions?

4. A bit picky perhaps (who, ME?), but (still in §5.12) in

  The Customer Autonomous System Number is the 32-bit Autonomous System
  Number of the customer which authenticated the PDU.  For a given AFI,
  there MUST be one and only one ASPA for a Customer Autonomous System
  Number active in the router at any time.

I don’t think the customer authenticated the *PDU* per se, did they? They signed something in the RPKI, I guess, which the cache scraped up and turned into a PDU. The customer has no direct connection with the PDU.

5. It seems as though this, in §7, could be tightened up:

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210] or send a
  version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and terminate the connection; in which case the Arbitrary
  Bytes field of the ERROR Report PDU MUST be a list of one octet
  binary integers indicating the version numbers the cache supports.
  The router MUST choose the highest mutally supported version.  If
  there are none, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version").

Perhaps something like

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210]. If version
  Q is not supported, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and Arbitrary Bytes field a list of one octet
  binary integers indicating the version numbers the cache supports.

6. In §13, “Reliable transport protocols (i.e. not raw TCP)” kind of bugged me, since TCP is the canonical exemplar of a reliable transport. Do you want some adjective other than “reliable”?

Nits:

s/epoc/epoch/
s/      specified address family other ASes./      specified address family to other ASes./ (you’re missing a “to”)
s/Vidated/Validated/ (2 places)
S/mutally/mutually/

I favor the pluralization “ASes” over “ASs”, not for juvenile reasons but because “AS” is typically read “ay ess” and “ess” is pluralized “esses”. Anyway I’m sure the RFC Editor has their own opinions about this, do as you will.

[Ballot comment]
Thanks for this document. Note, I reviewed only the diff between RFC 8210 and draft-ietf-sidrops-8210bis-09, not the full text.

I have a few comments on the parts I reviewed.

1. RFC 8210 said the SKI was 20 octets. This spec in §5.1 says it’s 20 bits:

  Subject Key Identifier:  The 20-bit Subject Key Identifier (SKI)
      value of a router key, as described in [RFC6487].

I think RFC 8210 was right. Here is what RFC 6487 says about SKIs:

4.8.2.  Subject Key Identifier

  This extension MUST appear in all resource certificates.  This
  extension is non-critical.

  The Key Identifier used for resource certificates is the 160-bit
  SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the
  Subject Public Key, as described in Section 4.2.1.2 of [RFC5280].

That ain’t no 20 bits.

2. In §5.12,

                                                            This is to
  avoid a race condition when a BGP announcement is received between a
  withdrawn ASPA PDU and a newly announced ASPA PDU.  Therefore, the
  cache MUST deliver the complete data of an ASPA record in a single
  ASPA PDU.

I found this to be more confusing than helpful. Maybe it’s just the BGP implementor in me, but the implicit withdraw semantics specified earlier in the paragraph are as natural as breathing; breaking in to justify them makes me briefly strip a gear. IMO these sentences could be removed (but do as you will).

3. Again in §5.12, next paragraph,

  The router should see at most one ASPA for a given AFI from a cache
  for a particular Customer Autonomous System Number active at any
  time.

Isn’t this considerably stronger than “should”? In the previous paragraph you say ASPAs have implicit-withdraw semantics, so if that’s properly implemented it’s not physically possible to see more than one ASPA for a given (AFI, Customer ASN) from a cache at any given time.

So depending on what you’re trying to do with this sentence, you could write it something like “Because of the semantics defined above, the router can see at most…”

3. You introduce a new field (the AFI Flags field of the ASPA PDU) with reserved bits, but don’t define a registry for allocating those bits. I suppose this is on purpose, given the practice in this WG of issuing whole new protocol specs instead of piecemeal extensions?

4. A bit picky perhaps (who, ME?), but (still in §5.12) in

  The Customer Autonomous System Number is the 32-bit Autonomous System
  Number of the customer which authenticated the PDU.  For a given AFI,
  there MUST be one and only one ASPA for a Customer Autonomous System
  Number active in the router at any time.

I don’t think the customer authenticated the *PDU* per se, did they? They signed something in the RPKI, I guess, which the cache scraped up and turned into a PDU. The customer has no direct connection with the PDU.

5. It seems as though this, in §7, could be tightened up:

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210] or send a
  version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and terminate the connection; in which case the Arbitrary
  Bytes field of the ERROR Report PDU MUST be a list of one octet
  binary integers indicating the version numbers the cache supports.
  The router MUST choose the highest mutally supported version.  If
  there are none, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version").

Perhaps something like

  If a cache which supports version N receives a query from a router
  which specifies its highest supported version Q < N, the cache MUST
  downgrade to protocol version Q [RFC6810] or [RFC8210]. If version
  Q is not supported, the router MUST abort the session, sending a version
  2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and Arbitrary Bytes field a list of one octet
  binary integers indicating the version numbers the cache supports.

6. In §13, “Reliable transport protocols (i.e. not raw TCP)” kind of bugged me, since TCP is the canonical exemplar of a reliable transport. Do you want some adjective other than “reliable”?

Nits:

s/epoc/epoch/
s/      specified address family other ASes./      specified address family to other ASes./ (you’re missing a “to”)
s/Vidated/Validated/ (2 places)
S/mutally/mutually/

I favor the pluralization “ASes” over “ASs”, not for juvenile reasons but because “AS” is typically read “ay ess” and “ess” is pluralized “esses”. Anyway I’m sure the RFC Editor has their own opinions about this, do as you will.

[Ballot comment]
Thanks for working on this -bis.

I would also like to know why this is not obsoleting 8210. So supporting Martin and Rob's discusses.

[Ballot comment]
I support the three discusses, especially Roman's remark about copying in security text from two previous RFC documents without updating, and Martin's remark about Update vs Obsolete.

[Ballot comment]
§5.12

These two paragraphs seem to describe the same case (withdraw) but specify different behavior:

  The announce/withdraw flag set to 0 indicates removal of the ASPA
  record in total.  Here, only the AFI and the customer AS of the ASPA
  record MUST be provided, the Provider AS Count as well as the Provider
  AS Numbers list MUST be zero.
  ...
  Receipt of an ASPA PDU with the Flags field indicating Delete is an
  explicit withdraw from the router of the entire ASPA data for that
  customer AS.  While the Provider AS Count and the Provider AS Numbers
  MUST be ignored by the router when the Flags field indicates a
  Delete, the cache MUST set the Provider AS Count to zero, and have a
  null Provider AS Numbers list.


Both require the setting of the Provider AS Count and Provider AS Numbers fields, but only the latter says that these fields "MUST be ignored".  Is that the expected behavior?  Please specify the behavior only once.

If the router is not required to ignore the fields (as initially specified), what should the receiver do if the Provider AS Count or the Provider AS Numbers are not 0?  Should that trigger an error?

[Ballot discuss]
** Section 5.11

  The diagnostic text is optional; if not present, the Length of Error
  Text field MUST be zero.  If error text is present, it MUST be a
  string in UTF-8 encoding (see [RFC3629]).

How does the protocol convey the language the diagnostic text?  Per Section 4.2 of BCP 18, “[p]rotocols that transfer text MUST provide for carrying information about the language of that text.”

I appreciate that this behavior in v2 comes from v1 and v0.  How was it handled previously?

** Section 7.  The guidance on error reporting seems inconsistent.

(a) Section 5.11 says “If error text is present, it MUST be a string in UTF-8 encoding”

(b) Section 7 says “in which case the Arbitrary Text field of the ERROR Report PDU MUST be a list of one octet binary integers indicating the version numbers the cache supports.”

The text in (b) seems to be describing an encoding inconsistent with the guidance in (a).

** Section 9.  Use of TCP MD5.

  It is expected that, when the TCP Authentication Option (TCP-AO)
  [RFC5925] is available on all platforms deployed by operators, it
  will become the mandatory-to-implement transport.
        …
  *  Caches and routers MAY use TCP MD5 transport [RFC5925] using the
      rpki-rtr port.  Note that TCP MD5 has been obsoleted by TCP-AO
      [RFC5925].

The above text comes from RFC6810 (2013), repeated again in RFC8210 (2017) and stated here (2022).  Why isn’t it appropriate 9 years later to drop support for TCP MD5 in v2?  Can the operational considerations preventing older platforms from staying with v1 be explained?

If there was a compelling operational reason, could the text be rewritten to the effect of “TCP MD5 SHOULD NOT be used unless TLS, IPSec and SSH are NOT supported.”

** Section 9.  Per the TLS guidance, is there a reason why conformance to RFC7525 or draft-ietf-uta-rfc7525bis-07 cannot be required to ensure modern version of TLS and secure ciphersuites.

[Ballot comment]
** Relationship with RFC8210.  I support Martin Duke's DISCUSS.

-- The abstracts says “This document updates and replaces RFC 8210.”  When I read “replaces”, I took that to mean that RFC8210 is obsoleted by this document.

-- Section 1 says “This document updates [RFC8210].”  I found that confusing because I don’t see how I need to read this document to implement v1 of the protocol.  I was under the impression this was v2, something stand-alone.

** Section 4.  Per “It is configured with a semi-ordered list of caches …”, what kind of data structure is “semi-ordered”?  Is this a priority list?

** Section 4.
  ... servers'
  clocks MUST be correct to a tolerance of approximately an hour.

How does an implementer reconcile the strict “MUST” guidance of “approximately an hour” and still ensure interoperability?  What is the “tolerance” on “approximately” -- 60 minutes and 1 second, 70 minutes, etc.  I recommend s/approximately an hour/an hour/.

** Section 5.1.  Why do some fields have a data-type and others just text description.  For example, “Protocol Version” is explicitly described as being an 8-bit unsigned integer, but the text doesn’t say that a Serial number is 32-bits.

** Section 5.1. 
      A cache increments its Serial Number when
      completing a rigorously validated update from a parent cache or
      the Global RPKI.

Is there are update which is not “rigorously validated”?  I’m trying to understand if there are updates which don’t bump the serial number.

** Section 5.1.  With a 16-bit Session ID, how concerning or likely is a collision?  Rob Wilton asked a similar question.  A few birthday paradox approximations says 50% chance of a collision with 256 caches or 1% chance of collision with 36 caches assuming they are randomly selected.

** Section 5.1
      A
      seconds-since-epoch timestamp value such as the POSIX time()
      function makes a good Session ID value.

What is the recommended approach to convert the POSIX time() result into the smaller 16-bit value?

** Section 5.1.  Per the definition of a Provider AS Number, what is a “spacified AFI”?

** Section 5.6, 5.7, and 5.10.  Editorial. In the PDU descriptions prior to these, the section text opened with some notional description of who sends the PDU and why.  Here, the section opens with a diagram and only covers a field level description.

** Section 5.7.

Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.

What is mean by “… and no magic?”

** Section 5.10.  What is the Length of the PDU?  The figure suggests that the Subject Key Info is a fixed 4 bytes which doesn’t seem right.

** Section 5.11.  The section doesn’t explicitly define the contents of the “Encapsulated PDU” field.

** Section 9.1.  Per the SSH authentication information:
  User authentication MUST be supported; host
  authentication MAY be supported.  Implementations MAY support
  password authentication.

-- What is “user authentication”?    Per the authentication method names in https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-10, there isn’t one called that.  Do you mean “publickey”?  Maybe:

NEW
User authentication (“publickey”) MUST be supported; host    authentication (“hostbased”) MAY be supported.  Implementations MAY support password authentication (“password”).

-- Since this text appears to be profiling SSH, and the this here comes from Section 5 of RFC4252, should it be explicitly said that “none” MUST NOT be used.

** Section 9.2.

      The client router MUST set its "reference identifier" to the DNS
      name of the rpki-rtr cache.

What is a “reference identifier”?

** Section 9.3.

If TCP MD5 is used, implementations MUST support key lengths of at
  least 80 printable ASCII bytes, per Section 4.5 of [RFC5925].

RFC5925 doesn’t have a Section 4.5, or provide guidance about using printable ASCII bytes

** Section 10.
This preference merely denotes proximity, not
  trust, preferred belief, et cetera. 

“Proximity” to what?  I though this list was rank order list per the preference value.

** Section 11. 
When a cache is sending ROA PDUs to a router ...

I missed something.  What are ROA PDUs in this context?  Why are they not defined in Section 5.

** Section 12.

  To keep load on Global RPKI services from unnecessary peaks, it is
  recommended that primary caches which load from the distributed
  Global RPKI not do so all at the same times, e.g., on the hour.

I’m trying to tie this recommendation for “primary caches” back to the three deployment scenarios.  Is the ISP backbone the only one that operates a “primary cache?”

** Section 13.  This error code text appears to be verbatim from RFC8210.  The text also suggests that [iana-err] is the registry for these error code points.  [iana-err] says the reference for these errors is RFC6810 for 0-7, and RFC8210 for 8. 

If [iana-err] isn’t being updated to point to this text as the canonical definition, then why repeat it here?  Couldn’t it just cite RFC8210?  What new information is being added?

** Section 14.

      ... they need to be
      given consistent trust anchors to use in their internal validation
      process.  Distribution of a consistent trust anchor is assumed to
      be out of band.

-- Distributed to who?  Is it the routers?

-- What makes a trust anchor “consistent?”  Is the intent of this text to say that in order to access a variety of caches, routers need the corresponding trust anchors of these caches?

** Section 14.

      Hence, the last link, from cache to
      router, is secured by server authentication and transport-level
      security. 

Please be clear that this is not always the case.  Section 9 allows for TCP.

** Section 14.

      The identity of the cache server SHOULD be verified and
      authenticated by the router client, and vice versa, before any
      data are exchanged.

(Excluding normal TCP) Are these verification and authentication practices something different than specified by the protocol behavior in Section 9?  If not, why the “SHOULD” as conformance to these protocols is a MUST.

** Section 14.  The text doesn't explicitly describe the risks of using an unprotected TCP connection.

** Section 15.
  The policy for adding to the registry is RFC Required per [RFC8126];
  the document must be either Standards Track or Experimental.

Is this text needed?  The registry already says this is the policy.

** Section 15.

Protocol version 1 added one
  new error code:

              Error
              Code    Description
              -----  ---------------------------
                  8  Unexpected Protocol Version

Why is a change made by v1 germane to the IANA considerations of v2?  I don’t think this text is needed.

[Ballot discuss]
Hi,

Thanks for this document.

My discuss is on the protocol version negotiation:

(1) Either the text is unclear, of the version negotiation is suggesting overriding a text field with binary data in the case that the server doesn't support the client version.  This doesn't seem like a good idea - more context in the comment section (5) below.

Regards,
Rob

[Ballot comment]
1.
I also support Martin's Discuss - I don't understand why publishing v2 of this protocol wouldn't obsolete v1 (on the assumption that new deployments should use v2 in preference to v1).

2. Section 5.1:
      Using persistent storage for the Session ID or a clock-based
      scheme for generating Session IDs should avoid the risk of Session
      ID collisions.

      The Session ID might be a pseudorandom value, a strictly
      increasing value if the cache has reliable storage, et cetera.  A
      seconds-since-epoch timestamp value such as the POSIX time()
      function makes a good Session ID value.
     
Given that session-id is only 16 bits, it feels like both pseudorandom and using POSIX time() could quite reasonably cause occasional collisions.  Using persistent storage to generate the session-id would likely decrease the frequency of collisions.  Another idea could be to also randomly generate the starting serial number, since this would seem to greatly increase the entropy and reduce the chance for a collision.

3.  Section 5.10.  Router Key

I found the "Router Key" PDU hardest to understand what it is and what it is for.  I would suggest having a bit more text before the packet field diagram to indicate what this PDU is.

4. Section 8.3:
  When a router receives this kind of error, the router SHOULD attempt
  to connect to any other caches in its cache list, in preference
  order.  If no other caches are available, the router MUST issue
  periodic Reset Queries until it gets a new usable load from the
  cache.

Are these periodic Reset Queries still expected to be "once per 2 hours" (as per section 6)?


5. section: 7.  Protocol Version Negotiation

  downgrade to protocol version Q [RFC6810] or [RFC8210] or send a
  version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol
  Version") and terminate the connection; in which case the Arbitrary
  Text field of the ERROR Report PDU MUST be a list of one octet binary
  integers indicating the version numbers the cache supports.

My reading of this text is it is overwriting what a client would expect to be a text field with binary data.  At best, an peer supporting an older version wouldn't understand this and more plausibly it would regard it as being badly formed.

Why not encode the supported versions in a comma separated values in the error string?  Alternatively you could just keep a simpler versioning strategy of the client trying earlier versions in decreasing sequence until it finds a version that both are compatible with.
 
6. Section 9.  Transport

  *  Caches and routers MAY use TCP MD5 transport [RFC5925] using the
      rpki-rtr port.  Note that TCP MD5 has been obsoleted by TCP-AO
      [RFC5925].
     
Since this is describing version 2 of the protocol, why not remove this option to reduce the list of "more protected protocols".  In fact, given this is a new protocol version, I was wondering whether it would be feasible to reduce this list further, but perhaps that puts too much burden on implementations.

7. Is there any YANG configuration model, or plans to generate one, to manage the required device configuration?  Perhaps this is being done as part of the BGP YANG model?

Nit:

      RPKI data.  While a cache is receiving updates, new incoming data
      and implicit deletes are associated with the new serial but MUST
      NOT be sent until the fetch is complete.
     
new serial => new serial number

Regards,
Rob

[Ballot discuss]
One item that I'd briefly like clarification on:

While I recognize that this fits the pattern of RFC8210 and RFC6810, I don't see why this document doesn't "obsolete" 8210 instead of merely "updating" it.

[Ballot comment]
Thanks to Michael Tuexen for the TSVART review.

(Section 6) "Caches MUST set Expire Interval to a value larger than either Refresh Interval or Retry Interval."

This would seem to allow a configuration where Refresh > Expire > Retry, which would result in records constantly timing out without a refresh, no?

[Not a DISCUSS because it's a holdover from 8210]

Nits:
(Section 4) s/twoo/too

(Section 10) s/server/cache

[Ballot discuss]
Two items that I'd briefly like clarification on:

While I recognize that this fits the pattern of RFC8210 and RFC6810, I don't see why this document doesn't "obsolete" 8210 instead of merely "updating" it.

(Section 6) "Caches MUST set Expire Interval to a value larger than either Refresh Interval or Retry Interval."

This would seem to allow a configuration where Refresh > Expire > Retry, which would result in records constantly timing out without a refresh, no?

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

The IANA Functions Operator has completed its review of draft-ietf-sidrops-8210bis-06. If any part of this review is inaccurate, please let us know.

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

We understand that references to RFC 8210 will be replaced with references to this document. If that isn't correct, please let us know.

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

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

the registry will be updated as follows:

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

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

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

the following registration will be updated as follows:

Error Code: 8
Description: Unexpected Protocol Version
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-04-29):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-8210bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 2) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'The Resource Public Key Infrastructure
(RPKI) to Router Protocol,
  Version 2'
  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
last-call@ietf.org mailing lists by 2022-04-29. 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 2 of the RPKI-Router protocol.  RFC
  6810 describes version 0, and RFC 8210 describes version 1.  This
  document obsoletes and replaces RFC 8210.




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



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?

Proposed Standard

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

  This document describes version 2 of the RPKI-Router protocol.  RFC
  6810 describes version 0, and RFC 8210 describes version 1.  This
  document updates RFC 8210.


Working Group Summary:

This -bis document got some solid review in WG mailing-list discussions, nothing stood out as controversial.

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

There are existing implementations for the rpki-rtr protocol, this -bis changes the protocol version, and adds support for
ASPA PDU types, and fixes some race-conditions in ROA PDUs.

Personnel:

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

Shepherd: chris morrow (morrowc@ops-netman.net)
RespAD: warren kumari (warren@kumari.net)


(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 shepherd has read through several versions of this document. This version is ready for publication
says the WG and the shepherd.

(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 particular review required.

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

Yes, no IPR disclosures required.

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

No.

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

Solid consensus was achieved.

(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 threats nor discussion of same.

(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 1 outdated reference:
  draft-ietf-sidrops-aspa-profile-06 -> 07
this will get sorted before publication (there is likely 1 more update for that draft anyway, because )

There are 3 'obsolete normative references':
  RFC 2385 (Obsoleted by RFC 5925)
  RFC 5246 (Obsoleted by RFC 8446)
  RFC 8208 (Obsoleted by RFC 8608)

these seem fine and will get sorted before publication as well.

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

There are no mib/yang/etc. requirements in this document.

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

yes, all references are properly categorized.

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

Yes:
  I-D.ietf-sidrops-aspa-profile

(15) Are there downward normative 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.

The existing rfc8210  will be updated, since this is: 8210-bis.

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

There are the expected IANA changes to the existing rpki-rtr-pdu fields, these seem normal to the shepherd.

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

none

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

no automated checks required.

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


no yang here.

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?

Proposed Standard

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

  This document describes version 2 of the RPKI-Router protocol.  RFC
  6810 describes version 0, and RFC 8210 describes version 1.  This
  document updates RFC 8210.


Working Group Summary:

This -bis document got some solid review in WG mailing-list discussions, nothing stood out as controversial.

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

There are existing implementations for the rpki-rtr protocol, this -bis changes the protocol version, and adds support for
ASPA PDU types, and fixes some race-conditions in ROA PDUs.

Personnel:

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

Shepherd: chris morrow (morrowc@ops-netman.net)
RespAD: warren kumari (warren@kumari.net)


(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 shepherd has read through several versions of this document. This version is ready for publication
says the WG and the shepherd.

(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 particular review required.

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

Yes, no IPR disclosures required.

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

No.

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

Solid consensus was achieved.

(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 threats nor discussion of same.

(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 1 outdated reference:
  draft-ietf-sidrops-aspa-profile-06 -> 07
this will get sorted before publication (there is likely 1 more update for that draft anyway, because )

There are 3 'obsolete normative references':
  RFC 2385 (Obsoleted by RFC 5925)
  RFC 5246 (Obsoleted by RFC 8446)
  RFC 8208 (Obsoleted by RFC 8608)

these seem fine and will get sorted before publication as well.

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

There are no mib/yang/etc. requirements in this document.

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

yes, all references are properly categorized.

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

Yes:
  I-D.ietf-sidrops-aspa-profile

(15) Are there downward normative 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.

The existing rfc8210  will be updated, since this is: 8210-bis.

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

There are the expected IANA changes to the existing rpki-rtr-pdu fields, these seem normal to the shepherd.

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

none

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

no automated checks required.

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


no yang here.