Subject: [sidr] Interim Meeting Dates/Locations (Proposed)

From: Christopher Morrow <[email-masked]>
Date: Mon, 26 Mar 2012 10:43:33 -0400

So, as stated in the meeting today, and in these slides:
  <http://www.ietf.org/proceedings/83/slides/slides-83-sidr-8.pdf>

There is a proposal to schedule 5 future Interim Face to Face
(+virtual) meetings. The dates/locations are:

Mon Apr 30 - after ARIN (IAD)
Wed Jun 6 - NANOG (YVR)
Fri Jun 29 - (BWI/IAD)
Fri Jul 27 - prior to IETF84 (YVR)
Sun Sep 23 - prior to RIPE (AMS)

The hope is that:
  1) WG folks interested in the forward progress of the WG work can
attend (either physically or virtually)
  2) WG folk interested see this number of meetings (about 1/month for
the next 6 months) as appropriate
  3) the overlap/adjacency with existing operations meetings will help
travel problems AND bring in some ops focus/requirements as well to
the work.

Please have a discussion on the applicability of the meetings (number
and attendance capabilities) and let's close that discussion out ~Mar
29, 2012 23:59 Paris Local Time (CEST?).

-Chris
<co-chair>
(Note: the deadline is to avoid scheduling/process deadlines in
getting the first meeting note out via IETF/IESG-secretary)

---

From: Randy Bush <[email-masked]>
Date: Mon, 26 Mar 2012 16:45:27 +0200

> Sun Sep 23 - prior to RIPE (AMS)

i will try to attend in person

randy

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 26 Mar 2012 11:14:50 -0400 (EDT)

I am content to have interim meetings iff the WG commits to improving 
the technical facilities for remote participants.  That was fumbled 
badly at the San Diego interim meeting and moderately badly today. 
We need to do better.

To encourage us to do better, I suggest that the first of these 
interims (on whatever date; see below) be virtual-only.  If we 
continue to have technical foibles, I suggest that the remaining 
interims be cancelled entirely.

> Fri Jul 27 - prior to IETF84 (YVR)

Neither of these Fridays work for me (June 29th at all, July 27th in 
person) due to prior commitments, and the Monday is dicey.  My general 
preference would be to have these meetings midweek (Tues/Wed/Thurs), 
thereby avoiding weekend-impinging travel.

> Wed Jun 6 - NANOG (YVR)

But that's World IPv6 Launch Day!  (No real objection.)

---

From: Arturo Servin <[email-masked]>
Date: Mon, 26 Mar 2012 18:03:36 +0200

I think that you silently discarded my email:

	http://www.ietf.org/mail-archive/web/sidr/current/msg04215.html

	Anyhow I wasn't expecting too much, but I least I tried.

Regards,
.as

On 26 Mar 2012, at 16:43, Christopher Morrow wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 26 Mar 2012 12:13:58 -0400

> I think that you silently discarded my email:

I didn't, I may not have read it ;(

> Anyhow I wasn't expecting too much, but I least I tried.

The October date may work out... would be good to discuss that though
after this set is settled/scheduled.

-chris

---

From: Arturo Servin <[email-masked]>
Date: Mon, 26 Mar 2012 18:27:37 +0200

No worries.

Thanks,
.as

---

From: Sean Turner <[email-masked]>
Date: Mon, 26 Mar 2012 18:45:43 +0200

On #3, I really like the idea of having interim meetings close to events 
that are essentially operator-centric meetings.  If this WG is in fact 
going to have protocols/boxes deployed/run by operator folk, it'd be 
really good to make it easy as possible for them to attend.  I know some 
attend the IETF, but it always good to be as inclusive as possible.

On #2, (I'll state the obvious) once a month meetings could be 
appropriate; however, the agendas will need to be posted early enough 
for folks to determine whether they want to go in person or be remote.

As to the meeting date (and assuming the agendas are out early):

Can attend remotely or in person.

> Mon Apr 30 - after ARIN (IAD)

I work to try to attend in person, but could definitely do it remotely.

> Wed Jun 6 - NANOG (YVR)

Can attend remotely or in person.

> Fri Jun 29 - (BWI/IAD)

Can attend remotely or in person.

> Fri Jul 27 - prior to IETF84 (YVR)

Not sure I can make this one in person, but could definitely do it remotely.

> Sun Sep 23 - prior to RIPE (AMS)

spt

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 27 Mar 2012 08:32:48 +0000

Moderate badness in the Monday meeting was due to my laptop communication problems.  Suggestions welcome as how to handle such a situation better.  Pkt loss for me varied 0-33-50-100%.  Help desk and NOC were unable to diagnose.  

On hotel wireless, I see congestion (judged by ping latencies) and slowness from time to time, but nothing as debilitating as in the conference center.  It was not only in the room, it was everywhere.  More diagnosis attempts with help desk today, else I will have to find alternate platform for Wed meeting.

Chris and I have equal access to meeting materials, webex codes, etc. so we have backup in case one laptop fails.  Which was the only way we were able to progress this time.

I should have printed everything.  People snicker at those who carry paper, but paper doesn't have pkt loss, or congestion, or blue screen, etc.

--Sandy

________________________________________
From: [email-masked] [[email-masked]] on behalf of Samuel Weiler [[email-masked]]
Sent: Monday, March 26, 2012 11:14 AM
To: Christopher Morrow
Cc: [email-masked]; [email-masked]
Subject: Re: [sidr] Interim Meeting Dates/Locations (Proposed)

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 27 Mar 2012 10:45:18 +0200

> Mon Apr 30 - after ARIN (IAD)

Can not attend.

> Fri Jun 29 - (BWI/IAD)

Can attend remotely depending on agenda.

> Sun Sep 23 - prior to RIPE (AMS)

Can attend in person.

> 29, 2012 23:59 Paris Local Time (CEST?).

As I stated before I prefer to have the extra time during, or next to, an IETF -- I already planned to attend those. So the extra meeting in Vancouver works for me. I understand that a higher frequency is good for momentum but extra travel is not possible for me and remote attendance is not ideal.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 27 Mar 2012 05:08:52 -0400

> As I stated before I prefer to have the extra time during, or next to, an IETF -- I already planned to attend those. So the extra meeting in Vancouver works for me. I understand that a higher frequ…

summarizing a constant thrum....
"Yes, not everyone can make every interim proposed. Yes not everyone
can make the virtual version of same. That is ok..."

Thanks for the info though!
-chris
<co-chair>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Mar 2012 06:23:36 -0400

>Mon Apr 30 - after ARIN (IAD)

can't make it

>Wed Jun 6 - NANOG (YVR)

ditto

>Fri Jun 29 - (BWI/IAD)

possible

>Fri Jul 27 - prior to IETF84 (YVR)

I'll be there.

>Sun Sep 23 - prior to RIPE (AMS)

I can try to be there.

Adjacent to IETF is always viable for me.  NANOG and ARIN meetings not
likely. RIPE meetings maybe.

Steve

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 27 Mar 2012 08:13:14 -0400

I support the idea of rapid progress through frequent interim meetings. 
However, in order to make this work, we really need to make virtual 
participation more successful than we did at the May meeting in San Diego.

> Sun Sep 23 - prior to RIPE (AMS)
I can make all of these meetings virtually. I will attempt to make the 
meetings in person.

- Matt Lepinski

---

From: Terry Manderson <[email-masked]>
Date: Tue, 27 Mar 2012 13:22:08 -0700

> 29, 2012 23:59 Paris Local Time (CEST?).

I feel like the Monday meeting was a bit of a lost opportunity. I appreciate
that the presenters made effort in presenting, and making slides and
presenting ideas. However I feel like the "RPKI over Bittorrent" really
needed focused discussion on what the problem is, and a resulting definition
of what RPKI needs in a requirements spec to address the problems that were
alluded (and BTW I am more than happy to help form that set of
requirements). Equally I appreciate the time taken in predicting the signing
impact on router CPU, but without some more concrete lab work I felt a
little lost as being able to take anything away from it at this stage.

So I'm not intending to enter into a discussion on those topics here (but
will commit to posting on both those items on list), but for me I think this
speaks to the applicability of the interim meetings, so I humbly ask the
chairs to keep the agenda tightly focused. The reason is that I have every
intention of attending these meetings virtually, and will further try to
make it in person (budget pending) - but for both of these to get most
value, I would appreciate that it syncs up with documents in play.

Cheers
Terry

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 27 Mar 2012 17:52:42 -0400 (EDT)

On Tue, 27 Mar 2012, Murphy, Sandra wrote:

> Moderate badness in the Monday meeting was due to my laptop 
> communication problems.  Suggestions welcome as how to handle such a 
> situation better.

Thank you for asking.

1) First and foremost, delegate the tech issues to two or more persons 
who do not have responsibilities to chair, present, scribe, or jabber 
scribe.  Ideally, find people who are unlikely to be active 
participants in the meeting.  It's fine to bring in outside help.

2) Have spares for all key hardware.  This includes laptops, audio 
gear, network gear, network connections, and phone connections. 
Cables and power supplies need spares, also -- a dead power supply can 
mean a dead laptop.  Based on experience in San Diego I suggest having 
at least three pieces of all key gear.  Have fallbacks in case a 
service provider fails: if you're planning to use Meetecho, ALSO have 
a WebEx session and a PSTN bridge set up and ready to go.

3) Test both primary and spare hardware and service providers in 
multiple combinations prior to the meeting.  The more testing you do, 
the more you can get away with only a single spare.  Testing needs to 
happen in the real meeting environment using the same phone lines, net 
connections, and audio hardware that will be available during the 
meeting.  The more removed your testing environment is from the real 
meeting environment, the more you need that second spare.

4) When a relatively large number of participants will be in a single 
space, provide high-quality microphones.  The average Polycom 
microphone still sounds like a speakerphone, and listening to people 
talking through one all day gives remote participants a clearly 
second-class experience.  If possible, give every participant his own 
microphone (with mute switch!).  At the very least, provide a floor or 
wireless handheld microphone as we have at the regular IETF meetings 
and make sure people use it.

Yes, this is a lot to do.  Yes, I'm saying to have three net 
connections[1].  Remember, you're not doing this yourself (at least, 
not if you're following suggestion #1).  In fact, no one person is 
stuck with all of this.  And "spares" don't have to be 
sitting-in-a-box-and-hauled-around-the-world-the-to-be-a-spare: they 
can be a meeting participant's personal power brick, so long as you're 
sure there's going to be that spare in the room and the person is 
willing to part with it should the need arise.

-- Sam

[1] This is based on the San Diego experience where the hotel net 
connection was terrible and the backup net was a 4G hotspot.  While 
both could move some packets, they were not enough to handle both 
remote participation and the normal packet-pushing desires of those in 
the room.  A 3G or 4G device could easily be the backup net, so long 
as 1) there is actually service in the meeting space and 2) the device 
gives priority to the remote participation traffic and avoids getting 
bogged down by routine email checking and web browsing.

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 27 Mar 2012 18:05:36 -0400

On a related note:

At some point we could also try a virtual (remote-only) interim meeting. 
I realize that there is value in having a critical mass of people in one 
room interacting directly. However, in cases where there is not a 
co-located event that is likely to draw a critical mass of people, 
perhaps a virtual interim makes sense.

Note: I have been involved in other working groups that have 
successfully pulled off virtual interims (so there are worked examples 
of this happening successfully). Also, most of the problems in San Diego 
were in trying to combine a large number of physical participants with a 
large number of remote participants, so it is possible that a completely 
virtual interim would run into fewer potential stumbling blocks.

Just my 2 cents,
- Matt Lepinski

On 3/27/2012 5:52 PM, Samuel Weiler wrote:
> gear, network gear, network connections, and phone connections. Cables 
> and power supplies need spares, also -- a dead power supply can mean a 
> dead laptop.  Based on experience in San Diego I suggest having at 
> least three pieces of all key gear.  Have fallbacks in case a service 
> provider fails: if you're planning to use Meetecho, ALSO have a WebEx 
> session and a PSTN bridge set up and ready to go.
>

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 27 Mar 2012 18:20:26 -0400

Terry,

On 3/27/2012 4:22 PM, Terry Manderson wrote:
> requirements).

I see your point here. However, I am personally very grateful to Rob for 
his BitTorrent experiment. I believe that the choke point of the global 
RIR repositories is a vital challenge in RPKI deployment. I think the 
working group would benefit from spending significant bandwidth thinking 
about this challenge and I see Rob's presentation as a very reasonable 
way to get the ball rolling.

That is, this particular topic has been completely dormant on the 
mailing list in the past months. Therefore, doing any kind of concrete 
experiment and presenting it to the working group as a possible approach 
for getting around the global-repository choke-point seems like a 
valuable way to spur work/discussion on this topic.

- Matt Lepinski

---

From: Terry Manderson <[email-masked]>
Date: Tue, 27 Mar 2012 23:22:30 -0700

Hi Matt,

On 28/03/12 8:20 AM, "Matt Lepinski" <[email-masked]> wrote:
> RIR repositories is a vital challenge in RPKI deployment.

Excellent - so we have a defined, and succinct problem statement.
"The choke point of the global RIR repositories is a vital challenge in RPKI
deployment."

> I think the

It's a thought process. And I don't mind seeing the idea thrown "out there"
with a speculative solution. My comments were in parallel with the time /
form / agenda of the proposed interim meetings, and the idea that some
(many?) will be churning additional resources from their own companies to
participate and in that participate remotely with all the obvious foibles
that brings.

> That is, this particular topic has been completely dormant on the

Sorry, has this been previously raised on the ML? I couldn't find anything
in a quick scan of the archives. Do you have a pointer?

> valuable way to spur work/discussion on this topic.

I appreciate experimentation as a valuable precursor to discussion, but more
than anything I would love to see some requirements fleshed out in working
group form first.

Cheers
Terry

---

From: Matt Lepinski <[email-masked]>
Date: Wed, 28 Mar 2012 02:59:36 -0400

Terry,

> in a quick scan of the archives. Do you have a pointer?

My apologies. When I wrote my message, I had thought that this came up 
on the list briefly during spring of 2011 during the (first?) WGLC of 
the repository-structure document. However, at the moment, I can't find 
the message reference at the moment, so it is quite possible that I am 
mis-remembering.

- Matt Lepinski

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Mar 2012 04:05:05 -0400

>> I feel like the Monday meeting was a bit of a lost opportunity. I

see previous gzip compression message :( I think we tried to stuff
8hrs of content into ~2hrs.
I think we ought to revisit the content at the next opportunity, which
is probably ~4/30/2012-ish.

> I see your point here. However, I am personally very grateful to Rob for his
> BitTorrent experiment. I believe that the choke point of the global RIR

i'd like to see a conversation about how this method worked/s and what
impacts other transport mechanisms may have on the distribution of the
data we care about. I think there's room for alternates, the
bittorrent experiment seems to show that... so do comments at the mic
by martin levy and others.

> repositories is a vital challenge in RPKI deployment. I think the working
> group would benefit from spending significant bandwidth thinking about this
> challenge and I see Rob's presentation as a very reasonable way to get the
> ball rolling.

sure. probably also writing down the 'what are we trying to solve'
with this distribution system would be good to document (terry's call
for requirements).

-chris

---

From: Terry Manderson <[email-masked]>
Date: Wed, 28 Mar 2012 01:09:37 -0700

> with this distribution system would be good to document (terry's call

Happy to start documenting such if people want to throw their _requirements_
at me. naturally I have my own. But I am but one lens of the issue.

Cheers
Terry

---

From: Arturo Servin <[email-masked]>
Date: Wed, 28 Mar 2012 10:12:42 +0200

We operate a repository and we are using the others repositories for our origin-validation tool. So, I would be happy to help documenting our experience and some ideas to improve.

Regards,
as

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 28 Mar 2012 04:15:18 -0400

> can make the virtual version of same. That is ok..."

being slightly less flip (I didn't actually mean to be flip):
The 2 questions here are:
  1) are more meetings required/helpful
  2) would having these coincident with existing events and ~1/month
be acceptable to the majority

we (everyone involved) do know that not everyone can make every
meeting... aiming for best participation level is the goal.

-chris

---

From: Tim Bruijnzeels <[email-masked]>
Date: Wed, 28 Mar 2012 11:09:47 +0200

fyi..

The validator implementers have also discussed some of the common problems that we see now, and other ways to distribute the rpki data over the past days. We have some more thoughts on this, but I am not sure that we agree yet. I would like to talk between us a tiny bit more to avoid mistakes that would make it impossible, and sending an idea to this list that is shot down immediately and wasting everyone's time ;)

Tim

>> at me. naturally I have my own. But I am but one lens of the issue.

Tim Bruijnzeels
Senior Software Engineer
RIPE NCC

e: [email-masked]
p: +31 20 5354309

---

From: "George, Wes" <[email-masked]>
Date: Wed, 28 Mar 2012 09:52:04 -0400

> meeting... aiming for best participation level is the goal.

[WEG] Avoiding some number of messages saying "can't/can attend x, y, z" is exactly why I requested that the chairs use a doodle poll or similar to gather that feedback (a bit more quietly), especially when there is more than one alternative for a date (before vs after an event, for example). You're asking for feedback, which is good, but you've still pre-set the dates, which really isn't aiming for best participation level. It's simply giving people an opportunity to throw rocks, and hope that enough people throw rocks of the same shape to change the schedule as necessary.

For example, although it means I have to give up more weekend for travel, I'd rather see us go on the front side of NANOG. I am unlikely to be able to do anything not World V6 launch related on June 6, and I'd bet I'm not the only one.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.