Hi,

Apologies for my lack of attention to date on this topic, so speaking only
for myself here.

At this stage I do not support this document's publication.

Starting with the document structure, I see no reference to a set of
requirements. The introduction is rather vague, and if anywhere that is
where I would expect to see such a requirements description. This means for
the rest of document I found myself asking "why" on many levels.

When I got to the end of the document I felt that the protocol borders on a
wheel re-invention exercise. When you think about a router simply being a
client to a cache that is providing RIB access tokens for a route using a
mechanism that is a secure, stable, scalable, known (by both vendors and
operators), and is extensible, I'm more likely to swing to RADIUS in doing
such a service with nicely structured AV-Pairs and sane timers for
reauth/retry etc. Even the SME's know radius for their WPA enterprise kit.


Glossary:

Global RPKI: 
I disagree with this definition for two reasons. 1) I'm not aware of a
unified definition for 'distributed system' so this is all rather vague.
Perhaps you could say 'published at a disparate set of systems'. 2) Limiting
the servers to be "at" the "IANA, RIRs, NIRs, and ISPs" is also premature.
It's not clear to me that these entities will run their own repositories,
nor are they going to be the only repository operators in the lifecycle of
the RPKI.

Cache:
The words surrounding the fetch/refresh mechanisms of the RPKI is limiting.
Both draft-ietf-sidr-repos-struct and draft-ietf-sidr-res-certs allow for
other (future) retrieval mechanisms as defined by the repository operator
beyond RSYNC (loosely documented in RFC5781).

Last sentence. "Trusting this cache further is a matter between the provider
of the cache and a relying party". In my mind the Relying Party was the one
that did the RPKI validation - would this not be better stated as "Trusting
this cache further is a matter between the provider of the cache and the
router operator".

Deployment Structure:

Why repeat the definition of "Global RPKI"? It's superfluous.

Local Cache: Again. 'Relying party' seems to be borrowed from the
CA/identity world. Unless you redefine that term here it seems as if the
"router" is making RPKI validation decisions. Which it is not. The router is
acting more like a NAS (See Radius, 2865) when talking to a local cache.

The definition of "routers" seems to get this right - eg "a client of the
cache".

Operational Overview

when you first use "ROA", please expand the TLA, and provide a reference.

Serial Query

I don't remember seeing a recommendation for how often a client (router)
sends a serial query. Is there a Min/Max? Surely doing it every second would
be excessive..

IPv4 Prefix:

"and nothing prohibits the existence of two identical
   route: or route6: objects in the IRR."

Why even mention the IRR here? It just doesn't seem at all relevant. (and
isn't defined)

" IPvX PDUs" expand to IPv4 or IPv6. Globing into one is a misdirection
under a heading of 'IPv4 Prefix'

IPv6 Prefix

Some text here to say that the IPv6 data structure follows the same
semantics as the IPv4 data structure would be good.. or alternatively
restructure the document to Semantics, then describe the IPv4 and IPv6 data
structures as subheadings to Prefix PDUs.

Error Report

What is "excessive length" of a PDU? at what point do you say "o.k, now I
can truncate".

Fields of a PDU

For all types, instead of using "ordinal" can you use the exact description
of the number? eg unsigned integer? For me I always relate ordinals to set
theory.


PDU type, the e,g is incomplete shouldn't it be "IPv4 Prefix = 4" with a
forward reference to the IANA Considerations section?

Serial Number. "for example via rcynic", Is not defined and implementation
specific! and there is a typo "completing an rigorously validated"..while
there, consider why you use the term 'rigorously'.. are there situations
when a validation is less rigorous? If so explain.

Session ID

What is the risk of a cache server starting/restarting with the same session
ID and serial number as before, but with different cache contents? Is this
an entropy concern? Just thinking of a potential scenario where a router is
cache-wedged. Is this at all probable? and why not - some words here to
cover this would be good.

Flags

Can you reword the binary choice here? Do you actually need to delve into
'right to announce'? This is really about RIB entry behaviors yeah?

Expand "IPvX".


Start or Restart:

I think the terms in when a router needs to send a serial query or a reset
query need to be tighter. Saying MAY here is too loose. I would much prefer
to see a structure where if the router does not have a recorded serial for a
cache from a previous session, the router MUST send a reset query. Logically
you assume that to be the case, so be specific.

Thereafter the router MAY send a reset query, and SHOULD send a serial
query. I suspect this is what the vendors (who have chimed in on the list)
have coded.

This then corroborates section 4 where you suggest the router only send
serial queries for efficiency.


Transport:

MiTM is Man in the middle as I and many others know it. 'Monkey/piggy/pickle
in the middle' is a child's ball game.

" Therefore, as of this document, there is no mandatory to
   implement transport which provides authentication and integrity
   protection."

if this is the case.. then why? what is the gain? why not then make the
router fetch the signed objects and do the validation internal - this again
seems to be the 'missing requirements' problem. And in such events - there
are a million solutions.

SSH Transport

State up front that you MUST use SSHv2. (instead hinting in the third
paragraph)

TLS Transport
"Man in The Middle (MiTM)" please.

Router Cache setup

"When a more preferred cache becomes available, if resources allow, it
   would be prudent for the client to start fetching from that cache."

How does the client (I assume router) know when to do this as cache's are
not synchronized?? How does a router tell if any particular cache has more
current data over another cache? what if two caches contradict each other?

Error codes

6: Withdrawal of Unknown Record (fatal), why drop the session? (which
presumably causes a restart) to a cache, assuming the cache is corrupt,
which will then send another Unknown Record, which is fatal... (repeat)??

Why not mark the cache as corrupt at the client?


Security Considerations:

Transport Security. There are multiple valid options for a root trust anchor
including the structure from the IAB aligning it to the IANA. Perhaps
instead of saying " the IANA root trust anchor" say "Global RPKI root trust
anchor". Otherwise you might accidently find your validated cache only
covers unallocated and reserved blocks.

Cheers
Terry