On Jan 10, 2012, at 9:30 PM, Randy Bush wrote:
> with a little work, i can usually understand geoff's. the above seems
> to spend all of it's power budget on trying to appear erudite, and the
> result is quite unintelligible to at least this st00pid geek.
Erudite is a fine choice of words here, I was hoping it'd
lead to corrections from those more learned. I ask that
you please indulge me Randy, I suspect you've already
got this all figured out.
Let me ask a couple questions, that may help me resolve
my confusions with this.
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:
[snip]
5. Processing a Received BGPSEC Update
Validation of a BGPSEC update messages makes use of data from RPKI
certificates and signed Route Origination Authorizations (ROA). In
particular, to validate update messages containing the
BGPSEC_Path_Signatures attribute, it is necessary that the recipient
have access to the following data obtained from valid RPKI
certificates and ROAs:
o For each valid RPKI end-entity certificate containing an AS Number
extension, the AS Number, Public Key and Subject Key Identifier
are required
o For each valid ROA, the AS Number and the list of IP address
prefixes
[/snip]
I labeled these things prospectively [more] volatile than current
rpki-rtr "stuff", that may or may not be appropriate.
If this is the intention, then have you selected the publication
dates for the documents that "augment" this brand new rpki-rtr
protocol, I'd like to know when I need to factor those documents
as well?
A general observation is that while this piecemeal draft
progression approach appears well designed to pass IETF
publication gates, I'm not sure it's optimal for considering
systemic and inter-dependency implications.
Alas...
> but i think danny is happy with the changes. and if danny is happy, i
> guess i am.
Excellent...
-danny
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
