IETF 102 Plenary

Alissa Cooper: So as people are walking in here just if you don't 
know what that video was that was playing. Before this meeting I 
wrote a blog post which I shared with the IESG and the IAB in advance 
(of the meeting) for comment and it was titled Something for Everyone 
at IETF 102 and it had a little bit of a humorous flair to it and 
Allison actually asked oh is that is that a reference to "Comedy 
Tonight" because the whole idea was that it was it was trying to the 
blog post was trying to be funny and I had never heard of "Comedy 
Tonight." So, we went and dug up a video and it's a song from a 
musical from the 1960s "A Funny Thing Happened on the Way to the 
Forum" by Stephen Sondheim.

Alissa: Thank you for crowdsourcing this. But the lyrics are so on 
point "Something familiar, something peculiar, something for 
everyone, a comedy tonight!" Welcome to the IETF 102 Plenary.

[Applause]

Alissa: Hi everyone, I'm Alissa Cooper, and I'm the IETF Chair. It's 
lovely to be here with all of you in Montreal, the world home of 
circus. Also somewhat on point for the IETF, and hopefully not for 
the plenary, but for the IETF as a whole. People might not remember 
this but this particular meeting was originally scheduled to be next 
week in San Francisco. We ended up changing it due to some concerns 
about visa issues and immigration issues in the United States we 
decided to move it to Montreal and in order to do that we had to 
change the dates. We had to move it back to this week. I think what 
people really don't realize though is the incredible foresight of the 
IETF Administrative Oversight Committee in making that switch because 
what that meant was that in addition to us having our working meeting 
here this week we would coincide with two very important world 
events, those being the World Cup and World Emoji Day. 

Alissa: So not only did we get to get our work done, but we also got 
to watch the games and celebrate the emojis. Congratulations to 
France, of course. Something else new at this meeting; people might 
have noticed that there's there have been Chromebooks on the tables 
for the working group chairs at the front of every session. When we 
first talked about getting these added, there was a little bit of 
concern about whether there would be enough space on the tables that 
remained for the working group chairs to still manage the meetings. 
You have the blue sheets, and there's all kinds of stuff up there but 
it seems that that wasn't necessarily a problem. In particular, some 
of the working group chairs were quite inspired by this and brought a 
whole family of laptops so that the Chromebook wouldn't be lonely. 
This particular case let's see five devices sitting there on the 
table. Big thanks to the Secretariat for providing those. I think I 
think that's been a well-received change.

Alissa: So getting on with our agenda, we'll first thank our hosts 
briefly and then we'll have updates on hot topics from all of our 
different constituencies, so I'll give an IETF chairs update, Ted 
will talk about the IAB or maybe not, I can't we crossed you out, 
you're coming on later. Allison will speak briefly about the IRTF. We 
will have administrative hot topics and then we'll hear from the 
NomCom chair. 

Alissa: We'll have a section in memoriam we'll do some recognition I 
will have the Jonathan B. Postel Award from Kathy Brown and there's 
no technical plenary tonight. So then we'll go straight into the open 
mic sessions. So first an extremely importantly a huge thanks to our 
host of this meeting, Juniper. 

Alissa: Juniper is one of our global hosts which means they've made a 
multi-year commitment to support the IETF. They will host three 
meetings over the span of nine years, a support that we really can't 
function without so we're extremely appreciative for that. Typically, 
we have a host presentation but Juniper wanted to donate that time 
back to us for the rest of the plenary and wish everybody a 
productive meeting. 

Alissa: So on to the IETF chairs report. I'll cover some typical 
items: participant statistics for this meeting, a little note about 
the HotRFC session that we had on Sunday, an update on IASA 2.0, 
preview of an agenda experiment we're running at IETF 103, and then 
just a reminder about respectful behavior at our meetings. Here in 
Montreal we have 1020 people on site. We have 137 first-time 
attendees - just a pretty typical sized group of first-timers for a 
summer meeting. If we compared to the last summer meeting, it's a 
little bit on the small side, continuing with the trends that we've 
seen over the last few years. We had participants from 56 countries 
this time - pretty on par with the last summer meeting as well. 

Alissa: The IETF Hackathon took place on Saturday and Sunday. We set 
another new attendance record at the Hackathon - 227 people showed up 
in person. They had more than 300 registered, 41 people remote, and 
we had 25 different project teams. So that event continues to just 
grow and grow. We also did the Hackdemo Happy Hour on Monday night, 
where teams could present their projects and talk to other attendees 
about what they accomplished on the weekend. We also had the World 
Cup streaming at the Hackathon, an additional benefit of if the 
meeting date change. Some people worked very very hard, as you can 
see, while they were watching the game. The next hackathon will take 
place again on the weekend prior to the working group sessions 
starting November 3rd and 4th in Bangkok prior to IETF 103. Please 
plan your travel accordingly.

Alissa: This is the second meeting where we ran an event on Sunday 
night called Request for Conversation HotRFC. This involves lightning 
talks to encourage brainstorming, to socialize new ideas, to find 
collaborators, to advertise Bar BoFs and side meetings. It took place 
on Sunday, and there were 10 talks. There was a packed room there 
were more than a hundred people there and you can find the 
proceedings on the web. This is something we've done experimentally, 
it's only the second time so the IESG is looking for feedback about 
this, whether people think it's a useful event, whether we should 
keep doing it, what we should change. Big thanks to Aaron Falk for 
doing the organization there and taking the initiative to plan the 
event. 

Alissa: I also wanted to give an update about the IETF Administrative 
Support Activity 2.0, a project that's going on and going on for a 
couple of years now this is the discussion about how we re-factor the 
way that we administer the IETF. The current plan is to create a 
limited liability corporation, IETF LLC, to house the IETF's 
administration. It will be a legal entity within the Internet Society 
where we are currently organized as an activity. On Tuesday the IASA2 
working group met, and in the room at least there was rough consensus 
about the final big open issue that we needed to resolve related to 
the LLC's board structure. So the next steps is that consensus is 
being confirmed on the list. We're also going to be finalizing the 
legal documents that are required in order to create this LLC. Those 
will go out for the last pass to the IETF community, and then the 
hope is to execute those legal agreements and start getting the LLC 
set up in August, prior to the changeover from the current ISOC CEO 
to the new CEO who's starting in September. So that's the plan for 
IASA 2.0 as it stands.

Alissa: I wanted to give people a heads up about an experiment with 
the agenda that we're going to be running at IETF 103. This has been 
mentioned on various mailing lists but I wanted to call people's 
attention to it in case you're planning your travel to IETF 103. 
We're going to run working group sessions only from Monday to 
Thursday. There's not going to be any working groups meeting on 
Friday. We are going to have meeting rooms of all different sizes 
available on Friday for ad hoc meetings and the IETF network is still 
going to be available. You'll be able to sign up for those at the 
same time when we open working group scheduling. We're trying to do 
this to see if we can have a little bit more focused time in the 
working groups. We have a lot of working groups who typically request 
not to meet on Fridays anyway and we've heard the suggestion that we 
try to schedule more ad hoc time. Friday might not be the best day, 
but we're going to try this. We might try something different in the 
next go-around but we thought we would do a little bit of 
experimentation. We're definitely looking for more feedback. We've 
gotten a lot of feedback already, which we appreciate. Certainly, 
once we actually run the experiment, we'll be asking everybody for 
their feedback.

Alissa: I just wanted to remind everybody about our guidelines for a 
respectful behavior. It always seems weird to me that we have this 
slide in here on Wednesday, when everybody's already been here for 
three days, so hopefully I think everybody is already aware of our 
guidelines for respectful behavior. We have a number of different 
documents that outline what our policies are that that govern how we 
treat each other here in the IETF, so please be cognizant of those. I 
think in particular we're really trying to establish an inclusive and 
open community. Sometimes those two things actually are at odds with 
each other. But I encourage people to take a look at the at the 
documents and think about them as you as you walk around the IETF. 

Alissa: We always publish a report in advance of the IETF Meeting, so 
there's a bunch of other topics that are covered in there that give 
more updates. About working groups that have closed and opened, 
notable documents that we published since the last meeting, and so 
on. Also, currently running experiments that we have, appeals. We've 
had one appeal since the last IETF meeting, and lots more detail from 
all of the other entities that support the IETF; the IAB, the IAOC, 
the RFC editor, IANA, the NOC, the Secretariat, and also some 
reporting from the Hackathon. Please check that out. 

Alissa: We like to use the IETF blog to expound a little bit more 
about what's going on in the IETF. If you have something that you 
think is interesting to the outside world, and you want to publish on 
the blog please let me know. We're always looking for more content, 
and we would be happy to have more contributions. We are not gonna 
hear from Ted until later, and with that I will turn it over to 
Allison Mankin, IRTF.


Allison Mankin: I don't have slides this time. If you want to see 
slides about the IRTF, they're in the IRTFopen proceedings. I wanted 
to just tell you that we are a growing group. We're very grateful to 
everyone who cooperated with us because we had our yearly workshop, 
which is called the Applied Networking Research Workshop (ANRW) which 
is co-sponsored by ACM, ISOC, and IRTF, as well as some corporate 
sponsors whom we thank gratefully. We had it on Monday of IETF week 
for the first time. This was the third of them, and we were asked by 
the participants to make it during IETF, so that researchers could 
come here and participate and become involved in working groups and 
research groups as well. We would be interested to hear your 
feedback, those of you who may not have registered for it, are not 
the people who came specifically for it, about how that felt to you. 
But from the point of view of the attendees, it was a great success. 
It made a huge difference, because we knew that the sessions were 
surrounded by people who were working actively on the deployment of 
protocols while this research was being aired. That's a very 
inspiring thing. That's one of the things that inspires people to 
come to IETF, is that there's a chance that their work will be used 
and deployed. So thank you for that. Those proceedings you can find 
everything about IRTF at irtf dot org, so check it out. Ask me 
questions about ANRW but you'll find a report about the statistics of 
ANRW and things like that in my more detailed report, which I gave to 
the open meeting. Yeah?

Sean Turner: Allison, Sean Turner. I thought it was great actually. I 
really particularly liked the TLS session. I'm glad it didn't 
conflict with anything. I guess I would say resist the urge to put it 
on Friday if we're in Bangkok again. Okay, like on a day where it's 
actually the same with the working groups. I think that would be 
better.

Allison: Yeah, I think that'd be better. Yeah, and I should also 
thank the magnificent schedulers of AMS, because we actually worked 
to avoid scheduling relevant working groups against sessions so that 
people could drop in and out of the ANRW. I'm glad that you 
appreciated that, glad you noticed that.

Sean: It was very good. 

? (faintly from the audience): Can you say that last part again?

Allison: The magnificent schedulers of AMS.

[Applause] 

Allison: Anyone else?

Aaron Falk: Hi Allison, Aaron Falk here. I thought the workshop was 
great and I want to comment to folks in the audience who were not 
there, Sharon Goldberg, the workshop chairs, the introductory 
presentation on how to help new people get traction for their 
proposals in the IETF. I understand it's posted on the proceedings 
page and it's a few slides. If I run into anybody who's from outside 
the community who wants to get something going in the IETF it's the 
first thing I'm going to show them after the Tao.

Allison: That's a really good pointer, thank you. 

[Applause] 

Alissa: Next we have administrative hot topics, Glenn Deen and Portia 
Wenze-Danley. 

Portia Wenze-Danley: Good afternoon. I am not as nervous as I was the 
first couple of times I was on the stage thank goodness. So along 
with not being as nervous I also have really had a chance to get to 
work with more people in the few months that I've been here, and 
actually get to know people on a different level. Of course it takes 
a lot to make these meetings work and we really appreciate the 
efforts of our host, and our sponsors, and everything that it takes 
to really go out there and get the funds to make the meetings a 
success for everyone who's coming from so far away. Our global host 
for IETF 102 is Juniper Network, and we really appreciate I hope 
everyone has enjoyed the venue this time. It has wheat I think it was 
actually created for IETF because of all the collaborative spaces 
around it's been a great place. So Thank You Juniper for your help.

Portia: We also have a lot of sponsors in addition to Juniper to make 
sure that we are doing everything we can to make your experience 
work. I have a couple of notes here. Our silver sponsors are Oracle 
and Akamai thank you very much we appreciate your efforts. We also 
have our bronze sponsor, Verisign. Connectivity sponsors TELUS and 
MetrOptic, and openface. We have two circuits that came in and I hope 
everything has gone well with your connectivity. Our Welcome 
Reception, again Juniper Networks, and I'd also like to acknowledge 
our Syster's lunch sponsors, Fastly and Comcast and NBCUniversal. I 
have not had a chance to attend those yet so hopefully one day I 
will. And that it'll go well tomorrow. In addition we would also like 
to acknowledge everyone who works on the datatracker enhancements, 
and the Code Sprint. It takes a lot to make sure that we are 
enhancing the tools to make sure that it's working well on your 
behalf. Our Hackathon, Juniper, Cisco devnet, and NBCUniversal; thank 
you very much. And of course the NOC volunteers for the NOC we have 
everyone who works with Limespeed and MeetEcho; bringing the meeting 
to participants on a remote level. 

Portia: Now we'd like to acknowledge that IETF is going to be in 
Bangkok in November. We are actually in negotiations for a Global 
host for this meeting and hopefully we have some negotiations that 
are going on for hosting opportunities. We do have a local host that 
has been very instrumental, and helping us get things going there on 
the ground: THNic. We are very thankful for everything that they've 
done. I would also like to thank Randy Bush for helping me connect 
with our local host, to make sure that we were able to move forward 
in so many different ways. If you are interested in hosting, please 
see Ken Boyden and Ken could you please stand up so people can see 
you. Thank you. And with that I thank you very much.

[Applause]

Glenn Deen: Hello. You may notice I'm not Andrew Sullivan. So one of 
the big changes that happened is Andrew Sullivan of course is now the 
CEO and president as of September 1st of ISOC and that made him 
ineligible to be the IAOC chair. So at this meeting, Andrew stepped 
down from the chair position but he remains in the IAOC and I was 
selected as the new. Hello and I am Glenn Deen if you don't know me. 
So the IAOC right now is clearly in keep-the-lights-on mode. The LLC 
is under way to being developed and set up. And eventually when it's 
in full operation the IAOC will dissolve and be replaced by the LLC. 
So we are still in business, we're keeping the lights on, and we're 
doing what we've always been doing. I'd like to say thank you for 
Andrew for his time as chair of the IAOC and I'd also like to 
acknowledge Kathy Brown. This is her last IAOC meeting that she was 
able to attend. She'll be retiring and moving on. So thank you both 
Andrew and Kathy.

[Applause]

Glenn: So one of the big changes that has been going on in the 
meeting selection process in the last year was the development of the 
meeting venue criteria, and there's been a working group that has 
been meeting now for about a little more than a year. They've come to 
closure on that document going through the RFC publication process 
currently. We've taken that document in the IAOC, and we've updated 
our meeting process to reflect its requirements. If you go to these 
URLs you will see the new documented process for how meeting venues 
are selected and evaluated, and hopefully it's very clear now and 
very well documented. The other thing I'd like to note that we've 
have a replacement. We have an old meetings committee that went on in 
the IAOC that took care of lot of stuff, and with this new change the 
new meetings venue review process, we've created a new committee. 
Literally called the "Meetings Venue Review Committee" whose job it 
is to take the venues we were examining and measure them against the 
criteria that were developed by the working group. That's a 
significant change about how meeting spaces will be selected going 
forward.

Glenn: In addition, we have new meeting dates that are being selected 
for this period of 2023 through 2028, and they've all been sent out 
to the lists for input. Okay, so here's the controversial one, 
potentially. W warned you a while back that with the meeting rates 
we're going to be changing. The good news is the early-bird fee has 
not changed. It remains at what it's always been or what it's 
currently. But we've made some other changes so the late fees will 
increase just before the meeting two weeks before the meeting and at 
the meeting to $1,000 U.S. The standard rate for those who don't 
claim the early-bird fee will be eight seventy-five and I'll show you 
a chart in a minute that shows the breakdown of when those kick in. 
So here's basically the layout, and so for the people who are looking 
at when they can claim the early-bird fee, it's going to open seven 
weeks prior to the meeting is when that registration will open up and 
you will be able to claim that fee and so if the upcoming IETF 103 
that means that registration will be open no later than August 13th 
two weeks prior to the meeting ups or up to two weeks prior to the 
meeting you can get this standard rate which is eight seventy five 
and if you are closer than two weeks you will pay $1,000 this was the 
best way we could balance out the charging and a need for IETF to 
increase the rates but give people an option that allow them to 
maintain the current rates. 

Glenn: One point I would really like to make; Thailand is a brand new 
country. And we have not been to it as the IETF before so the 
guidance we like to give to every attendee and wherever you're from, 
even if you've never needed visas before please take a look at the 
visa situation for yourself personally. See if you were going to need 
a visa or not. And now on visas. Typically, visas require letters of 
invitation; the process that is now in place going forward is that 
prior attendees to IETF meetings can request, once we open 
registration, you'll be able to request a letter of invitation. For 
attendees who have not been to a meeting in the past, you will have 
to register and pay your registration fee, and then you can request 
your letter of invitation. If it turns out you are unable to get your 
visa through the process, if you can't attend because of a visa 
issues we will refund your fee. Okay. Clear enough, and we're going 
to publish all this on the website, so it's very clear when we do 
registration for 103 and going forward. Finally, the very detailed 
report you want all the gorp and all the details they're available 
here on these links. So that's so far for this meeting it's actually 
been very good meeting. We are only three fewer than projected 
attendees were 1027, which is wonderful. We have remote participants 
442. We issued 221 letters of invitation for visas. The revenue from 
registrations is $698,665. Sponsorship revenues $443,332. It's been a 
good meeting. Looking back, IETF 101 in London, we had 1211 paid 
attendees, eighty-five more than we've projected and I won't read 
every last number out here. Bottom line, we did pretty well. The 
revenues total were of $1,493,876. Thank you.

[Applause]

Alissa: Thank you, Glenn and Portia. Next we have the NomCom. Scott?

Scott Mansfield: Hello IETF community. Do we have. We need some 
attention come on let's get some energy going here. This is the 
NomCom. It's exciting stuff. So I'm your new NomCom chair coming in 
and so I have a few slides that I've prepared. So the first slide is 
to show that it is actually possible to herd cats. And this is what 
we're going to be doing for the next six to eight months. So I'm not 
going to tell you which who the cats are any of that you can figure 
that out for yourself. But the important thing here is to acknowledge 
the fact that we have a large number of volunteers that are helping 
out with this process of electing the next set of leaders for the 
IETF. I would like all of the voting and non-voting members, if 
you're in the room, please stand. If you've got your orange dot, wave 
it proudly. One there's one there's another one over there a couple 
back there. So these are the people that I'm going to be relying on 
heavily. I am a non-voting member, which means all I can do is make 
sure the cats go in the right boxes. So it is very important to 
provide feedback, and the way that we're going to interact with the 
community is through our wonderful set of IETF datatracker tools. So 
if you've never used it, you probably have, but if you've never 
looked at it, I provided the link to the website. And there are some 
tabs at the top, and so when you're ready to nominate yourself or 
someone else, you can click on the nominate tab, and fill out the 
forms. And then emails will happen, and then you know magic occurs. 
Then when we get to the point of having all the nominations and 
nominees, and you'll be able to provide some feedback. 

Scott: And there's going to be some new behavior, so look, you know, 
keep your eye out for some new behavior. And new ways to provide 
feedback to the NomCom this year. If you're looking to see what type 
of experience we're looking for from the community, we will have we 
have some information there now. That information is current there's 
a couple of places we're still looking for some more details about 
the experience, and so I'll point that out in a slide or two. And 
then there's questionnaires. If you're going to be a nominee, we have 
a questionnaire that you need to fill out. Those are a work in 
progress. You can see what we did last year, and we're going to 
continue to do some work on those so that's some hard work that we're 
going to be working on soon. Like in the next week or two. So here's 
my proposed timeline. This is published on the NomCom main page the 
important date here that we really are striving for is the August 
16th date. The NomCom will be working very diligently to make sure 
that we have all the job descriptions, and the questionnaires, and 
our thoughts together to be ready to announce the call for 
nominations on the 16th of August. 

Scott: Once that thing comes out, we expect a flurry of activity from 
this community so that we can have a wonderful pool - a set of people 
that that we can choose from. Something that's new this year, as you 
may have heard, if you were paying attention to previous conversation 
tonight, is this LLC board member. So I want the community to start 
thinking about this, because this is not the type of position that 
the IETF NomCom has asked for in in the past. And so there's some 
different characteristics of people that we're looking for. So please 
take time provide some consideration. Read the background, and really 
provide this NomCom with a reasonable, wonderful set of candidates 
for this. So I am going to end. This is my last slide, I'm going to 
end quoting the famous American philosopher, Fiona Apple that there 
are a couple lines we are an extraordinary community right there's a 
song that she has. It says "but he's no good at being uncomfortable 
so he can't stop staying exactly the same." She also says "but I'm 
good at being uncomfortable so I can't stop changing all the time." 
What I'm asking this community to do is embrace the uncomfortable. 
We're going into a world where things are changing. We need to make 
sure that we think outside the box, think of ways to make the IETF 
community even better than it is. So look around the room. This is 
your community. It's up to you to make it awesome. So help me do 
that. Thank you.

[Applause]

Alissa: Thank you, Scott. And thank you for your willingness to serve 
in the role. I know it's a lot of work. Allison, can I ask you to 
come on back up? 

Allison: Many of you may not have known Bob Braden which seems almost 
impossible to me because for the first 25 years of the IETF you would 
not have been able to not know about Bob Braden. But if you do 
remember him, if you're you know since we had this nice growth and 
lots of newcomers, you probably remember him as the person who took 
over the RFC editor after the death of Jon Postel in 1998. And served 
in that role with Joyce Reynolds for many years. Joyce is also gone 
now and also very much missed. The people who remember working with 
Bob will remember his work on the end-to-end task force and then 
research group RSVP maybe some of you remember that he was a fierce 
advocate for the earliest days of Internet Multimedia. So this is the 
start is, to just talk about him technically. Because we are a 
technical body. He bridged us from the days when there were lots of 
task forces, End to End Task Force and IETF were parallel 
organizations. In those days, to a time that most of us don't even 
know all the different things that we owe Bob for, in terms of 
technology and things that we take for granted now. But then the 
other thing is that the other night a group of us who had known him 
well, met together with his two sons, and with two nieces of his who 
came here because IETF was such an important part of Bob's life. And 
reminisced about him. I just want to say very briefly that everybody 
who spoke, spoke of his humor. That it was acute and mostly gentle. 
They spoke of his genuine and warm willingness to teach. He was never 
a professor, but he was always a teacher here at IETF. And many of us 
who have been in the IETF for a long time owe a great deal to the way 
that Bob taught newcomers, and helped people to become knowledgeable 
about the whole of our Internet Architecture. And then finally, 
people kept mentioning his great dedication. He was supremely 
dedicated to the Internet, and to the IETF, and carried out kind of 
heroic efforts on the part of us that we still use full standards 
such as the hosts requirements standard, that required just heroism 
on his part to pull off. He is being memorialized here because of 
that tremendous and formative role that he played in in our 
organization and our technology. I don't know if anyone else wants to 
say a few words about Bob.

Philip Prindeville: I remember being on my second job out of college, 
twenty-five years old, working for Wellfleet on basic security 
options, and ripping my hair our, and Bob was extremely patient with 
me walking me through the logic of how everything worked and giving 
me great insight in what wasn't stated in the RFC. I don't think it's 
a stretch to say that I wouldn't be here today if it hadn't been for 
him. 

Allison: Thank you, and also welcome back 

Philip: Yeah it's been 30 years and one week since my last IETF, so...

[Applause]

Bob Moskowitz: We have a model you see in our science here that IETF 
making the Internet work better but I think about Bratton I think 
IETF making the Internet WORK. 

Allison: With dedication. And humor. Thank you.

Alissa: Okay we're gonna move on to the Postel award. 

Kathy Brown: Thank you. It's my great pleasure on behalf of the 
Internet Society to present the 2018 Jonathan B. Postel Award. Jon 
Postel, the first editor of the RFC series. The first director of 
IANA, and the first member of the Internet Society in 1992. The 
Jonathan B Postel award was established by the Internet Society to 
honor individuals, or organizations that, like Jon Postel, have made 
outstanding contributions and service to the data communications 
community. Since his death, and the first award in 1999, seventeen 
times this award has been given to esteemed members of this 
community. I myself have had the amazing privilege of doing the last 
four and now the final time I do this the fifth. What is very special 
about this award it is a peer award so the prior winners of the award 
are picking the next person who is Steven G Huter.

[Applause]

Kathy: For his leadership and personal contributions at the Network 
Startup Resources Center that enabled countless others to develop the 
Internet in more than 120 countries. This year, you are the winner of 
this very special award - which is stuck in customs - so we will take 
the picture. 

Steven Huter: Thank you, Kathy. 

[Applause]

Steven: So when I first got your message a couple months ago, Kathy, 
I was scrolling through morning email and I read it and then I 
decided to have a few more sips of coffee and read it again to make 
sure it wasn't spam. And then, you know I kind of flashed back and I 
thought 1996 Montreal. And the last time I was here was the joint 
INET IETF meeting that was here in Montreal. I was one of the 
volunteer of ISOC folks helping out with the INET workshops, and 
there I made friends with a guy named [Adiel Aplogon]. Many of you 
know him. He came from Nome Togo for the workshop. You know when it 
was over, we went to the IETF meeting to go you know, check that out. 
And we were riding on an escalator and he said hey man how do I how 
do I get this dotTG you know my country code you know top-level 
domain isn't delegated yet. In a great moment of serendipity Jon was 
coming up the escalator as we were going down. And I just said: see 
that guy with the long gray beard? We need to talk to him. And you 
know I said Jon could you wait for us at the top? And he said sure 
and so we rode up and you know, Adiel introduced himself posed his 
question and John chatted with him for a few minutes. And said you 
know, you know the drill, get the nameservers up, and fill out the 
template, and send it in. and Adiel worked with actually a guy from 
Quebec here from Montreal Francois Norman who assisted him with yet 
that going and a few days later, you know dotTG was on the net. So I 
kind of thought back to how, in a way, it was nice and simple things 
were back then, and it gave me a nice time to reflect about that 
experience with Jon. 

Steven: I'm happy to receive this award on behalf of the Network 
Start-up Resource Center. And I feel strongly that it really should 
be a group award, because there are a lot of people that contribute 
to this. From you know, folks at the University of Oregon to 
international contractors, and dozens and dozens of volunteers. Some 
of whom are in this room, but you know, when I first started working 
with it in 1993 - quite some time ago - you know, it already had 
roots well before that. And in the original vision and inspiration, 
and frankly sweat, was all Randy Bush. Randy had started in the late 
80s assisting folks in South Africa with establishing some of their 
first connections to research institutions, universities. And that 
led over to the neighbors want to use CP email feed in Namibia and 
Botswana. Zambia, Zimbabwe, etc. And it led to this amazing set of 
stepping stones that that really helped several dozen countries with 
some of their first TCP/IP connections. So 1992 Randy teamed up with 
John Klensen, who was at MIT at the time, and he was working with a 
United Nations university project under the International and 
Nutrition foundation and they were trying to get email connections in 
a bunch of countries so folks could basically do nutrition education 
with people in their countries about this. So they wrote a grant to 
the National Science Foundation to formalize what they were doing and 
that's really the roots of it. And at another great moment of 
serendipity there was a guy named Steve Goldstein, some of you may 
know him, and he happened to be appointed as the International 
Interagency Networking Coordinator about this time and really needed 
to start internationalizing the NSF net, and getting connections into 
countries where US scientists were being funded to do you know 
paleontological research in Mongolia. And geophysics research in the 
Rift Valley. And all sorts of things like that. 

Steven: So several other people got involved, and Randy was awesome 
at you know recruiting people for the INET training workshops and 
then starting to cultivate network operator groups. And always 
infusing a spirit of cultivating network operators, helping each 
other. And that's really the essence of how the NSRC still operates 
today. You know we've evolved the model and techniques to today's 
internet, to do the training and things are virtualized, and all 
sorts of other advancements. But the heart and spirit still really go 
back to the roots. That I learned, and we all learned from Randy, and 
and John. And Jon Postel was a close peer of theirs. I was fortunate 
to meet him by association with Randy and John, and really grateful 
to receive this today. So thank you, ISOC, thank you, IETF, thank you 
University of Oregon and various other few dozen sponsors 
particularly NSF and Google, that have been steadfast over the years. 
And thanks to all of you that contribute to the work of the NSRC and 
help in advance the net in new places. Thank you.

[Applause]

[Applause]

Alissa: Okay. So next we have a somebody special to recognize we 
thought you were gonna get off the stage Kathy, but you're gonna have 
to come on back up. Not just yet, you can wait. I'll give you a 
little break. Io I knew of Kathy before I knew Kathy, going back to 
her days as in government and at Verizon working on telecom policy. 
my father also was working on telecom policy. Not always on the same 
side as Kathy, often almost never on the same side as Kathy from what 
I could gather from my family lore. But I think the way that Kathy 
would characterize him, and actually she just did this the other day, 
was that she would say I love him for it. And that's really the 
spirit that Kathy that I've seen Kathy brings her to her role at ISOC 
in her role in the Internet community when I did get to work with her 
starting in the IANA transition process several years ago, that was 
always the mentality that she brought. Even if we have opposing 
views, different parts, different constituencies, she was always 
striving to see what are the commonalities? Get us to focus on our 
common goals. And what we're trying to achieve together. Even if she 
disagreed, with you she loved you for it. And given the success of 
that transition process, we are all the beneficiaries of her 
leadership and strategic vision in that process. Even closer to home 
Kathy has been really integral to our ability to carry out the IASA 
2.0 process thus far, and on a really short timeline. For a project 
this complex. She has really combined an openness of mind to allow 
the IETF community to explore all different avenues of what it is 
that we might want to do as an organization as a community, while 
also at the same time constantly reaffirming ISOC's support for the 
IETF and the desire to provide whatever it is that we need in order 
to succeed and continue to make the Internet work better. And for 
that, I'm very grateful and I think we all are. So thank you so much 
Kathy, for all of your contributions as ISOC president and CEO and we 
do have a few gifts for you if you want to come on up on stage we 
have the traditional plaque. You've given a lot of these plaques, so 
we got you a plaque.

[Applause]

Alissa: Also of course it's not the real plaque, we're gonna send you 
the real plaque. We know that, unlike some folks in our community 
whose retirement involves sending many emails on mailing lists, your 
retirement sounds like it's going to involve potentially staring at 
the ocean. And we wouldn't want you to forget about us, while you're 
staring at the ocean so we got you an IETF beach towel. Again, not 
the real towel. The real towel will be sent.

Kathy: Thank you. This is a bit of a surprise. It's been an 
experience, an honor, and a privilege to be part of this community to 
be part of the Internet Society. The work you do the work the 
Internet Society does is crucial to the to the evolution of the 
Internet. To its continued opportunities that it provides for the 
people of the world. And so it is with great appreciation and I 
appreciate this towel. I now intend just to look at the ocean and 
figure out what it all means. Thank you.

[Applause]

Alissa: Next up, we have the IAB open mic. So if the IAB could come 
up to the stage please. 

Ted Hardie: So while the rest of the IAB is assembling I must note 
that tonight one of our colleagues, Christian Huitema was unable to 
join us because of a death in his family. Our thoughts are with him 
and his wife as they have returned to France to deal with the 
situation. As is traditional, we'll start with introductions.

[IAB and Heather Flanagan, RFC Editor introduce themselves.]

Ted:  The mic lines are open.

[some tries a muted microphone]

Heather: I totally don't believe you.

Ted: You're really hoping I'm gonna sing the Zero Mostel version of 
comedy tonight aren't you? 

Barry Leiba: Well, I'm certainly not going to sing it. 

Heather: Thank you, Barry. 

Barry: What are you planning to do about the RFC Series?

Heather: Why thank you for asking Barry. I have a list it's rather 
long. First some of you might have heard that we're working on 
changing the RFC format. Is this, is this a shock to anyone in this 
room? Wait I saw a hand. Okay there's two. I don't believe you. Yes, 
so this is a project we've been working on for quite some time. The 
good news is that we are in the phase that the RFC Production Center 
is actively testing the tools, so it's moved from you know a gleam in 
my eye to actual code that we're trying to make sure is running. Once 
we have it to a state that it works for the production center, then 
we're going to be reaching out to the community and asking you all to 
be testing it as well. To make sure it works for you. At this point 
I'm expecting that to happen around the next meeting. Things have 
taken a little bit longer than I had certainly hoped, but progress is 
being made. Just slow and steady. So there's that.

Heather: Other projects, however, are on my list. Some of which are a 
little bit I would call edgy. There's things I want to try and do, 
like when we have RFCs that are actual proper HTML with the CSS, 
wouldn't it be really interesting to have a sandbox place to say 
"well what else can we do with this? can we actually annotate these 
with some of the errata? Would that cause, in terms of the where 
people reference the archival version of a document?" I don't know, 
this is something I want to explore. There's a lot I can do with the 
metadata in documents that can be improved, that doing that has an 
add-on effect of making the documents much more easily indexed in 
other organizations sites and services. And to be very, very clear I 
should have put this in my email to the to the IETF list earlier, all 
of this is all well and good, but frankly the first priority - the 
priority that comes before all of this, is to publish documents. If 
any of the projects that I come up with look like they're going to 
impact the rate of publication, it's something I do with a lot of 
consultation. Otherwise, the projects have to wait because we want to 
get your documents out the door. That's the most important thing that 
the RFC Editor does so - that's the short version.

Ted: Aaron I believe you're next.

Aaron Falk: So way back, I used to be part of the RFC Editor. I'm 
currently part of something called the RFC Editorial Board. There's 
another group called the RFC Series Oversight Committee, which my 
understanding is a support group serving at the pleasure of the IAB. 
I am wondering if you could maybe talk a little bit about the 
relationship between that group and the IAB how the IAB uses them. 
Maybe a little bit about their involvement in the BoF last night was 
something I didn't see come up on the list or in the BoF. I 
understand that the entire group is up for potential replacement as 
what if you could sort of talk a little about that.  Well first is 
that true, and if so, why. Thanks.

Ted: So the RFC series Oversight Committee is actually an IAB 
program. it's set out in one of the RFC's the number of which I am 
looking up frantically [RFC 6635]. Okay so like many other programs 
it's part of how the IAB maintains long-term commitments that may 
continue past the lifetime of any single IAB member. So the whole 
program effort there has been put in place to make sure that the IB 
can keep attention to something over a longer period of time than the 
lifetime of any single member or chair. And in this particular case 
the RFC sets out that the RSOC will be part of the oversight of the 
RFC series. Okay so the RSOC is in fact, at this point we have put 
out a call for volunteers, and there are interviews going on this 
week, some of them have happened already, for new volunteers or 
continuing members of RSOC and it's actually pretty typical. You'll 
see that the IAB calls for volunteers all the time for different 
things. The appointment process will go forward after we've had the 
interviews, and after we've collated the information from the 
interviews with the public information that we got from putting out a 
call for comments. Oh sorry Robert, did you want to talk about RSOC a 
little bit more? He'll continue to talk about RSOC, and then I'll 
talk about the BoF.

Robert Sparks: So the defining documents for RSOC talk about the 
reason for having it as a separate body the IAB manages. It as a 
program, because it manages many other things like a program but it 
is a little bit more than a program in the way that it's defined when 
we set out to call for the people who volunteer to serve on the RSOC, 
we realized there had been quite a long time since we had done a 
serious evaluation of everyone that was on the RSOC. The IAB decided 
that we would just re-evaluate everyone who was willing to continue. 
At the time the IAB made that decision everyone was fully cognizant 
that one of the major reasons for having RSOC as a separate body was 
for continuity of information. That was expected to be a relatively 
stable body of people. So if there was concern that this was a clear 
the slate and put a new set of people in kind of intended activity, 
that is certainly not the case at all. It is more exercising the 
responsibility the IAB has for overseeing the RSOC itself, and making 
sure that we're doing the right thing. 

Aaron: Are there terms or mechanisms that ensure continuity? 

Robert: No there's there are no terms. The document that created RSOC 
has the principles that define how the IAB should manage its 
constituency and the IAB is very much aware of what those principles 
are. 

Ted: So the RFC in question is RFC 6635, as somebody mumbled earlier 
but has been confirmed since then. My apologies for not having it on 
the tip of my tongue. On the question of the BoF, as you may have 
seen from the message the IAB sent out earlier today one of the 
issues there is we did not do some of the coordination that we would 
have normally done in a timely fashion. Indeed there was not a 
coordination with the RSOC in advance, so some of that is certainly 
one of the things we feel like we did wrong about that, and we 
apologize.

Aaron: Do you think in a perfect world that IAB talking to RSOC and 
RSOC talking to RFC is a reasonable path for how the concern that 
motivated the BoF could have been expressed? I'm trying to understand 
sort of the role of where this fits. If the IAB is going to go off 
and do things on their own, what does the RSOC do? 

Ted: So I think that there is a distinction here that's important to 
draw, right? The RSOC and the RSE and the Editorial Board all do 
things that are very important but primarily relate to how the RFC 
series is now. There's a role that the RSE plays in thinking about 
the evolution of the RFC series is. There's also a role for the whole 
community to think about it as I noted this particular problem has 
been called it to the fore by the IAB in the past. There have also 
been other suggestions for changes to the RFC series. For example the 
best current operational practices effort that was discussed some 
time ago, that came from external bodies to the IETF. I don't think 
there's a limitation in who can suggest changes to the series, but 
there's a very important principle that those discussions need to be 
public. I think that the problem that we ran into here is in trying 
to pay attention to that principle, and making the discussions 
public, some of the external coordination that should have happened 
before that public discussion didn't occur. 

Ted: Okay so I have Phil next and then I believe I have that 
microphone and then Bob and then back to that microphone.

Philip Hallam-Baker: When we look at the RFC series, I think the part 
of the problem is that we have this frame of how do we fix our RFCs. 
It might well be that what we need is something that's a little bit 
between an internet-draft and an RFC. Because many times all the 
people are coming to the IETF and asking for an RFC is simply to have 
something that is permanent, and can be referenced elsewhere. Now 
we've given up the principle that drafts expire and disappear. There 
now persistent and that's great for me as a patent expert witness, 
because it's my prior art sources. I think that maybe rather than 
trying to reform RFCs and solve the problem in that frame, it may be 
that you need something in between. A little bit less than an RFC. 
And maybe what we need to do is to work out yeah, are the drafts 
something that the IESG should be doing? Should they be happening 
with the RFC and need to be considered together, because you've got 
two publishing streams here, and you need to think about where the 
best place is rather than choose one of the other things.

Ted: Heather did you want to answer that?

Heather: I think it's an interesting idea. It's something I'll want 
to explore I'm my gut reaction is a bit of hesitancy. I mean one of 
the things we had as feedback the other night is dividing RFC's into 
a host of other things means you have a brand to build. And you've 
got confusion that you're introducing to solve other confusion. How 
you handle that can be really delicate. It makes me anxious to 
consider how we're going to do it. It's not a no, it's a we have to 
be careful if we go that route.

Ted: Richard?

Richard Barnes: Quick comment, and then a question. Robert, I wanted 
to react real briefly to a phrase you used which was continuity of 
information I realized that can be they can seem like a motivation to 
keep a lot of stability in a governing board but the contrary you 
know what that makes me worry about is stagnation, and a lack of new 
blood. And you know it's a constant problem across a lot of groups 
that we have around this organization. And so I encourage you and the 
IAB to keep in mind that flow to get new ideas and new blood into 
these oversight bodies you're appointing. In addition to maintaining 
continuity, having a regular turnover can be a bit a way to maintain 
continuity because you establish processes around it. The question 
I'd like to propose opposed the folks, multistakeholderism is you 
know a thing that we're kind of keen on around here in a sense of 
making sure that all the people who are affected and have a stake in 
a decision are represented in making that decision. And so I'm 
curious what Heather and the members of the IAB in policy with the 
RFC series think is the set of stakeholders for the RFC series, and 
how you're pulling in relevant feedback from that whole collection of 
stakeholders in deciding how this RFC series evolves?

Ted: Heather and then I think I'll answer as well.

Heather: I want to talk to just about anyone that can spell RFC. If 
they're technical enough to know anything about that or incorporate 
that I don't know if folks realize that I'm not full-time doing RFC 
Series Editor. I actually work with scholarly publishers, I work with 
national research and education networks. I do a lot on the Identity 
and Access Management space. I have a lot of contacts with some of 
the network operator groups around the world. Through the IETF, I 
have contacts with a lot of the corporate entities that use RFC's, 
and I have no shame in leveraging all of those things to get the 
information I need. In turn, I will come back to this community and 
sort of the heart of it all to say here's who here's the type of 
group I've been talking to am I missing anybody I've already gotten 
some really excellent feedback about reaching out to open-source 
communities which I think is brilliant. As well as talking to RIPE 
and a few others. So open to pretty much anything. 

Ted: The one thing I would like to add to that is that there are 
really two classes of stakeholders here and that's the people who are 
producing RFC's and the people are consuming them. And it's much 
easier for us to reach out to the people who are producing them. 
We're connected to every single one of the streams here, and one of 
the reasons that we like to hold meetings such as the one was held 
earlier at IETFs is because you have IETF, IRTF, ISE, and IAB all of 
the stream managers are together at one time. And that can be a 
failing right, it's very easy for us to look at the production side 
of that and it's extremely difficult to pull in who may be the 
consumers of these RFCs. As a stakeholder community that does require 
some outreach that Heather is going to be taking on. But that is very 
general and we could use your help as a community with. I think one 
of the things she just mentioned for example was that Adam had 
suggested that the open-source community might be one as a consumer 
of RFCs for which we don't have great data. And they're gonna try and 
work together to get some additional data on that set of consumers 
even though they're very rarely producers of RFC's. Certainly there 
are other members of the community who have other ideas for how we 
can do outreach to the set of stakeholders from that side of the 
equation. It would be very valuable.

Richard: Thanks. On top of that is that given that I think this 
consumer stakeholder group is the entire internet technical community 
and numbers and millions it's gonna be difficult to take kind of an 
artisanal I have talked to people approach or someone goes and talks 
to people approach. So I think I would encourage you to take some 
innovation in collecting information.

Heather: I couldn't agree more. One of the meetings I'm having this 
week is with some of the folks who do communications and marketing at 
the Internet Society to figure out if I was going to do something 
like a survey how does one do that, how do they do their outreach. 
What's that going to look like? Could I potentially leverage some of 
the ISOC regions? It's just a very initial exploration, but I think 
you're right. As much as I apparently try to, I can't talk to 
everybody. I talk to a lot of people but not everybody. So yes it's a 
well taken point. 

Bob Hinden: I've been working with RFC Series for a long time, since 
Jon Postel, and all the editors since, and I've written a few RFC's 
and so forth. So I appreciate the public apology you sent to the RFC 
plusplus the IETF list about this. But I would sort of like to 
chastise the IAB for what you did here. So I'm gonna read from RFC 
6635, which defines this. Section 2.1 RFC Editor - The RFC series 
editor is the individual with overall responsibility for the quality, 
continuity and evolution of the RFC series. This activity should have 
been directed to the RFC editor the IAB should not have taken it on. 
It doesn't say the IAB is responsible here for these for the 
evolution and these things so I think you've seriously overstepped 
your responsibility here. I think in some sense your apology didn't 
go far enough, because I didn't get the impression that you sort of 
were willing to take it back, it was more of you just didn't follow 
the right procedure. But I think you should have asked the RFC Editor 
to look at this issue and consult with the community, and come back 
with a recommendation. You shouldn't have done a BOF. The IESG 
shouldn't have approved it. It appears that you did this in a rush so 
the IAB, which is supposed to be the deliberative body who says 
they're very busy, decided to take this on themselves. I think you 
know I think you made a serious mistake here. So I hope you take this 
to heart, and next time on some other issue you figure out what the 
right thing to do is but this this was not a very good performance. 

Ted: Leslie I think you're next.

Leslie Daigle: I think my remarks are probably gonna put some context 
around some of Bob's. Also, maybe some of my remarks would have fit 
in a little bit in the in memoriam section. Because it occurs to me 
that there's some stuff to this community to do well to remember and 
probably if you didn't know Bob Braden, and you probably don't 
remember this part of the RFC series history. Namely that for a 
number of years up until about a dozen years ago, it was published 
out of ISI. It was funded by ISOC even before there was an IASA. It 
was funded as a separate activity. So as part of the administrative 
restructuring that we did the last time around it was time for that 
part of our universe to move on and become under the same umbrella as 
the other activities administratively. But at the time it was the RFC 
Editor was a very independent beast. It was an academic function 
hosted at ISI like I said, and when we were in discussions and I can 
remember which airport I was striding around having those discussions 
with a head of ISI at the time. To move the function into something 
that was closer to the IETF administration, there was a lot of 
concern over how to make sure this remained true to the spirit of the 
RFC series. So how could it maintain support for the independent 
activities that have published because the IAB does not look after 
the RFC series for the IETF, the IAB looks after the RFC series for 
the internet community. So it's broader and so even having a BoF here 
to talk about it is very focused. It's as Richard outlined, there is 
many more people to reach out to. So on and so forth. But another 
piece of that puzzle was how could we make sure that the RFC series 
editor was adequately supported with a broad base of people who were 
familiar with both technical publishing and the internet publishing 
space, and hence RSOC. The RSOC was constituted not just to be 
another IAB program. The RSOC is an IAB program simply because that 
was the mechanism that the bill. But the purpose of the our sock was 
to be that collection of independent of advisers for the independent 
RFC series editor. So I think it's great for any committee it's 
absolutely great to review them periodically review the composition 
you know, adjust the mandate if necessary. But it isn't just that 
this is an IAB thing to you know update and twiddle with you know a 
BoF on a Monday night. This is larger than the IETF. It has to be 
handled with the broad perspective that the IAB has which goes beyond 
the IETF and it has a rich history all of its own. So Bob referenced 
the RFC that details the mechanics of how this got brought into the 
the IETF space but there's a lot of rich history out there but the 
background of the RFC series that people in this room sure certainly 
should make themselves aware of. I think that maybe there's a little 
bit more reading for the IAB to do before making more operational 
choices and discussions going forward. Thanks.

Ted: so just to point out two quick clarifying things. The 
Independent Series Editor also has an editorial board called the ISET 
which I believe Aaron referenced earlier which does editorial advice 
to them. That's a distinct from the RSOC both are of course available 
to advise both the independent series editor where RSOC is more for 
the RFC. The other thing I'll point out here is that one of the 
issues that I think that the IAB was thinking about here was 
evolution, and not just evolution for the IETF, but in particular for 
the IRTF, and for some of the other streams. It was very clear in the 
BoF on Monday that particular concern was not well expressed and we 
certainly apologize for it, but the evolution of the streams and the 
evolution of the output of the bodies that are both present here as 
producers is certainly something that we continue to look at beyond 
just the IETF. As we said, we're also going to be looking much harder 
at working out how we can look at the consumption side of the 
stakeholder body. But the simple fact is the movement into four 
streams has started, but not completed, a change in how the 
production works. We have to think as a community, not just the IETF, 
but as a technical community on whether it's best to push that change 
forward, let it evolve on its own, or make sure that the change is 
limited in order to keep all of them together. And that's the 
conversation we think Heather will be having as she goes out and 
starts the rest of this process.

Leslie: That sounds like an excellent conversation to have. What I 
got out of the BoF description. I hope you've got a lot of about what 
preparatory materials everybody participating in that conversation 
should have read before engaging in it we have a list of RFC's and so 
on and some thoughts about we're going to have it. Thanks. 

Ted: Thanks, and of course suggestions on both of those are welcome. 
I believe Andrew is next and then Lucy.

Andrew Sullivan: I wanted to say thank you to the IAB and to the IESG 
for approving this BoF. I thought it was useful. And the reason I 
think that is not because it was perfect, and not because that 
conversation has completed or the right results has come out or 
anything like that. But rather because this is the sort of thing that 
people sometimes go off into you know rooms and talk amongst 
themselves and don't talk about in public. And I think that you know 
this is a large community, there's a lot of different ways that 
people can express themselves and so on and this is a way that we can 
get out amongst ourselves and say: look here are the people who are 
producing these things, and we need to talk to each other about what 
those issues are, and so on now this is gonna be a fraught topic 
that's gonna be one that creates a lot of strong feelings. And a lot 
of history and different people have different views about this, but 
I think that it's good that we came together. It was like another 
plenary, right, because there's nothing else against it. I think that 
that's a fine thing to do. You know I can understand that there are 
people who don't feel that it was executed perfectly or whatever. I 
myself having executed a few things in public not always very well 
understand that sometimes you're gonna have a little bit of trouble 
but you know I still think it took a certain amount of bravery on 
your part to say hey, we're gonna talk about this. I'm going to talk 
about it public here, among the people who have to do this work, and 
it's definitely gonna be a delicate topic. So I really appreciate it 
I want to thank you.

Ted: Lucy, you're next.

Lucy Lynch: I actually want to change the topic slightly. Several 
people have referenced transparency, and engaging the community and 
conversation and whatever. I'm a person who likes people just show 
their work that's part of why I like the drafts that's part of it I 
like the archival part of the RFC series. I would like the IAB to 
publish their agendas and open their calls in the same way that the 
IESG does.

Ted: Okay. We'll take that under advisement and get back to you. 
Certainly all of the minutes are public. I don't know that we've ever 
published the agendas I have.

Lucy: Yes, after the fact of these conversations. What it says about 
this particular BoF is that you went into executive session.

Ted: And I will point out a good bit of this actually also occurred 
at the retreat with the IAB and IESG, and those minutes are not 
public either, so I take your point.

Ted: This mic.

Ann Bennet: In view of the negative comments about the RFC++ BoF, if 
I have comments on the very interesting topics that were raised on 
that BoF is it appropriate to post them to the RFC++ mailing list, or 
is there's some better forum for this discussion?

Alissa: the RFC++ mailing list has been closed. So you're not gonna 
be able to post anything there anymore the after the posting of the 
minutes I closed the list since the BoF process is over. 

Ted: Heather I think has requested that they happen on the RFC 
interest list which is a much longer running list it's the RFC 
interest mailing list sorry if somebody could write it down for you. 

Heather: And just as a side note for folks who would rather drink 
bleach then listen to format conversation, I think there might be 
some of you I'm trying to focus the RFC interest list on discussion 
topics and whatnot now that we're moving to looking at actual tools 
and testing tools and whatnot there is an XML to RFC - dev list, and 
I expect a lot more of the operational format work discussions to 
happen there when we're ready to release the tools for user testing. 
So keep that in mind.

Ted: speaking personally I have to know what flavor of bleach before 
you tell me it's gonna be a format issue.

Heather: Lemon. 

Ted: I think you were first before Shane. But I'm sorry I can't see 
you because there's a light shining right at me.

Philip Prindeville: I attended the ANRW. I think that was the first 
time that they were here. As somebody who dabbles in security without 
trying to make too much of a fool of himself since everything has 
security implications these days anyway. I appreciated having the 
academics present who will then study my work and then tell me where 
I went wrong afterwards. Or possibly even during these meetings so 
that spirit that embarrassment. So is that going to be a regular 
thing the ANRW Allison?

Allison: oh yeah so the its the that was our third iteration, but it 
was our first time where we had it during the IETF week instead of 
the weekend before. And that was the inspired idea of the program 
chairs, that they wanted to make sure that we actually brought it 
together with the community here at the IETF. So we actually already 
have the logo for ANRW 2019 ready to go, and we're making plans to 
get the next one going and in the near term.

Philip: Will they be concurrant?

Allison: Yeah. Come again next year. IETFers too. It'll be here in 
Montreal again.

Ted: so a lot of local knowledge will serve you again well drink 

Shane Anker: I apologize this is the wrong forum and I'll sit down 
and please don't yell at me but I been to a lot of side meetings this 
week which were held in the venue like with groups of 30 or 40 people 
discussing topics that were highly relevant to some of the working 
groups that are going on. I noticed a trend towards this over the 
past few years that we start to have meetings that don't have minutes 
or agendas or any way for remote people to participate. That are 
happening in sort of semi-formal way in the IETF. We have a kind of 
there's there's pushback in the BoFs because you can only have two 
for specific. I'm sorry I'm in the wrong place?

Ted: No, you're actually providing an excellent segue because your 
question is for the IESG so I'm gonna ask them to come up to the 
stage ask the IAB to step down and you can continue with your 
question as they do.

[Applause]

Shane: Yeah so that's basically it I know with BoFs there's a 
restriction, you can we have two BoFs for some reason so I know 
within certain people that have interest in topics they're kind of 
afraid to have a BoF because they don't want to waste their BoFs so 
that's where barBoFs became kind of a thing but now you have to 
register a barBoF. People have things that they don't know what to 
call these meetings, because they're not allowed to call them 
anything. So I guess what I would like to see if someone who doesn't 
come to every IETF, but when I'm here likes to participate I think 
easier to have some sort of official gathering here that doesn't run 
into all these issues about what do we call it, how do we record it, 
who's allowed to know about it, and these kind of things that's 
basically my question. Thank you.

Alissa: So we're gonna do a quick round of introductions, and then 
we'll take your question. First we have two members of the IESG who 
were not able to make it to the meeting this week Suresh Krishnan the 
Internet Area Director had a death in his family, and Spencer Dawkins 
is out with a family medical emergency as well. Spencer may be on 
remote participation and we have we have their photos here so people 
know what they look like. In any event and we'll start with 
introductions with Adam.

[Present IESG Members introduce themselves and what area they are an 
AD for.] 

Alissa: Okay so to your question Shane. I have just a few thoughts 
and then I'm sure lots of others will want to chime in so this is a 
topic that I know we've been wrestling with as long as I've been on 
the IEDG and it's probably been much longer than that to try to bring 
some clarity to you know what is considered an official meeting, and 
when does that note well apply and all of these things. What we've 
done recently as the IESG to try and facilitate that is we've created 
these side meeting rooms specifically for side meetings and they 
explicitly do not have remote participation capability. They don't 
have projectors. The idea of them is to facilitate ad hoc discussion 
of you know a closer interaction between a smaller group of people 
than what you would normally get with a BoF with microphones and 
presentations and slide decks and so on. We have this sign-up 
procedure for them, they open up at a certain time before the meeting 
starts and people can sign up to book them and then you know 
advertise them in the usual ad hoc ways on various mailing lists. Now 
it seemed that part of the idea of this was to bring some clarity, 
because it did start to seem to us like there were more and more 
barBoFs that were happening in meeting rooms that nothing to do with 
the bar. And they were looking more like BoFs, which go through a 
more formal approval process. So the idea was to draw a brighter line 
between these things. It sounds like maybe that hasn't entirely 
worked, and that's very useful feedback. But that was the idea behind 
them. Other people want to comment.

Mirja Kuehlewind:  so in this specific point, in the Wiki you can 
also see which like when the room was reserved, so at least you have 
a notion about what's going on. But I totally understand that it's 
kind of confusing because you don't know where you need to be, and 
who to talk to, and so on. I think we as a community also agree that 
this is kind of a value part of having a face-to-face meeting. That 
you actually have the opportunity to talk to each other in the 
hallways, having a side meeting. The thing we're struggling with is 
how to get this work at the right point of time back to the whole 
community to involve everybody in discussion and if you have further 
ideas we would be more than happy to listen.

Shane: Maybe removing the two BoF limit might eb a good start. I 
don't know. 

Alissa: Just the one other detail here is that there are some 
conversations that have started about the display of the agenda in 
the data tracker because it's gotten that has also gotten a little 
bit of lack of clarity of which events land on the official agenda 
and which ones do not. It seems like an area that's kind of ripe for 
a bit of an evolution in terms of how we represent things on the 
agenda for clarity purposes. I see we have Spencer at the mic Spencer 
go ahead.

Spencer Dawkins (remote): I wanted to say a couple of things. We've 
been talking about stuff like this for a while. One that came out of 
discussions was the HotRFC session Sunday night where you can talk 
through an idea very quickly. To provide a preview of what 
discussions will go on all week long [garbled]. The two-BoF limit is 
a BCP. It would take one sentence to change that. [garbled].

Alissa: Thanks, Spencer. Okay Barry I think you're next.

Barry Leiba: hi this is Barry Leiba, but I had one thing to talk 
about but I want to follow up on this thing first. We have done more. 
The IASA 2.0 BoFs, there were more than two of them. As a general 
thing I think the IESG has gotten better in recent years at doing the 
right thing even when the right thing is not exactly along the letter 
of something that's written. I think we should continue that. One of 
the things that the other guy mentioned was getting having the 
ability to have remote participation in minutes and things like that. 
When we have a side meeting however large or small it is, it's not 
connected to the rest of the community very much and I think I'd like 
to encourage the IESG to be more lenient about approving BoFs 
realizing that there are real scheduling issues involved here, so 
that more of these site meetings can be accessible to the community 
in those ways. The other thing I wanted to come back to the RFC++ BoF 
but in a completely different way and kind of related to this. I 
really liked that it was scheduled with nothing alongside it and this 
has been something I've pushed on for a while that Gen Area BoFs 
conflict with everything, and yet you know there are always other 
things going on. Again realizing that there are real scheduling 
issues involved. I'd like to encourage you to make the first edition 
of a gGen Area BoF as conflict-free as you can manage, because it's 
really helpful to be able to get the background.

Alissa: Thank you. I think Aaron was next.

Aaron Falk: I have a new topic. So my principal area involvement in 
the IETF is the transport area and transport is obsessed with finding 
qualified area directors. Because it's been a challenge for years. 
And one of the changes that I've seen I think across the whole IESG 
has been a real effort to reduce the workload to try to get to 
something that's closer to half time instead of close to full time. 
So this is a question for the whole IESG, as I'm wondering is that 
what you're doing and if you're if you're getting it down to half 
time are you able to keep up with your work? Is there stuff that's 
falling off the plate, what is it? You know if you have to 
prioritize, so what's not getting done? Is this a strategy that's 
working for us, or should we think of something else?

Alissa: I'm not able to go half time so you guys better talk.

Adam Roach: I was gonna comment. I think we have a mix of people 
between you know some of them are working halftime or there abouts 
some are working full-time I'm pretty close to full-time myself for 
example. I believe that Alexey is somewhat lower than that. But 
between among the three ART area directors we can cover the ART area 
because we have sort of that that mix that balance and I know that 
it's like we've we've given instructions to NomCom that we you know 
we can have people who aren't full-time but we can't have everyone 
not full-time.

Aaron: let me just add on to the list of things that I want to hear 
are you able to keep up with the reading? Do you know what's going on 
in your working groups?

Warren Kumari: Yeah I think as Adam said it depends wildly based upon 
the person I think it also depends a lot on how long you've been 
doing this for. I mean this is sort of my second year. At the 
beginning I was definitely overwhelmed, I didn't know what I needed 
to pay attention to. I still don't know what I need to pay attention 
to, but I'm less stressed about it. I mean I think that one learns 
relatively quickly which things you need to be paying a lot of 
attention to, which you spend less on. For me it's probably 35 or 40 
hours a week. So you know not really full time, maybe kind of, but I 
mean I know that there are a lot of people who manage to get this 
done in a lot less time. So I think it's how effective and how 
efficient you are. How much time you want to devote to it, you know? 
I am also good at procrastinating. So some of the time has been, you 
know, rearranging my desk and sharpening all the pencils. But as for 
am I managing to keep up with my working groups, I think so. I hope 
so. No chairs have complained yet. If I'm not, please come along and 
tell me. I'm not sure what snark Jim came up with, but I'm sure some. 
Does that answer your question mainly?

Ben Campbell: I'm kind of in the opposite situation I'm in my fourth 
year as an area director and due to some job changes I have 
historically had been 75% to full time most of the time due to some 
job changes I've been kind of forced to push that down to 50%. And it 
definitely has made some changes. I think it's doable. One of the 
things I've started doing is paying a little bit less attention to 
drafts that are outside my expertise and trusting the other ADs a 
little more and I don't give it much editorial feedback you that I 
used to give as far as keeping up with my working groups and things 
like that I've probably become a little more squeaky wheel driven 
than I was before. I have not been complained to, and I hope any of 
my chairs or working groups that need to complain to me will do so.

Alvaro Retana: Yeah so I think that what you're seeing is everyone 
experience varies a little bit. I think we all develop a little 
tricks and tactics of how to deal with the load. But what I want to 
add is that keeping up with the working groups and reading for the 
telechats, it's the only part of what we do. We are also responsible 
for a lot the policies around the IETF, and we need to talk about 
BoFs and agendas and a bunch of other things. So what that means is 
that at least in my case, that the load varies quite a bit. This is 
not that easy to say well I have every other week a telechat, and I 
have to read 600 pages for that. But it varies, because there are 
different topics and so I think it's important to keep that in mind. 
In terms of how much the ADs also want to be involved in those other 
discussions and those are the things. Which may mean driving some of 
the issues but it also means just you know commenting and keeping up 
on those discussions as well. so there's a lot more than just the 
telechats.

Eric Rescorla: I was just going to suggest that you should stand for 
Transport AD. Be the change you want to see in the world, Aaron. 

Aaron: Basically what I'm hearing is it's a full time job.

Eric: Seriously, I spend substantially less than full time. About 
30%.

Terry Manderson: If you don't want to stand for Transport Area AD, 
there's INT Area AD as well. I would absolutely I concur with all of 
my AD colleagues regarding the fluctuation of time. The other 
observation I would add, is that being an AD will happily chew up as 
much time as you're willing to give. So if you want to give all of 
your week, your weekends, your holidays, to being an AD, it will suck 
it up and it will love you for it. And the IETF will love you for it. 
But you must have some discipline. 

Aaron: Thank you.

Job Snijders: I'm a bit nervous about the topic I'd like to raise and 
I'll grant you safe passage when I said my piece because it means a 
bit of extra work for all of us. I've noticed that there is a 
significant stream of documents on the standards track that are 
submitted to IESG that do not contain sections about raising 
awareness of running code, nor are companies with implementation 
reports. What I expect from an implementation report is quite simple 
that for each normative term in the draft, a implementer indicates 
compliance, not compliance, not applicable, or something else. And 
these reports are incredibly helpful especially with large protocol 
extensions or protocol modifications to assess the readiness and 
operational considerations of said protocol. So this means that I 
wouldn't want to promote the idea of having running code before are 
submitted to the IESG. And I know some companies consider this a 
chicken egg situation where they're like well we don't want to step 
resources on something that's not solidified as an RFC. But on the 
flip side I want to encourage people to basically put their money 
where their mouth is, and if you believe in an idea you should 
implement it on a data branch or something internal. And I'm not 
asking for open source, I'm asking for running code. Because I think 
the step next strike predominantly is about interoperability and if 
interoperability cannot be demonstrated, I wonder why it's in IESG 
review when it comes to protocols. So my question to you in review 
would it be possible to put more emphasis on researching whether 
implementations exist and what their status.

Alissa: Thanks. Go ahead now Alvaro.

Alvaro: Sure so I agree with you in principle. I think they just like 
every time I agree with you it's in principle only. Yeah we are the 
IETF, right we believe in running code. I think that you have RFCs 
that have talked about implementation sections, for example. in the 
routing area we have several working groups that require 
implementations. Specifically IDR requires two implementations and 
implementation reports and everything else, which is actually what 
you just said. For every SHOULD and MUST, someone documents how that 
works for that implementation. On the other hand, I think that that 
this is one of those topics that is probably better discussed on a 
working group by working group case, where in some cases it is maybe 
more important to have those specific requirement to have 
implementations in other cases it may not be. So even for the routing 
area we have IDR which requires two, others require one, others ask 
the questions but it's not consistent. I will argue that from the 
point of view of timeliness for example, of getting the documentation 
out on producing actual results from the IETF. Sometimes waiting for 
implementation might take a while. I understand your point that if 
people don't implement, then maybe it means we don't need that. So 
it's just either one of two things one is specific working groups 
talked about the specific needs. If you think that there is something 
that we really need from an IETF point of view that would change the 
requirements of how the standards track RFCs are produced and 
qualified. Which would mean a proposal right, so you write something 
down and get the community to talk about that. 

Warren: Following on from that I think that this is best handled on a 
working group by working group basis, and sometimes on a sort of 
case-by-case basis. Some documents, even standards track documents, 
don't contain stuff that can really be implemented. More talks like 
you know how you do stuff. When this was first discussed in DNSop I 
was somewhat resistant to it but recently I've got a document that 
I'm co-authoring with Duane Wessels, which got implemented in the 
Hackathon. And somewhat because of what had been suggested, people 
wrote back you know this bit is not clear when I tried to implement 
it, and when I tried to include this, this bit is not clear. So I 
think this is you know case-by-case, working group by working group. 
But I think that there is definitely value in even if it's not a 
formal implementation report. Just, you know, implementers providing 
feedback. I tried to do this and I didn't understand what on earth 
you meant in section 12.

Eric: Yeah I certainly think imitation is pretty important I think we 
shouldn't confuse that with implementation reports. Speaking of some 
protocols I've been involved with both TLS13 and QUIC like seven to 
ten independent implementations that have some degree of 
interoperability, and you know one three is already an RFC, we're 
already a pretty substantial fraction of lights no loss traffic. I'll 
be pretty sad if we have to spend the amount of time would take to 
document every normative every 2119 term in the documentation. That's 
a lot of bookkeeping.

Job: I can sympathise with the reasoning that this is working group 
by working group, but I think as a default I think the IETF should 
encourage implementation. It should perhaps be a working group by 
working group opt out. 

Ben: So I pretty much agree with the choir so far, that this should 
be a working group by working group thing. But I'm gonna give it a 
little bit of a counter opinion, is that I am nervous about putting 
more structural barriers into getting drafts to Proposed Standard. I 
think if we're going to, and I agree if there are implementations 
having the reports is really good, but one of the big differences of 
between Proposed Standard and Internet Standard is an Internet 
Standard does require at least two interoperable implementations. And 
maybe one way to look at dealing with this thing is to once again 
we've talked about this many times but once again talk about 
progressing things from Proposed Standard to Internet Standard. 

Job: In DNSop there are only Proposed Standards, not Internet 
Standards, so in my mind having two implementations should be in the 
weaker category. Pushing this is into Internet Standard, but I would 
love to see more push for implementation earlier in the process. 
Thank you.

Warren: From so last bit on the opt in versus opt out, etc Oh a while 
back I can't remember when I think it's actually all of routing had a 
requirement for to two implementations but then there was a RFC 
published I think by Fenner wrote it, removing that as the 
requirement. And going back and looking at the history for that would 
be interesting. The way that that happened though was there was an 
RFC published. I think if you're proposing this what would be 
reasonable is write it up in a draft and we'll discuss it and 
everybody can chime in and then we will have basically sent text. 

Alissa: RFC 1264 created the requirement, and 4794 eliminated it. So 
might be worth looking into this as well. Thank you, Deborah, for 
sending us the numbers. I think Kerry was next.

Kerry Lynn: This goes back to Shane's question.  You mentioned at the 
outset that there's going to be some agenda experimentation at the 
next IETF, reserving Friday as sort of a day for proforma meetings. 
I'm wondering if you and the IESG, if you have any thoughts about how 
structured those meetings will actually be. And whether we will be 
able to use resources like MeetEcho to actually include external 
people. I'm thinking if this becomes really an interesting trend lots 
of meetings ad hoc and in the final day, things may spill over into 
the final weekend or the following weekend. Not extending this you 
know even longer. Anyway, what thoughts about structure and 
resources?

Alissa: So people can correct me if I have it wrong but I think the 
plan is to have some rooms that have MeetEcho and projection, your 
typical kind of facilities for a regular working group meetings. I 
think that's what we wanted to do but just give people more 
flexibility to schedule them ad hoc. 

Mirja: So I think about structure at this point it's very 
unstructured because it's an experiment. If more structures needed or 
whatever is needed it's something we'll learn from this experiment 
but I have also heard ideas about for example research groups taking 
the opportunity and have like a whole day meeting on that day in 
these kind of things. I'm really excited to see what will happen.

Alissa: I think you're next Phil.

Philip Hallam-Baker: this has been one of the best IETF meetings I've 
been at you know every you know never run out of food at any of the 
snack breaks. Every meeting has been in a room that's been of us a 
reasonable size. You know everything has just worked. And you know 
congratulations for the people who organized that. But I was saying 
that both because I also want to give my thanks to Aaron for 
organizing the HotRFC, which I have found to be very useful. Because 
it's connected me with a lot of people who are interested in the 
ideas I presented that you know their security ideas, but are not 
really relevant inside the security they're relevant in applications 
that might have a requirement. I think that that's an experiment that 
does work. To go back to the first question about ad hoc meetings. If 
I'm designing a protocol I do not invite a hundred of my best friends 
to design it with me. The reason I come to IETF meetings is because 
if you want to affect the Internet, you don't need a hundred people 
to design a protocol. But you need a hundred people bought in to 
start deploying it. So I think there's always got to be some times 
when you're going to say a small group is going to go off and work on 
the focus thing alone. And you know that's just the way that you have 
to do so you can move fast. However when people do that they have to 
bear in mind that the decisions they make in that cabal, have to be 
you know they have to be sensible to the people who weren't allowed 
into the cabal. and that's not a decision that they made in private 
that is a proposal that they've made in private so that they don't 
waste the time of a hundred people thrashing out things in a forum 
that aren't ready to be thrashed out. So I think it's a question of 
tone and acceptance of the fact that you're not making decisions.

Alissa: Thank you. Just to tie your two of your comments together, I 
think part of the reason this venue is so great is because it has so 
many spaces where small groups of people can sit down and have the 
kind of conversation that you're talking about. So thanks. John.

John Klensin: Two quick questions I'm not going to make speeches 
tonight. The first is that as we look at meeting participation 
figures, we're seeing an increased number of remote participants on 
whom we're getting more and more dependent. Including I noticed 
tonight for good or bad reasons IAB and IESG members. We've got a 
number of procedural bars to treating remote participants as full 
participants. And I'm wondering as a very general question when or if 
the IESG intends to address that question. The second question, 
somewhat related actually, is that you mentioned during your summary 
that there's an appeal pending. That appeal interacts with some of 
the things that come up tonight about the openness and transparency 
of the leadership process. I'm wondering what the IESG's timeframe is 
for addressing it.

Alissa: So on your first question can you just elaborate about the 
barriers I just want to make sure I understand.

John: We've got a NomCom which will not allow remote participants to 
participate. We have a number of things tied to the NomCom 
eligibility rules which discriminated against from most participants 
unless they're getting to most meetings. We have historically done, 
as others have mentioned this evening, a number of semi informal but 
not very informal because they're officially authorized meetings 
which do not allow remote participation. I don't know if that's a 
problem or not, no question is really not that I'm looking for 
particular solutions, it's that I'm asking if the IESG considers this 
important enough to address, and if so, what the time frame is.

Alissa: Thank you. So I think just on the issue of general 
interaction between remote participants and in-person attendees at 
the meetings the way that the IESG has thought about this is that we 
are fully supportive of the remote participation facility. We think 
it's great we think it's you know it's been extremely effective at 
helping bring new people in and support people who can't make it to 
the meetings and so forth. We do like to optimize if we have to have 
a trade-off between the accommodating remote participants and 
accommodating people in the room, if we're going to be in the room 
we're optimizing for in the room, if we have to make a trade-off. But 
in many cases we don't have to make a trade-off so that's good I 
think on the issue of NomCom eligibility that's a real issue. At 
least in my mind there's been a few others pending large 
administrative matters before the IETF, and it's hard to do too many 
of them at once. But I do think it's something that we need to talk 
about and potentially address in the future. It's definitely 
something for us to take on.

John: As I tried to say I'm not chastising you for prioritizing other 
things, I'm just hoping this will not get postponed forever.

Alissa: Fair enough anybody else? Okay. Oh the appeal. Sorry, yeah, 
so we are discussing the appeal. We discussed it this week we're 
working through our response which we intend to have out in August. 
That's based on vacation schedules and so forth. I think you're next, 
Glenn.

Glenn Deen: So the person who helps organize a side meeting every 
IETF, one of the challenges I have is getting people to know where it 
is, and be able to find it. While we do announce things over email it 
gets lost in the clutter of the actual IETF week. We all get so much 
email it would be a big help even if you label it as this is a 
totally unauthorized ad hoc thing that's going on that we have no 
control over so you're in scary territory, a slot somehow on the 
official agenda structure so you guys should say we're in this room 
at this time talking about this. If you want to come, come. if you 
don't want to come, eh. But that would be a really big help in 
coordinating these little side meetings. It would also give the 
opportunity for a bigger part of the community to be aware of where 
they are, and put them in a schedule when laying out the schedule for 
attending and planning out their IETF week.

Alissa: Couldn't agree more at least from for me personally. 
Kathleen? 

Kathleen Moriarty: Just a quick suggestion as you go through the 
appeal, or a question, have you considered just reissuing the ballot 
on the conflict review, since so much research and discussion has 
happened? It should be quite straightforward. It would be an easy way 
to round that out.

Alissa: So I don't really want to speak to the details of it because 
it's in process. 

Kathleen: I just wanted to provide that as a suggestion because I 
think it would be a reasonable way to handle it. 

Alissa: Thank you.

?: So this week we had the ANRW. I think it was a great way to mix 
the in to open the idea of community to the research community, so I 
think having this workshop during the week was a good thing. The 
other thing I'd like to mention is that the AMS a set up a recycle 
badge here, which guess what it's here to recycle the badges so I 
would like us that we try to feel this being, and not being the only 
one putting my badge there. So on Friday morning put your badge in 
this bin. Thank you.

Alissa: Okay no more questions for us so I'll invite the IAOC to come 
on up. Thank you.

Glenn: We have one question I love this. Mike, bear in mind I've only 
been IAOC chair for about forty or fifty hours or so. So go easy on 
me. 

Mike StJohns: Its about the IETF logo on our badges. Why did they 
shrink, and can we get them back?

Ted: are you arguing against recycling these badges, Mike, right 
after everybody clapped?

Mike: I'm talking about the size of the printed logo.

Glenn: I had not noticed. I do not know why they got small.

Bob Hinden: Congratulations and condolences. This is a great venue 
and I think we should come back again and again. Thank you.

Glenn: You know one things I've loved about this venue is the huge 
amount of open seating for us to sit down and talk to each other 
that's wonderful.

Terry Manderson: The venue is great, but the bar hours are shocking. 
We have a drinking culture here in the IETF. Socialize around drinks 
and ratify decisions at drinks. I know you have no sway over the 
hours here.

Glenn: I'm not worried with the hotel bar hours here. I believe the 
hours of Montreal is 3 a.m.

Terry: Its not the end time, it's the start time (bars not open early 
enough).

[Laughter]

?: For travel budgets putting the Asia meeting at the end of the 
year. Hits the end of year travel budgets get cut. Trying to organize 
the meetings for more expensive meetings at the beginning of the year 
and easier to get to at the end and see how it impacts attendance.

Glenn: Yes that's a very good point. It's something we have observed 
internally as well so we have discussed experimenting with switching 
to a slightly different rotation where we might do Asia as the March 
meeting right now we have booked out through 2021. Most of the venues 
are in negotiation with venues already, but past that date we're 
looking at doing that exactly experiment you're suggested. Yes Bob.

Bob Hinden: Just to also respond to that so that's a very one region 
view of it. If you live in Asia having a November meeting is great. 
So you know it is about balancing the pain. There's just  not unless 
you want to just rotate there's no way to solve this.

Glenn: That's absolutely true. As I say, if we do it, it will be an 
experiment. We'll see how it goes. We've tried this way for a couple 
years, and as you know if you look at ahead in the schedule while we 
do try to keep to the schedule of North American March, Europe in the 
summer, and in Asia in the fall, we don't always do it, even now. We 
do mix them up. The fact that we're here in the summertime and not in 
Europe right now is a bit of a change for us. So why say we're 
considering the experiment we're going look at it. The big thing that 
really influences our choice and our ability to meet at a particular 
location is the availability of meeting venues that we can go to. One 
of the challenges we have faced in Asia is the availability of venues 
that meet the IETF requirements in November. And so one of the 
reasons what other motivations we're doing, is to look to see if we 
start going to Asia as an experiment in March, if that opens up new 
venues that we can't access currently because they're already booked 
many years out in advance by other groups. Going once, going twice, 
gone. 

John Levine: Glenn before you go, I might mention that if the 
schedule for the LLC goes more or less as proposed, this may well be 
the last time we see this IAOC. 

Glenn: If that ends up being what happens I will think I hold the 
distinction of being the shortest serving IAOC chair ever. 

Alissa: Thanks everyone enjoy your evening.