Re: [sidr] Current document status && directionz

2016-09-08 Thread Heasley
Am 08.09.2016 um 00:42 schrieb Randy Bush : >> Or maybe there's pushback that says: "Hey, I hear what you all in the >> rir want, but it's not cool, please please let's dive back into the >> politics stream and see how we get movement on what we all (probably?) >> want: a single

Re: [sidr] WGLC for draft-ietf-sidr-origin-validation-signaling-04

2014-05-05 Thread heasley
Mon, May 05, 2014 at 07:03:46PM +0200, Randy Bush: And lets not forget: Running Code: Last but not least???the draft has been delayed more than what it should and several implementations (including two from Cisco) has running code + documentation + training. As we are pushing to improve

Re: [sidr] NotFound vs Uninitialized

2013-03-14 Thread heasley
Thu, Mar 14, 2013 at 02:02:13PM -0400, Montgomery, Douglas: Not an ops person - so take with a grain of salt - but imagine a world N years from now where I only accept routes that have VALID origins. All others routes are dropped. Imagine a net/power/nature event that both reboots my

Re: [sidr] ORIGINs

2013-03-11 Thread heasley
Mon, Mar 11, 2013 at 03:45:17PM -0700, Randy Bush: heas, Whether anyone likes it, it has become a TE knob of sorts, in a protocol with few such knobs, and many smaller transit providers rely upon it to affect route selection for non-malicious reasons, such as to balance their own

Re: [sidr] http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib-04

2012-12-04 Thread heasley
to go to WG and/or IESG or IETF list. On 12/4/12 5:15 PM, heasley wrote: rpkiRtrCacheServerPreference doesnt indicate which is more preferred, 0 or 255, but should imo. Since it is an Unsigned 32, I think that this text: A lower value means more preferred

Re: [sidr] additions and changes to agenda on Friday

2012-11-08 Thread heasley
Thu, Nov 08, 2012 at 11:25:44AM +, Murphy, Sandra: There are ISPs that spend considerable energy creating prefix filters from IRR data and strongly encourage their customers to register in IRRs. Those registers are maintained by an outside party that's outside the operator

Re: [sidr] additions and changes to agenda on Friday

2012-11-07 Thread heasley
Thu, Nov 08, 2012 at 03:27:02AM +, John Curran: no need. this is object based security. rama and hanuman have tals and validate. This would leave Rama and hanuman dependent on the CA services but not aware of the CPS term and conditions despite the explicit requirement specified

Re: [sidr] origin attribute

2012-10-24 Thread heasley
Wed, Oct 24, 2012 at 10:53:58AM -0600, Shane Amante: Danny, On Oct 24, 2012, at 9:11 AM, Danny McPherson da...@tcb.net wrote: On Oct 23, 2012, at 6:03 PM, Shane Amante wrote: I suspect John is referring to the operational practice employed by some networks, right now, whereby they

Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation

2012-05-24 Thread heasley
Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. understood; i'm registering/re-enforcing that if that is developed it must not be the only mathod.

Re: [sidr] [Idr] AS_SET depreciation (RFC6472) and BGP multipath

2012-03-28 Thread heasley
Wed, Mar 28, 2012 at 05:00:43PM +, Murphy, Sandra: Replacing ASs in the AS_PATH sounds like a behavior you would want the security protections to prohibit. It would enable attacks. Can you explain how you would distinguish legitimate uses of this feature? I've not used this feature,

Re: [sidr] BGP4 MIB module

2012-03-21 Thread heasley
Tue, Mar 20, 2012 at 04:28:15PM +0100, Bert Wijnen (IETF): So I had been in discussion with Jeff in order to see if we could get the BGP4-mibv2 module in good shape. Below is out discussion. Those who are interested in this MIB module at all may want to take a look to make sure they agree

Re: [sidr] rpki-rtr protocol maximum message length

2011-05-31 Thread john heasley
Tue, May 31, 2011 at 10:52:07AM -0700, Paul Hoffman: C or assembly-based implementations will need to malloc (etc.) the buffer for the incoming message. Having that fit into 256 octets could easily have some value to some implementations. that magic could just as easily be 64 or 512 octets