Thanks for the quick response.
On 3 Jan 2017, at 20:00, Randy Bush wrote:
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.
I plan to mention that when I write up my reviews of the other two :-)
I agree with the lower case exclusion. I merely thought the working
group might want to be consistent on the cluster of drafts. (Assuming
they are really a cluster--I could see an argument that the protocol and
overview drafts are for a separate audience than the bgp.)
[...]
-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.
-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. If
you don't think so, then I'm fine with the current wording.
-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.
That's much more clear, thanks.
[...]
-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.
-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.
Yes, sorry.
-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.
As I mentioned in response to Alvaro's comment: Maybe section 2 should
cite the protocol rather than the overview? (Perhaps with a separate
mention that the overview is available.)
Ben.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
