Skip to main content

Minutes for IESG at IETF-85
minutes-85-iesg-opsandtech-1

Meeting Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2012-11-07 21:00
Title Minutes for IESG at IETF-85
State Active
Other versions plain text
Last updated 2012-12-12

minutes-85-iesg-opsandtech-1
IETF 85 Plenary Minutes
Atlanta, GA, USA
Wednesday, 7 November 2012

Minutes by Cindy Morgan, IETF Secretariat

1. Welcome

Russ Housley welcomed the audience to the IETF 85 plenary.

Based on community feedback after previous plenaries, the Operations and 
Administrative plenary was combined with the Technical Plenary, and a 
format with reduced reporting was used.  The reports include links for 
interested parties to find additional information if desired.

2. Host Presentation

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-12.pptx

Jean-François Mulé accepted the host plaque on behalf of the North 
American Cable Industry.

3. Reporting

3.1. IETF Chair

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-13.ppt

3.2. IAOC Chair and IAD Report

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-14.pptx

3.3. IETF Trust Chair Report

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-15.ppt

3.4. IAB Chair Report

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-3.pdf

3.5. IRTF Chair

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-0.pdf

3.4. NomCom Chair

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-16.ppt

4. Awards and Recognition

http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-17.ppt

Jun Murai introduced the Itojun Service Award and announced this year's 
winners: John Jason Brzozowski, Donn Lee and Paul Saab.

The winners thanked the committee and encouraged the community to keep 
deploying IPv6.

5. Technical Topic: Internet Performance Measurement

Alissa Cooper introduced the technical topic for the plenary, Internet 
Performance Measurement.  Two presentations were delivered: 

- Sam Crawford, "SamKnows" 
  http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-7.pdf

- Henning Schulzrinne, "Large-Scale Internet Measurements for Data-
  Driven Public Policy" 
  http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-8.pdf

At the end of the presentations, the microphones were opened for 
questions from the audience.  A summary of the Q-and-A session follows:

JUN MURAI: I have question for  Henning.  I agree with what you said 
about measurement being key, and it's going to be important.  We've been 
working for a long time in the past on the measurement of the Internet, 
and the measurement work in research has been confused in many ways.  
There is the business secrets concern, and also the government concern.  
What is your suggestion, being the FCC in America, to have non-Americans 
join you?  What is your encouragement to the rest of the world?

HENNING SCHULZRINNE: It depends on which audience you're talking to.  
We'd be happy to talk to any of our colleagues, so if you want to send 
them our way we can certainly talk about our experience.  I believe we 
have demonstrated two things, namely that it doesn't have to be an 
adversarial relationship; it's not a regulator versus the ISP type of 
thing. It can be a collaborative relationship where everybody benefits.  
And, it is something where we can show that it actually helps 
performance improvement, which presumably everybody benefits from.  If 
we do our job here, even for smaller countries where it might be 
difficult to set up a completely new infrastructure, hopefully they can 
all just ride on larger efforts.

OLAF KOLKMAN: I was very happy that your presentation drove home the 
point that the goal is that good policy needs good data.  That's an 
important message.  But what is there that we can learn by doing good 
measurement with respect to Internet architecture?  Is there anything 
you've seen in your measurements that we can use in our protocol and 
architecture development in the IETF?  

SAM CRAWFORD: Our focus so far has been on over-the-top measurements, 
looking at the various aspects of performance, rather than features.  
But it's something we're exploring right now.  There are a couple of 
initiatives we are looking at.  One is around, not just DNSSEC support, 
but DNSSEC compliance or grading.  And another is around IPv6.  We've 
already been doing some extensive IPv6 measurements in Singapore.  We've 
seen some interesting differences between v4 and v6.  Not just 
performance, but how the different networks behave with each other.

HENNING SCHULZRINNE: I'm not sure we've learned anything inherently 
about Internet architecture as an abstract entity, but what we do learn 
is about what really happens to the stuff that we build around here, in 
the real world.  The assumptions that some of us may have are just no 
longer reflective of reality, and so it provides us also an indication 
of the kind of spread of parameters that you see in the real world.  
That might lead us to have better diagnostics tools in some of the 
protocols that we build, it might make us think about making it easier 
for protocols to be measurable, and it might (as we progress documents) 
give us an indication that certain features are particularly problematic 
and we might want to look at them again.

ERIC VYNCKE: Most of the measurement right now is in the network layer.  
You talk about IPv6, but you don't talk about the doom days of CGN.  
What is the support of non-TCP and UDP in the transport layer?  Do you 
measure only the subscribers behind CGN?  And if they are behind CGN, 
how many TCP and UDP sessions do you connect?

SAM CRAWFORD: No, we're not measuring how many subscribers there are in 
those areas.  With all of these studies from regulators, one of the 
first things we do is a sample plan highlighting which areas we're 
looking for from customers, and this goes to where the ISPs have their 
customers.  We build the panel around that, so if there is a 
concentration of users in one area, then that is one of the aspects 
we're measuring.  With regards to how many TCP and UPD sessions, it 
varies by region.  We do typically use multiple concurrent sessions in 
order to overcome limitations.

ALISSA COOPER: But you're not measuring the maximum achievable.

HENNING SCHULZRINNE: Let me see if I can twist the question a little 
bit.  We do TCP and UDP, but there are other protocols out there that 
people want to use, SCTP being one, for example. I think this an 
emerging area where there is just starting to be an awareness that 
broadband is more than speed.  And from a regulatory perspective, 
because it's easier to explain speed to policy makers who might be 
lawyers and economists that like nice round numbers, as long as it's 
broadband and has some speed, the Internet must all be the same.  Since 
we're no longer concerned with just the availability of broadband, but 
what do you do with it, innovation, all of that.  Clearly, if you look 
at our Internet principle work, we call out the need for networks that 
are not constrained in their abilities.  Increasingly, this is not 
something that we have a work plan for.  We will be looking at how to 
characterize the evolution of what you can do with the network as 
applications emerge.  Much of what we do is driven by the questions we 
get asked.  The measurement collaborative is an open one.  If interested 
parties have something to contribute, we encourage them to participate.  
We encourage people to approach us with the issues they see in ways that 
may not be consumer-obvious.  

MICHAEL RICHARDSON: Yes, performance is not the only thing.  Are you 
measuring latency?  Are you able to measure it with your current system?  
From what I can tell, that power-boost stuff is actually a cause of 
trouble rather than a feature.  It's great to hear that performance is 
more than speed, but what numbers can we really use at the end, and can 
you measure them at this point?

SAM CRAWFORD: Yes, we are measuring latency. We're measuring effectively 
to the nearest point of Internet exchange, to the nearest hand-off from 
the ISP. So yes, we're capturing that, and a whole bunch of other 
metrics as well.

HENNING SCHULZRINNE: Are you talking about buffer-bloat issues?

MICHAEL RICHARDSON: Yes, exactly.

HENNING SCHULZRINNE: So yes, we have one measurement that is the latency 
under load, which is an initial attempt to identify the presence if not 
necessarily characterize the full extent of this type of load-sensitive 
latency, as opposed to the standard transmission layer, DSL and coax 
type of latencies that you measure.

MICHAEL RICHARDSON: So you're presenting two speeds, is what you're 
saying? Basic speed and speed under load?

HENNING SCHULZRINNE: Yes.  And that's probably an area where additional 
work here [in the IETF] would be most helpful.

ROBBIE SIMPSON: I think the area of Internet measurement research and 
standards work has been going on for quite some time.  Some time ago I 
started a project called Net-E at Home, and I thought we were sitting on 
a gold mine of data at the time, but unfortunately we couldn't share the 
data because of the privacy issues.  Has the FCC or any other regulatory 
body published any guidelines on what measurements you think are safe to 
share?

HENNING SCHULZRINNE: We've thought a lot about privacy issues and 
struggled internally about what you can reasonably disclose, because we 
want to disclose pretty much whatever we measure, including IP addresses 
and everything.  So we did have some lawyers look at that.  We arrived 
at a conclusion which I'm not sure I can generalize, simply because 
national laws matter.  In the U.S., national laws are often not well-
defined for these types of things.  There just isn't a law to address 
that.  What is a potential risk and impact?  How much informed consent do 
you have?  So we intentionally pick active measurements as opposed to 
passive measurements.  We only measure when there's no other activity 
going on.  We pick what you might call the easy part.  We are currently 
working with a number of privacy experts for the mobile piece because 
that is an order of magnitude harder.  You have the conflict between 
needing the location and not wanting to disclose the location as part of 
your measurement data.  

BERT WIJNEN: I think this is a good start.  It's unfortunate that 
Henning's presentation was very U.S.-centric, but at least we get the 
idea of how you guys do it over here, and we can see how that applies at 
our place.  I think people have already mentioned that we need to do 
more than just bandwidth management.  In the BOF that we're going to 
have, we can probably find out if we can define some standard protocols 
or data formats.  So, a shameless plug for the RIPE NCC Atlas Project, 
which already does traceroutes, pings, DNS queries, HTTP GETs and what-
have-you.  For example, we did see data with Hurricane Sandy. You can 
also do user-defined measurement, but of course that gets into security 
and all that stuff.  They user-defined measurements that do allow people 
to see something happening in the small scale in their environment that 
allow them to set up a quick measurement that will check things around 
the area where they see things happening.  

HENNING SCHULZRINNE: I look forward to becoming aware of other projects.  
There's a number of these efforts.  Every country has at least one 
project.  The EU seems to like to do that.  I'm hoping that if we start 
that LMAP effort here that the experience can be introduced.  I 
apologize for being U.S.-centric, but I don't want to pretend to speak 
for other policy bodies.  

BERT WIJNEN: Right, but if we can define interfaces to all the data, 
then that will allow us to correlate measurements that SamKnows does 
with RIPE Atlas stuff, etc.  And that would give us a much better 
insight into the performance for the user, but also if there are any 
problems, wherever they may be.

ARTURO SERVIN: Last week, there was a presentation on some of the 
research we are doing in Latin America, and Patrik Fältström went to the 
mic and said that this was the 5th presentation he'd seen on measurement 
in the last week.  Initially I thought he was exaggerating, but it's 
been a week, and this was my 4th one.  Indeed, it seems like there are a 
lot of people doing measurement, but there is no data, so we have to do 
our own research.  So this is more a comment, that we need to start 
finding some common ground amongst each other, because there's a lot of 
money and effort expended here.

HENNING SCHULZRINNE: Certainly we hope to make it easy for people to do 
their own measurements by taking care of the boring bits, so that 
researchers can focus on the interesting statistical issues.  That's 
certainly one of my goals.

PATRIK WALLSTROM: At .SE, we have been doing these kind of measurements 
for the past 1.5 years.  We have 30 or so probes that we have on 
different connections, and we've been measuring from all these 
interconnecting connections.  What we have found is that we see a lot of 
filtering in bittorrent and VoIP protocols, but for different reasons 
than you might think.  One example is that you see the filtering only 
where the traffic is expensive, for example traffic going though a 
trusty operator.  One other example is on your mobile network--on some 
of the best mobile networks in Sweden, you see the most filtering.  So 
that's data that you have to analyze and see the reasons for.

HANNES TSCHOFENIG: I would like to touch on the architectural aspects.  
As a protocol designer, you have to take limitations in the deployment 
into account. There are different academic papers on the inability to 
get, for example, the IP options through the network, ECN, etc.  Some 
believe you have to use HTTPS nowadays to get any application protocol 
to work in all the different networks.  Have you done some measurements 
that would actually give us any large-scale data on this? Because I 
couldn't find anything.  

SAM CRAWFORD: This comes with the features Henning was talking about.  
The short answer is no, but it's something we want to.

HENNING SCHULZRINNE: This is an open invitation.  We may not be able to 
do everything, but if you have things that you worry about, if you think 
something is not being deployed as widely or is being suppressed by 
intentional or unintentional actions, that's useful for us to know.  I 
would be happy to talk to you about that.  We can talk offline.  I do 
believe there was at least one IMC paper that looked at ICMP options a 
few years ago.  We have very little visibility into what survives the 
trip across the internet these days.

6. IAB Open Mic

Bernard Aboba introduced the IAB:

- Bernard Aboba, IAB Chair
- Jari Arkko
- Marc Blanchet
- Mary Barnes, IAB Executive Director
- Ross Callon
- Alissa Cooper
- Spencer Dawkins
- Joel Halpern
- Russ Housley, IETF Chair
- David Kessens
- Danny McPherson 
- Jon Peterson
- Dave Thaler
- Hannes Tschofenig

Bernard Aboba noted that this plenary was a big change from the past, 
since the administrative portions had been condensed and combined with
the technical plenary.  He called for a show of hands for whether we 
should do this again.  Many hands were raised in favor, with a few
hands raised in favor of the old style.

Lars Eggert (as IRTF Chair) and Heather Flanagan (as RSE) joined the IAB 
on stage for the open microphone session.  A summary of the open 
microphone session follows:

BERNARD ABOBA: We are now opening the mic to questions for the IAB.

LEE HOWARD: I noticed--and this isn't just the IAB report--but all the 
presenters in the Administrative Plenary side said they would keep it 
short because it is their presentation is boring.  If you think it's 
boring, don't waste our time.  So why do it at all?

DAVID KESSENS: Some presentations have to be done that are boring.  
Think about the IAOC presentations.  This is the money that's being 
spent on the IETF's behalf, and we should be interested in it, despite 
that the presentation itself is boring.  We can't help it.  But some of 
the financial stuff you just need to know about.  There's certain stuff 
that has to be done and trying to put it in a little corner somewhere 
doesn't work.  We need to be open and transparent; that's how this 
community works.

ERIC RESCORLA: Obviously, this is information that has to be public.  
The question is why it has to be presented verbally.

BERNARD ABOBA: Is there any particular thing that you'd like to hear 
less of?

ERIC RESCORLA: I'd like to hear less of all of the reporting.  I'd like 
to see a URL for the reporting, and open mic other than that.

JON PETERSON: There could be more hums to see if the community is 
interested in that.

BERNARD ABOBA: That's not a bad idea.  But I'd hate to be at the IAB 
plenary and make judgements on the IAOC.  So just in terms of the IAB 
slides--we had 3 slides this time.  How many of you would like to see 0?  
(Noone raises their hands).  We'll take that as confirmation.

SPENCER DAWKINS: Back to Lee's point, I feel your pain--but you don't 
actually want the IAOC report to be exciting.

[Laughter from the audience.]

JOHN LEVINE: I'd like the report to be either longer or shorter.  If 
it's just going to be, "Here's what's on the web page," it could be 
shorter.  On the other hand for the IAOC, I was intrigued that the first 
page said our revenue was up and costs were down, and we had this 
$500,000 surplus.  And the next slides said, "We're probably not going 
to raise the price."  Some analysis would have been helpful here.

RUSS HOUSLEY: Can we talk about this with the IAOC on the stage?

JOHN LEVINE: Sure.

MARCELO BAGNULO:  Maybe it would be better to do technical plenary 
first, and admin afterwards so that the people who are not interested 
can leave and look at it offline.

JOEL JAEGGLI: One thing we forget is that the consequence of this 
organizational function is that instead of being run by Bob Kahn or CNRI 
is that it's actually being run by the people right here in the 
audience, and the IAOC, and the people that we appoint.  So, the fact of 
the matter is that it terrifies me that people like Eric Rescorla are 
responsible for running this organization--but that said, he's not doing 
that bad of a job.  

[Laughter and applause.]

JOEL JAEGGLI: We have the cookies, we have an administrative plenary 
which is tolerable, and we have a process that hasn't caused the IETF to 
go bankrupt.  It needs a certain minimum amount of engagement from the 
people in this room, because some of you will be serving on the IAOC in 
the future, some of you will be serving on the IESG, and some of you 
will be serving on the IAB.  You need to be engaged here, even when it 
isn't interesting.

[Applause.]

DANNY MCPHERSON: Back to Lee: most of what we do isn't sexy.  This is 
the "exciting" boring stuff.

[Laughter.]

LEE HOWARD:  Joel, I see no need to make threats that some of us will be 
serving on these various bodies in the future.  My comment may have come 
off as flip, and maybe was misconstrued.  My point was really about the 
apologies that the presenters were making.  There's information here 
that is interesting, and maybe we should focus on the information and 
not the data.  It is interesting how this stuff happens.  Making sausage 
is neat stuff--if it's your thing.  I'm not saying we shouldn't be doing 
the things that need to be done, but that this can be interesting, and 
can be made interesting by saying, "Look, here's the change in fees 
based on the analysis that we're talking about."  This is good stuff.

THOMAS NARTEN: What would you rather have: boring presentations that are 
short during the plenary, or really exciting stuff on the website that 
no one reads?

ERIC RESCORLA: Hypothetical question: you guys all sat through that.  
Could you pass a test on this stuff?  Could you reproduce any figure 
other than the $500,000 one?  Because if you can't, this was a total 
waste of time.  This would be fine if people were assimilating the 
information in any meaningful way.  But they're not; they're just 
sitting through it, zoning out.  Ask yourself if you could reproduce any 
significant piece of information you've just heard.  And if you can't, 
then it was a waste of your time.

LUCY LYNCH: Data point: we held an interim meeting.  We had 36 
attendees, plus 23 remote [attendees].  Work got done.  It cost us 
$18,000.  It wasn't all that successful.  Data points from the slides.

[Applause.]

KEITH DRAGE: Just a request: for the reports that you don't give, like 
the RFC Editor--can you put them in the meeting materials rather than 
just links in the slides?

JOHN KLENSIN: I didn't sit through this and zone out.  I found it a very 
interesting and useful presentation.  I have certainly sat in other 
plenaries and zoned out.  Part of your obligation as the IAB is to 
present these things in ways that are useful to us so that we know them 
even if we don't want to know them.  We need to know them anyway.  If 
some of us are so omniscient that we don't need any of this information, 
then we shouldn't be spending more time in the plenary; we should be 
spending more time in the bar.  But the rest of us actually do 
appreciate at least some of these presentations.  They may be important 
to some of us who don't appreciate them but may need them anyway.  I 
personally believe that we have gone downhill since we were using more 
plenaries which contained more information which was useful to large 
fractions of the community even if we didn't think we needed to know it.

PHIL HALLAM-BAKER: I'm getting wrapped into this meta-meta discussion.  
We're currently having this Internet Governance Forum going on.  All of 
the pre-meetings going on ahead of this ITU WCIT thing.  There's some 
serious issues there that need to be discussed, and given the people 
here in this room, I would liked to have been discussing those.  
Regardless of what you may think that process has to do with this 
organization, another way that you can look at this process is that the 
plain old telephone system [POTS] is dying.  And it's taking the 
institutions of that system with it.  Those systems are linked into 
governments.  My company has been attacked by a state actor.  We've had 
another member of the CA family attacked by a state actor.  We've had a 
very large corporation attacked by its own government--by the government 
of the country that we're now in.  There's a lot of serious issues that 
I think we should be addressing.

BERNARD ABOBA: We did have a proposal for a plenary which we didn't 
do this time, but which we could do in the future, about the issues of 
transitioning from POTS to IP.  How many would like a plenary on the 
subject Phillip just mentioned, the death of plain old telephone 
service?

[Lots of hands up in the audience.]

BERNARD ABOBA: Wow, a significant audience.  Okay, thank you.

LESLIE DAIGLE: I would like to say that I did get information out of the 
brief administrative reports presented earlier, and I found them useful. 
The part I wish had been shorter was the rehashing of the plenary 
length; I don't think we've learned anything tonight about what the 
plenary length should be.  The substantive point I want to bring up is 
in terms of the NomCom Chair's report, the articulation of what the 
NomCom is looking for in terms of useful input was very much focused on 
the IESG role.  Everyone here who is doing any work is interested in 
making sure we have a well-constituted  IESG.  And in most cases, people 
have had enough interaction with the IESG that they have an idea of what 
does and doesn't work in the IESG.  In a lot of cases, this [plenary] is 
the only interaction the community has with the IAB and IAOC, and I 
don't think that the community as a whole has a sense of what would or 
would not be useful in terms of skills and people represented on the IAB 
and IAOC.  So I would like to hear from the NomCom Chair if he's still 
around.

MATT LEPINSKI: If I had a brief articulation of what feedback would be 
useful for IAB and IAOC positions, I would have given it.  I think there 
is a lack of clarity in the community as to what makes good IAB and IAOC 
members, and what the NomCom should be thinking about in regards to IAOC 
and IAB members.  If you have any information about what you think the 
NomCom should be thinking about--we're talking to as many people as we 
can this week, and we'd love to hear from you.  But I don't have a 
clear, concise, "This is what we need to know" statement.  That's a 
problem in the community, and I don't know an easy way to solve it.

LESLIE DAIGLE: It's not a new problem, or a problem specific to this 
NomCom.  I'm so glad we're having this conversation, but could we have 
the discussion earlier next year?  Because it would be really good to 
get some of that clarity and get people focused on what we need here.

HANNES TSCHOFENIG: The charter of the IAB is laid out in RFC 2850, and 
it lists out the functions.  Everyone has a different perception about 
the importance of the different functions.  Some of them are about 
liaison relationships and interacting with other organizations.  Others 
are more on the architectural oversight function, which is topics that 
concern multiple different working groups or even different Areas, or 
concern work that isn't even happening today in the IETF that may be 
useful to be done in the IETF.  The plenary we heard today was one such 
topic, where we reached out to people outside the community to see if 
there is work to be done, bringing new blood to the IETF.  Different 
people have different perceptions on what they would like their efforts 
being focused on.  

BARRY LEIBA: Following up on that last bit: the IAOC in particular 
requires the sort of background that we don't usually see people in 
here.  Is it at all useful to hear how a person behaves in a WG when 
you're looking for contracts and business backgrounds and that sort of 
thing?

MATT LEPINSKI: Yes, it's difficult for the NomCom to get input on the 
IAOC because of the way that most of us interact with the people who end 
up getting put on the IAOC.  The NomCom is happy to receive an input, 
but with regards to the people that we're going to put on the IAOC to 
oversee the finances of the IETF and its contracts, it is not so useful 
to know how they performed in a working group.

JOE HILDEBRAND: One thing that makes the NomCom's job difficult is that 
we don't periodically have a conversation about why we're here.  What 
are we doing, what do we mean?  Why do we have an IETF, why do we keep 
coming?  Is it for the cool trips? Is there something we're trying to 
accomplish as a whole?  And because we don't have that conversation, and 
because we have a strange process (as compared to other organizations) 
for the choosing of our leaders, I think we should periodically have 
that discussion about why we're here.  If we knew that with some 
specificity, it would be easier to pick the people who are trying to 
forward that goal.  

OLAF KOLKMAN: If the NomCom and the community don't know what the IAB 
and the IAOC are doing, then maybe the plenary presentations are too 
short.

[Laughter.]

OLAF KOLKMAN:  Or maybe we have not been communicating well enough what 
we do.  I don't have good ideas about how to improve that communication, 
and I don't think the big plenary hall is the place to have that 
conversation.  If you don't know what the IAB and IAOC are doing, please 
ask.  It's part of this community, and this communication needs to be 
clear.  Set your requirements.  

BERNARD ABOBA: I'd like to ask an additional question of the audience.  
We have had suggestions from some members of the community that maybe we 
could use the remote presentation facilities from time to time.  If we 
were to have a technical chat, some introduction to the IAB, how many 
people would actually log into that and participate?

[A few people in the audience raise their hands.]

BERNARD ABOBA: Well, maybe our remote participation system could handle 
that, if we're only talking about 12 or so people participating.  Not a 
very big load.

[Laughter.]

PETER SAINT-ANDRE: I don't know if Eric has been paying attention in 
working group meetings, but the plenary has no monopoly on folks zoning 
out.

[Laughter and applause.]

PETER SAINT-ANDRE:  We need to focus more on the issues that require 
real-time interaction.  We should use this high-bandwidth connection to 
discuss what's really important.

[Applause.]

LESLIE DAIGLE: I wanted to follow up from Hannes's characterization of 
what the IAB needs.  I'll start by responding to Bernard's suggestion 
about open tech chats with the IAB.  This is going to come across as 
sounding a little rough, so please don't take it the wrong way, but I 
don't think anyone here wants to get to know the IAB personally.  I 
mean, I am fortunate enough to know many of you personally, so I have 
that advantage.  My point is more about what can you do?  What are your 
skills that you need to get your work done?  That's what the NomCom 
needs to know.  The IESG, when you fill an IESG seat, you don't just 
find who is the brightest spark or most intelligent person.  You're 
looking for someone who can sort out actual working groups.  And we're 
all familiar with that process because we've been on the other end of 
it.  We're not on the other end of the things that the IAB does.  While 
I appreciate that there are lot of policy things coming up, I think that 
it's not a question of finding particular expertise and making this the 
panel the panel of Internet gods.  I think this group needs to be 
constituted in a way that you all work together, and that you can 
understand something outside of your own particular, which means that 
you're technical generalists at a certain level.  That you care about 
it, and you care about finding the right answers--that's not something 
that's going to convey in a tech chat.

BERNARD ABOBA: I would point out that the IAB has provided a very 
detailed job description to the NomCom, and for the first time in 
a long time, the NomCom has not asked questions about it.

HANNES TSCHOFENIG: Leslie, you forgot one really important part, which 
is that the person has the time to do the work.  Because that is 
generally the show-stopper, both on the IAB and the IESG.  If you don't 
have the time, then it really doesn't work.

DAVE THALER: I think as Bernard was saying, the job description contains 
some things, and I don't know how many people who provide feedback about 
IAB members have actually read the job description, but that's at least 
some answer.  It's a variety of skills that no single person would have, 
but collectively across the IAB, different skills that are necessary to 
have within the IAB: the ability to look at a problem you're not an 
expert on and make an insightful comment. Or things like being aware of 
the politics of different situations, like being aware of how different 
SDOs work, or how different governments work, or the effects of 
governmental-run organizations.  Just being aware of the politics is 
another whole aspect, and being a generalist there is also very useful.  
Collectively, these are they types of skills that are useful.

BERNARD ABOBA: And the job description has been changed substantially in 
the last three years, in particular to emphasize more leadership skills.  
So thank you all very much for your feedback.

7. IAOC Open Mic

Bob Hinden introduced the IAOC:

- Bernard Aboba, IAB Chair 
- Scott Bradner
- Dave Crocker
- Marshall Eubanks (not present)
- Bob Hinden, IAOC Chair
- Russ Housley, IETF Chair 
- Ole Jacobsen
- Ray Pelletier
- Lynn St.Amour, the ISOC President/CEO (not present)

A summary of the open microphone session follows:

MARC BLANCHET: We used to have live transcription during the plenaries, 
and that's disappeared.  Is there a reason why?

RAY PELLETIER: Originally we had the transcriber here because they were 
assisting someone here with a disability who could use that service.  
And then we broadened that to include the occasional other meeting, and 
then the plenaries.  And while that had some popularity, it's been gone 
for a couple of meetings now, and nobody complained.  It seemed like 
perhaps it wasn't of value to most folks.

JOHN LEVINE: You have a substantial surplus this year.  So why are you 
asking ISOC for less money rather than reducing meeting fees?  ISOC 
appears to have no shortage of funds, and for those of us who pay our 
own way here, while the fees are not unreasonable, they are not low.  
What's the overall logic for some of the meeting fees?

BOB HINDEN: I'm not sure exactly how we got to the $650 number.  It was 
increased about 3 years ago from $635, so we've tried to keep it fairly 
consistent.  But actually we're asking for more from ISOC for next year 
than we did for this year.  We are actually asking for more money, not 
less.

SCOTT BRADNER: The ISOC board took an action to increase funding in 
order to avoid raising meeting fees.

RUSS HOUSLEY: ISOC helps us find sponsors, and we had a lot of sponsors 
this year, so that's where the additional revenue is coming from.

JOEL JAEGGLI: I'm on the recall petition, but one question I have after 
reading BCP 101 and RFC 3777, is that when you're replacing mid-term 
people once you've created a vacancy, which the recall process does, the 
IAB reviews IESG appointments, and the ISOC board reviews IAB 
appointments, but no one reviews the IAOC appointments?

RUSS HOUSLEY: The IESG is the confirming body for NomCom-selected IAOC 
appointments.

SCOTT BRADNER: See RFC 4071, section 4.

JOHN KLENSIN: We make a big fuss about cross-Area review and cross-Area 
understanding.  Any time a mic line has to be closed, it's an indication 
the plenary is too short.  I'm old enough to miss the Monday morning 
plenary which would highlight the important things that were going on in 
the week.  I think we are damaging ourselves as a community if we keep 
shortening the portions that allow input from the community, discussion 
from the community, and technical review of important work across Areas.  

BERNARD ABOBA: It's an interesting observation.  To some extent, I was 
sitting up here telling people about things that had already happened.  
That did feel a little awkward, as opposed to Monday night when I could 
tell people about things that were going to happen.

JOHN KLENSIN: I think that the move of the IAB plenary to Monday and the 
ability to use that slot for forward-looking stuff was a real 
improvement.  But again, I'm one of those fuddy-duddies who thought the 
short Monday morning plenary was a good idea.  It's not a matter or 
reporting on what happened during the week; it's an opportunity to let 
all of know, if we have spare cycles, where we ought to spend them.  And 
if that bores some people, shame on them, because what's important here 
is our ability to work as a community across Areas and across levels of 
the stack.

DAVE CROCKER: I am confused about the logistics of what you're 
suggesting given the number of Working Groups we have.  I'm unclear 
about how much time you want and what you want done during that session.

JOHN KLENSIN: I think that kind of review is more important than another 
Working Group.  I think if we cannot handle a Working Group in terms not 
only of managing and having people come to the sessions, but of 
understanding as a broad community what that Working Group is doing, 
then we have too many Working Groups.  So my tradeoff isn't more Working 
Group time.  It's making more strategic decisions about what we need to 
do.

DAVE CROCKER: But what are you looking for on Monday morning?

JOHN KLENSIN: I think the Steering Group is supposed to act like a 
Steering Group.  If the Steering Group is able to say, "Well, this 
Working Group has an impact across Areas on this thing on the internet, 
and maybe it's time we get a presentation from them," that's useful.

DAVE CROCKER: A selective hot seat for salient working groups?

JOHN KLENSIN: If that's necessary.  For some we've been using these 
cross-Area reviews at Last Call as a means to get input from those which 
would not normally occur.  That's too late.

MATT LEPINSKI: It would be kind of cool on Monday morning to have the 
IESG members give 5-10 minutes each on what they see as the important 
things that will happen during the week.  Or just a couple of sentences 
from each IESG member.  That would help give everybody a heads-up about 
things that are happening in other tracks.

RUSS HOUSLEY: So, on Sundays the IESG and IAB talk about hot spots.  
Maybe we could do an experiment in Orlando and hold that discussion in 
plenary.

JOHN KLENSIN: I think that would be useful, but it would have to be no 
later than Monday night.

RUSS HOUSLEY: Right.

SAM WEILER: I am not happy about response to John Levine's question 
about meeting fees.  If a more substantive answer is not more 
immediately available, I would like you to take an action to review 
those fees, and if you're not lowering them, respond back to the 
community with an explanation.

RAY PELLETIER: Just for background, the fees $635 for 2008, 2009 and 
2010.  And they are $650 for 2011, 2012, 2013.

SAM WEILER: That doesn't answer the question.

RAY PELLETIER: Just a point of information.

ERIC RESCORLA It's not fun to admit you're wrong, but I hear it's good 
for you.  I just found the discussion of the meeting fees to be quite 
illuminating, and we wouldn't have had that if we hadn't seen the 
financial presentations, so bring it on.  

[Laughter and applause.]

ERIC RESCORLA: I just got back from W3C where the last-minute meeting 
fee is 135 Euros a day, so I'm feeling okay.

BOB HINDEN: Thanks for the feedback.

DANNY MCPHERSON: Just another data point: I know we [Verisign] have 
sponsored stuff at the last couple of IETFs with the resources we had 
available, and that some of those sponsorships only came in a few weeks 
before the meeting, so the IAOC can't count on that money coming in.  
They have to budget to manage this long-term.

TIM SHEPHERD: I think something unfortunate happened with the meeting 
fees discussion, and I think there's a lot of misunderstanding.  My 
theory is that I think some people might think that the IETF is running 
a surplus.  But from what I understand from sitting through similar 
financial discussions at previous meetings is that the IETF is actually 
running a substantial deficit every year, and that deficit is being made 
up by ISOC underwriting the activities of the IETF.

SEVERAL IAOC MEMBERS: That's completely correct.

DAVE CROCKER: It depends on whether you think the ISOC revenue is a 
natural part of the IETF revenue.  

PAT THALER: Having been treasurer of another large standards 
organization, one thing I'll note is that this year we had 3 North 
American meetings, and that's not the desired case or the usual case.  
And frankly, the costs in North America, because of the way the hotels 
are set up to charge for their meeting space, tend to run lower.  It's 
hard to extrapolate from this year's experience what next year will be, 
and I think that is important to consider.

BOB HINDEN: That is correct.  You'll see that in the back up online, if 
you look at the years where we had more meetings outside North America, 
the costs do go up.  And to the previous statement, we run approximately 
a $2 million deficit every year.  It's being made up by ISOC, but it 
doesn't show up on the revenue line.

8. IESG Open Mic

Russ Housley introduced the IESG:

- Ron Bonica, Operations and Management Area 
- Stewart Bryant, Routing Area 
- Gonzalo Camarillo, Real-time Applications and Infrastructure Area 
- Benoit Claise, Operations and Management Area
- Ralph Droms, Internet Area 
- Wesley Eddy, Transport Area 
- Adrian Farrel, Routing Area 
- Stephen Farrell, Security Area 
- Russ Housley, IETF Chair, General Area
- Brian Haberman, Internet Area 
- Barry Leiba, Applications Area 
- Pete Resnick, Applications Area 
- Robert Sparks, Real-time Applications and Infrastructure Area  
- Martin Stiemerling, Transport Area
- Sean Turner, Security Area 

A summary of the open microphone session follows:

LUCY LYNCH: There isn't another natural place in the plenary to say 
this.  I've seen a number of IETF 55 shirts this week.  On the bottom of 
that T-shirt, it says "IPv6."  Itojun did that.  Itojun was a volunteer 
on the NOC team at 55.  It's hard to believe its 30 meetings on, and I 
still miss him.  So thank you, Itojun.

[Applause.]

ANDREW SULLIVAN: There was a recent incident where there was a 
suggestion for somebody to make a judgement call.  And the response on 
the mailing list was, "Oh, we better not do that; we should exercise one 
of these rules instead."  We have a current discussion going on about 
the Note Well, and it's turned into a 300 message cluster of people 
micromanaging the discussion of exactly what we can put up in slides.  I 
am extremely concerned that we need the ability for someone to make a 
judgement, and make it stick.  I'm wondering if you have any suggestions 
on how to make that work in the future?

RUSS HOUSLEY: Your question is how to stop bikeshedding?

ANDREW SULLIVAN: Well, yes.

PETE RESNICK: One of the things that generates the bikeshedding about 
process is driven by an idea from the IETF plenary (the main body of 
everyone) that we are authorities that need to take charge.  The 
decision has to be immutable, and if we're going to be put in that 
position, then everybody wants to make sure that the rules for us doing 
that are really tightly defined.  On the flip side, because of that 
feeling, we are loath to engage in the discussion on the list, for fear 
of overly influencing the direction of the discussion.  There's a power 
imbalance now, and a pretty serious one, that when I started with the 
IETF wasn't here.  Part of this is a cultural problem, that we're being 
asked to be in a very legalistic, authoritative place, and the dynamic 
has gotten strange.  Some of it is, you guys shouldn't worry so much 
about the rules, but also, push back on the judgements.  Does that make 
sense?

ANDREW SULLIVAN: Yes, it makes sense, and that's exactly why I want 
judgement rather than more rules.  It seems like every problem that we 
have, we immediately go into protocol-building mode.  We're always 
fighting the last war.  I am terrified that eventually what we're going 
to have is all process, and do no actual work anymore.  

RUSS HOUSLEY: This is exactly why open mic time is important, because 
this is where the community holds us accountable.

HARALD ALVESTRAND: I am just slightly sentimental.  I was looking at the 
slides I did at the plenary in Atlanta 10 years ago.  One slide says, 
"The IETF is a success in producing high-quality, relevant standards for 
the internet and allowing open participation and fair sharing of ideas.  
The leadership is providing a unified vision of the internet 
standardization effort, and in using the internet to create the 
internet."  The next slide says, "The IETF is a failure.  Work is slow, 
output mediocre, and irrelevant to the real problems facing the 
internet.  Decisions are taken by back-room deals, intimidation and mob 
psychology.  The IESG imposes random mandates that are irrelevant to the 
problems at hand.  People are leaving in disgust in droves."  Some of 
you were at that plenary.  I am quite happy to see that compared to that 
plenary, plenaries are reasonably tame now.

[Laughter.]  

HARALD ALVESTRAND: Thank you for making the stuff that needs to be done 
boring to the rest of us.  We need to get our work done and not have 
that kind of dramatics.

RUSS HOUSLEY: Thank you.

DAVE CROCKER: Back to Andrew's point.  I think there's a couple of 
things make a huge effect on the bikeshedding and devolution into 
minutiae.  Yes, we all have the tendency.  Welcome to the world of 
engineering.  We know how to manage processes in Working Groups, and we 
don't do that management in the IETF list.  We don't have someone who 
tries to move the conversations towards convergence.  We tend to let 
tiny numbers of people effectively have a veto, and rough consensus 
doesn't assign that kind of power to individuals.  For topics that don't 
formally require rough consensus, let me suggest that there is a 
difference between discussion (which is good) and sense of obligation to 
have a clear rough consensus (which is bad for those topic where it's 
not required).  The thing that we probably do need when we don't need 
rough consensus, is reasonable support.  If you don't have a fair amount 
of community support, it's probably a bad decision--but that's different 
from saying we require rough consensus.  This distinction between when 
we need rough consensus and when we don't might help a lot.

PETER SAINT-ANDRE: Having sat up there myself, I'd like to point out 
that those people up there [on stage] aren't our leaders; they are 
people serving in temporary leadership roles.  They are people just like 
us.

JOHN KLENSIN: I consider that we don't have a plenary like the last one 
in Atlanta as a bad sign of community disengagement.  I'd like to see 
more controversy around here, because I think the controversy exists in 
the community.  And there's a sense of acceptance and reassignment that 
one can't do anything, that's a bad sign.  We don't have enough recalls, 
we don't have enough controversy, we don't have enough appeals.  That's 
not to say people are behaving badly, but that the community doesn't 
feel it has the leverage to push back because pushing back gets bad 
results.

JOE HILDEBRAND: A disengaged community produces bad work, and I think 
we've been guilty of that, and I think that's why it's hard to get 
people involved in new work.  For instance, we have people participating 
on mailing list who live here in Atlanta who we couldn't get to come to 
the meeting physically because they weren't interested in our level of 
back-biting and production of low-quality output.  And I think that's a 
shame.  We need to think about who we are, and what we're doing, and why 
we're doing it.

ADRIAN FARREL: Isn't it possible that the people on the list chewing the 
ideas are the ones who cause the disengagement by the others?  It's the 
engagement that causes the disengagement.

JOE HILDEBRAND:  That may be.  And part of it is that we don't teach 
other to argue well.  We end up arguing about the wrong things, and we 
do it in a way that discourages people from having opinions.  Winning 
isn't important; what's important is building a better internet.

PHIL HALLAM-BAKER: I find it strange that we're discussing how 
disengaged people are these meetings.  On the one hand, we've got these 
people who are not engaged.  On the other, we've got these people who 
are saying that they wouldn't want to be engaged.  I think we've got to 
decide whether it is more important to get people engaged who are 
interested in making the internet better, or whether it is more 
important to preserve the institutions in the form that they have 
evolved to over the last 25 years. 

PETE RESNICK: I don't know that there's anything contradictory in those 
views.  What I think I heard Joe and other folks talk about in terms of 
engagement is that there is the way we deal with each other internally, 
and then there is how the rest of the world deals with us.  They are 
related, no doubt, but I do think that what folks are talking about is 
more about how do we make that communication work internally.

PHIL HALLAM-BAKER: I think the two are linked, and it points to a 
systemic issue.

HARALD ALVESTRAND: Ten years ago I expected about five different 
revolutions to have to happen in order for the IETF to survive the next 
10 years.  I think we've had about two of those.  I am concerned that we 
don't have a process that scales.  If someone asked us to come up with 
good reason why we had to produce 30% more output in a year because it 
was needful, I don't think we could do it.  I think we have serious 
problem in scaling and in quality of reviews.  That we've kept the 
machines churning and produced output of such quality is a credit to the 
leadership; we just haven't had the revolutions yet.

RUSS HOUSLEY: I think that's supported by the time commitment by the 
leadership positions.

KATHLEEN MORIARTY: While I don't disagree with the other comments that 
have been made, I want to say that from my experience, the level of 
detail and transparency in the IETF is tremendously helpful, especially 
as I've brought new people into this forum.  I greatly appreciate that.

LEE HOWARD: Think it's great we can have such an active discussion about 
how disengaged we are. 

[Laughter.]

LEE HOWARD: I don't hear grousing about what ADs are doing.  I think the 
reason there aren't so many fireworks is that the IESG is doing a great 
job.

RUSS HOUSLEY: Thank you.

MURRAY KUCHERAWY: In comparison to some of the other people who have 
been at the mics, I'm a relative whippersnapper.  However, I'd say that 
in the time I've been here, there have been big improvements in all the 
things we've talked about, the accessibility of the IESG.  I'm fairly 
satisfied in the way that's going.  There's another organization I 
attend regularly which hasn't documented any of its process, and I 
frankly use the IETF as a model for it sometimes.  They're about one-
fifth the size of this organization, but I'm much more comfortable in 
this environment than it that one.

PETE RESNICK: I think Murray is right about the engagement bit.  That 
is, once you get to know us, it's easier to engage us.  But most of the 
community is not engaging us at that level.  One of the reasons people 
become chair is because they engage us, and vice versa.  The people who 
come up to the mics are the ones who are engaged.  There are a lot of 
people roaming the halls who have not gotten up to the mics.

RUSS HOUSLEY: Six years ago the IESG had a breakfast meeting on all six 
mornings of the IETF week, and now we have only three, which allows the 
IESG to be out there having breakfast with the community and have those 
two-minute conversations that can help avoid a train wreck.

PETE RESNICK: Although I will admit to spending half those breakfasts on 
topics in a specific Working Group and not the general engagement.  So, 
nose whacked with newspaper, appreciated. 

PETER SAINT-ANDRE: I'd like to ask Harald the question about what those 
other revolutions are?

HARALD ALVESTRAND: One of the suggestions I made at one point was that 
the complete IESG never see a document unless there is a crisis.  The 
review process doesn't scale.  It's much more important for the people 
at the top of the pyramid to provide actual leadership rather than 
reviewing documents.  Reviewing documents is of course critical, but 
these are not the people to do it.

RUSS HOUSLEY: I distinctly remember the slide you put up when you 
stepped down as chair, and it was not a pyramid--at least not a right-
side-up one.

HARALD ALVESTRAND: The way Brian Carpenter described the way you know 
you're IETF Chair is because everyone sits on you.  One of the other 
revolutions I suggested was cutting the IESG in half, because the group 
is too big to communicate efficiently with itself.  That didn't go 
anywhere; we've since added a new Area, which meant adding two ADs.  But 
these are mechanisms, not revolutions.  I would like to have the IETF be 
an organization that eats other standards organizations.  When people see 
that running an organization is no fun, they should come to us and ask 
us to take over.  And the IETF should be in a position to say yes to 
that.  We've kept the machine ticking, and that's important, but we 
can't continue this way indefinitely.

JOE HILDEBRAND: I just wanted to get one positive note in.  I do think 
there are a lot of really strong individuals, and a lot of people that 
I've learned a ton from over the years.  One thing for the people who 
are in leadership or who have been around for a long time and have some 
of the institutional knowledge, they should really be asking themselves 
if they have enough people that they're mentoring.  If we want to 
culture to maintain itself over the years, please keep taking new people 
under your wings.

JARI ARKKO: As we do more and more engineering, the systematic function 
gets harder and harder.  At the same time, some other organizations are
pushing us on speed (like WHATWG).  We do have to figure out how to get 
back to more "running code" principles.  The danger is that certain 
efforts will go other places if we're not fast enough.

RALPH DROMS: If we're going to speed things up and look more at running
code, then we need to be careful not to lose our breadth.

[ENDS]