Registry Working Group

[William T Johnson <>]

Echoing these statements, I’m primarily interested in how best to use IRR.  
I, like Bill, have survived mostly on the bare essentials, though perhaps a 
bit brooding in insuring all downstream members are accounted for in the 
probability Google or Cloudflare follow though.  I take a strict view of 
responsibility to insure my RON guarantees prefix acceptance.

Tom

-=-=-=-=-=-=-=-=-=-=-=-=-=-
William (Tom) Johnson
I-Light and Indiana Gigapop

-=-=-=-=-=-=-=-=-=-=-=-=-=-



> On Jan 8, 2019, at 4:06 PM, Alan Whinery 
> <>
>  wrote:
> 
> I think that responses may have gotten waylaid by the holidays, to some 
> extent.
> 
> I'm glad to have out-waited Bill, because letting him talk first usually 
> saves me a lot of trouble.
> 
> What I'd like to see is a concise BCP reference for someone newly 
> encountering the whole IRR, MANRS, etc. stuff that we've all been meaning 
> to catch up on, in place. I don't know if that's a working group, or a 
> project, I'm guessing it's a working group, because one would need 
> revisions. If we can point at a university-focused (and lab focused and RON 
> focused) reference, mission accomplished. But unlike the typical working 
> group, there should be a tangible, organized reference doc. Page one should 
> be organized to initiate someone who has not yet acclimated in the echo 
> chamber.
> 
> On 1/8/2019 10:19 AM, Bill Owens wrote:
> 
>> Replying to your original email to make things simpler but acknowledging 
>> it was your reminder just now that got me to do it...
>> 
>> > On 12/14/18, 3:34 PM, 
>> "
>>  on behalf of Michael H Lambert" 
>> <
>>  on behalf of 
>> >
>>  wrote:
>>>     All,
>>>          In a fit of non-lucidity I told Dale I would be willing to chair 
>>> the IRR working group.  I've been remiss in sending out an initial 
>>> message, but here goes.
>>>          I'll throw out some discussion points for possible directions 
>>> for the group.  I figure we can schedule a call for sometime in early 
>>> January to provide some focus to what I'm sure will show up on > this 
>>> list.  I expect a lot of this to mesh nicely with points on Grover's 
>>> agenda for the Global Summit MANRS workshop.
>>>          o Motivation for using IRR.  Potential loss of peering with 
>>> Google and Cloudflare is significant, but that isn't the only reason.
>>     Honestly, for me the threat of losing connections to Google *is* the 
>> only reason. I didn't know Cloudflare was potentially in the mix as well, 
>> but they're important too. I've managed to survive this long without any 
>> serious use of IRR and I don't see any advantages to it; the records I 
>> have are because they're what my ISPs require me to have. I make no use of 
>> them.
>> 
>>>     o How-Tos for various aspects of IRR.  Working with registries, 
>>> tools, etc.
>>     YES. I don't know what I'm doing with IRR, and the documentation I've 
>> found is all about how it could be used, not how it is used. I want the 
>> absolute minimum configuration that will let me keep 
>> Google/Cloudflare/whoever happy. If there's additional configuration that 
>> keeps us in good standing with the MANRS world, that's fine too.
>> 
>>>     o Perhaps this would culminate with a white paper on best practices.
>>>          Is concluding the group by the end of June realistic?  It's not 
>>> supposed to be long-lived.
>>     I just looked at the Google peering portal and don't see anything 
>> about IRR, or any complaints about my lack of a coherent IRR 
>> configuration. Apparently the January 1 deadline, wasn't. I'm glad, since 
>> doing actual work on the network has been keeping us plenty busy without 
>> adding make-work, but I do wonder that we haven't heard anything more from 
>> Google about this.
>> 
>> Bill.
>>

Attachment: smime.p7s
Description: S/MIME cryptographic signature