Re: [sidr] Ben Campbell's No Objection on draft-ietf-sidr-bgpsec-ops-12: (with COMMENT)

[Randy Bush <[e-mail]>]

thanks for the review.

> Update: I noted when reviewing other sidr drafts on this telechat
> agenda that this draft treats 2119 keywords differently than the other
> drafts.  That is, this draft explicitly excludes lower case versions
> of the 2119 keywords

which is, i believe, the current wisdom; see long discussion on ietf
list.

> while the other related drafts do not.

have fun with that. :)

> -1, first paragraph: "It is thought...": Can you mention "who" thinks
> -it?

phrase removed

> -1, third paragraph: Please consider writing out "also known as"

rich got that

> -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.

> -4, 2nd paragraph: The MAY seems like a statement of fact. Is it intended
> to offer permission, or describe reality? (The latter should not use a
> 2119 keyword.)

sure

> -4, last paragraph: "a prudent operator will..." sounds like it might be
> worthy of a SHOULD.

given the previous, how about lower case should

> -6, first paragraph: "SHOULD/MUST only" constructions tend to be
> ambiguous. In this case, are we saying SHOULD only originated signed
> announcements, as opposed to unsigned announcements? Or as opposed to
> validating received assignments? If the latter, then the "need not
> validate" seems to weaken the SHOULD.

   An edge site which does not provide transit and trusts its
   upstream(s) may only originate a signed prefix announcement and not
   validate received announcements.

> -6, last paragraph: Can something be cited for the 84% assertion?

easier to remove it.  actually, i thought i had done so already; which
causes me to worry if i lost other edits.

> -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.

> -7, paragraph 7: "a signed path learned via iBGP MAY be Not Valid."
> seems like a statement of fact.

are you suggesting to downcase it?  i will assume so.

> -12.2: [I-D.ietf.sider.bgpsec.overview] is mentioned in section 2 as
> needed to understand this document. That suggests it should be a
> normative reference. 

ennie meenie.  i think some other reviewer had me push refs around.  i
don't have a dog in this fight.  my personal opinion would be that
overview is informative and the protocol spec itself is normative.

again, thanks.

randy