Re: [sidr] Mirja Kühlewind's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush <[e-mail]>]

>> ok, i have had coffee.
>> 
>> as a bif gedanken experiment, posit a global registry where r0 can say
>> "i can speak bgpsec."  i am a distant r1 and receive an unsigned path
>> with r0 in it.
>>   o did someone before r0 on the path not speak bgpsec, so the path was
>>     never signed?
>>   o did someone between us not speak bgpsec, so the path was stripped?
>>   o was there a monkey in the middle?
>> 
>> i think we did discuss this problem space, and decided that, as long as
>> we allow islands of partial deployment, and therefore path stripping,
>> the monkey is on our back.  we might have been wrong in this; but even
>> with coffee i do not see a way out.
>> 
>> and i do not think the idea of partial path signing, r0 signing a
>> received unsigned path, would have helped a lot.
>> 
>> it is not clear to me that this is a space where the ops doc can help
>> much.  i am open to ideas.
> 
> I'm currently not using bgpsec (or rpki for that matter).  BUT, if there
> was no path to go back, I would never ever use it.  Destroying my ASN
> because I wasn't ready to migrate is a straight-up No Go(tm).
> 
> Mistakes will be made.  Rolling back will happen.  Preventing rolling
> back will kill the baby and will guarentee this will never be rolled
> out.

what do you mean by "no path to go back" and "rolling back?"

where do you see "destroying" your AS?

my only guess is that
  o you have not read the spec or any documentation on it, and
  o you triggered on the phrase "path stripping"

fwiw, path stripping is removing the bgpsec gorp from a bgpsec path and
rendering a classic bgp4 path to hand to a bgp listener who does not
understand bgpsec.  no ASs are harmed in the process.

randy