>>> -4, first paragraph: I found "either" followed by "and/or" a bit >>> confusing. I suggest simply dropping the word "either". >> >> As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers >> are either capable of generating their own public/private >> key-pairs and having their certificates signed and published in >> the RPKI by the RPKI CA system, and/or are given public/private >> key-pairs by the operator. >> >> but the router(s) might not be capable of generating key-pairs. they >> might, they might not, the op may generate or not, or both. an >> absurd corner case might be that a router with two ASs has the as0 >> key stuffed by the as0 noc, and the as1 key is generated on device >> because that is the as1 policy. > > I merely meant that "either" seemed odd for non-exclusive options. I > take your argument to mean that the options really are non-exclusive.
ok, i will drop the either. >>> -4, last paragraph: "a prudent operator will..." sounds like it >>> might be worthy of a SHOULD. >> >> given the previous, how about lower case should > > That would not seem to change anything :-) My point was that the > language seemed stated in a way that _might_ justify a 2119 > keyword. ok, upcased SHOULD >>> -7, paragraph 6: This seems to say that signed paths MUST be >>> signed. Does the "MUST be signed if sent to external BGP speakers" >>> mean that the existing signature must not be stripped (as stated >>> more weakly in the previous sentence), or does it mean the sender >>> must re-sign the path? >> >> Because of possible RPKI version skew, an AS Path which does not >> validate at router R0 might validate at R1. Therefore, signed >> paths that are Not Valid and yet propagated (because they are >> chosen as best path) should have their signatures left intact and >> MUST be signed if sent to external BGPsec speakers. >> >> i am not seeing where bgpsec stripping was suggested; in fact, the >> opposite. if router r0 receives a signed path and intends to pass >> that signed path to the next listener, r0 must sign the path. i am >> at a loss to understand your question. clue bat please. > > Sorry, I did not mean that stripping was suggested; the previous > phrase (non-normatively) recommends against stripping. My question is, > since the subject of the sentence is "signed paths" whether the "MUST > be signed" language means "MUST NOT strip the signature" (which I > suspect to be the case), or something else. how about As the mildly stochastic timing of RPKI propagation may cause version skew across routers, an AS Path which does not validate at router R0 might validate at R1. Therefore, signed paths that are Not Valid and yet propagated (because they are chosen as best path) MUST NOT have signatures stripped and MUST be signed if sent to external BGPsec speakers. if not, use larger clue bat > As I mentioned in response to Alvaro's comment: Maybe section 2 should > cite the protocol rather than the overview? done randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
