> Do you foresee rpki-rtr being "augmented" for router on- boarding of > additional RPKI-derived data to enable things like those provided in > the BGPSEC protocol document, e.g., S.5 of bgpsec-protocol I-D:
i think so, but i am a bit worried as about this waterboarding stuff. > If this is the intention, then have you selected the publication > dates for the documents that "augment" this brand new rpki-rtr > protocol i think the norm is to get some experience with v0 (the protocol version number in the pdus, a la bgp_4_) before going to v1. but, as with most things, i could be wrong. > I'd like to know when I need to factor those documents as well? as i have no idea how to factor a document or how much lead time factoring takes, even if i knew when v1 could be out which i don't, i would not be able to answer. > A general observation is that while this piecemeal draft progression > approach appears well designed to pass IETF publication gates perhaps a focus on engineering, as opposed to mis-guessing and impugning others' motives, would be productive. in the current taxonomy, there are three pieces, the rpki, rpki-based origin validation, and then path validation. rpki-rtr as it stands is part of origin validation, and the docs for origin validation are going through the sausage machine now. path validation is in early to mid design, documents are in high flux or unwritten, and are nowhere near ready to be considered sausage. the semantics of an rpki-rtr pdu needed to support the most recent path validation drafts are obvious. but, as principal author of rpki-rtr, i am already grossly and embarrassingly behind on revisions of at least three other docs (two for origin validation!!), origin-ops, pfx-validate, and bgpsec-reqs. so i have no time to chase document drift in the very drafty path validation specs even if it was appropriate to do so, which imiho it is not. they're drifty enough that an interim is being held just to discuss one tough aspect and see if a very different conceptual area can be understood well enough to be added to the goals. and getting v0 of rpki-rtr through the sausage machine already has consumed a silly amount of wall clock, tyvm. randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
