> However, the concerns I raised during WGLC in > http://www.ietf.org/mail-archive/web/sidr/current/msg05010.html > regarding the ambiguity of some of the guidance regarding location of > RPKI caches ("close") in section 3 still have not been addressed. IMO > if it is important enough to discuss proximity, it is important enough > to devote some words to explaining the rationale for that > recommendation so that operators can make an informed design decision. hey, thanks for caring and reviewing i think the two paragraphs you would like to see improved are As RPKI-based origin validation relies on the availability of RPKI data, operators SHOULD locate caches close to routers that require these data and services. 'Close' is, of course, complex. One should consider trust boundaries, routing bootstrap reachability, latency, etc. If insecure transports are used between an operator's cache and their router(s), the Transport Security recommendations in [RFC6810] SHOULD be followed. In particular, operators MUST NOT use insecure transports between their routers and RPKI caches located in other Autonomous Systems. i am not against further explanation, send text. but short text. :) experiments have shown that latency between cache and router, and between caches in a cache dag, is not an appreciable issue. as the reports of these experiments are not peer reviewed, it is not clear that they are good to reference. one has been accepted at conext, but page count limit prevented the latency issue from being included :( i thought bootstrap reachability would be fairly obvious to an operator. but if simple routing and no dns dependency were not obvious to you, then a few words are indeed needed. or am i missing your point here? as the rpki-rtr protocol is beyond the border of object-based security, the operator only has transport security between the cache(s) and the router. it would probably be good to add this as it motivates the "close" and "trust boundary" cautions. what is missing from the second paragraph? section 7 of rfc6810, as referenced, was very heavily reviewed and pretty much bludgeons this one to death. of course if you have specific ideas for improvement, that'd be great. > "ok, we're going to stick it in a VM on our two national data center > compute infrastructures like the rest of our servers, we can spin up > more instances if you need to scale it" > "but RFC mumble mumble says that we shouldn't do that..." > "ok, why? And where do you want to put it?" > "ummm... 'close' to the routers? Because...reasons" i am not sure it would be useful to go into the general issue of why caches should be proximal to the consumer as it is a rather well- explored area, from akamia and limelight to dns. but if you have a sentence or two that communicates this, send it over. randy