John Scudder asked the following question in an email to the
authors of draft-ietf-sidr-bgpsec-protocol:
From: John G. Scudder j...@juniper.net
Date: Wed, Apr 18, 2012 at 8:00 PM
Subject: bgpsec-spec S. 4.2 comments
A few misc questions/comments I noticed while perusing S. 4.2:
A BGPSEC
that's also flawed.
You should be able to sign anything that you can.
Suppose you receive it from an ibgp peer that sourced it but didn't sign it.
--
Jakob Heitz.
On May 2, 2012, at 7:21 AM, Sriram, Kotikalapudi
kotikalapudi.sri...@nist.gov wrote:
John Scudder asked the following question
that's also flawed.
You should be able to sign anything that you can.
Suppose you receive it from an ibgp peer that sourced it but didn't sign it.
--
Jakob Heitz.
What a BGPSEC router does when originating a new BGPSEC update
is covered in Section 4.1. You are right -- the router can receive
a
The discussion here (and John's comment) is related to text in Section
4.2, where we discuss what a BGPSEC router does when propagating a
route advertisement. Propagating connotes here that the update (or
route) was received from an eBGP peer.
not exactly. 4.0 says
Sections 4.1 and 4.2
Howdy,
for the folks that attended in person, and remotely I think we (chairs)
would like to get some feedback on how the meeting was done. I think we
know of a few stumbling blocks:
1) late start/technology fail with the webex (probably webex
operations failures more than anything - my
