Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.txt

[Randy Bush <[e-mail]>]

> 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