Tim: Congratulations! ☺
I think we’re in sync with everything else, just this last piece is outstanding. Thanks! Alvaro. On 1/9/17, 6:55 AM, "Tim Bruijnzeels" <[email protected]<mailto:[email protected]>> wrote: Let me try to make the point again – I didn’t do a good job above. In fact, reading this over I want to change it… In this document you’re saying: here’s a new protocol that SHOULD be used instead of rsync (3.4.1). And, as you mentioned above, the intent is to eventually phase out rsync in favor of RRDP. Time lines to phase it out are really out of the scope of this (or I think any other RFC) document because it is something the RPKI community agrees on and migrates to, just like any other new protocol. All that is good. However, both RFC6480 and RFC6481 mandate the use of rsync: “all publication points MUST be accessible via rsync” and “publication repository MUST be available using rsync”. Which means that to comply with the RPKI architecture rsync MUST be supported forever, regardless of whether RRDP is used, or a different protocol that may come along in the future…or even if it is not needed at all anymore (not even for eventual backup). ☹ The question about updating RFC6480 above should have been a statement: this document should update RFC6480/RFC6481 so that rsync is not required anymore. Changing the text in RFC6480/RFC6481 to say “MUST use RRDP” would just result in another update later if another protocol ever comes along, so I think this document should be explicit in the change (to allow the move away from rsync), but still generic…for example, the text in RFC6480/RFC6481 can be replaced with something like: “The publication point MUST be accessible using a retrieval mechanism consistent with the accessMethod element value(s). Multiple retrieval mechanisms can be supported at the repository operator’s discretion”. A change like that would require that this document be tagged to Update RFC6480/RFC6481 (and would of course return RFC6481 to be Normative). Ok, I understand. But I will need a bit of time for the text. (baby number two has his due date this Thursday so bear with me).
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
