3 Wednesday Plenary

Thursday Plenary

Current Meeting Report

5 December 2007
IAOC/IESG Plenary


Welcome (Russ Housley)
Host presentation (Dr. Stephen Wolff, Cisco)
NOC Report (Morgan Sackett, VeriLAN)
NomCom Chair (Lakshminath Dondeti)
Recognition (Russ Housley and Internet Society)
IETF Chair Report (Russ Housley)
IAOC Chair Report (Kurtis Lindqvist)
IAD Report (Ray Pelletier)
AMS Secretariat Staff Introduction (Ray Pelletier)
IAOC Q&A
IESG Q&A


1. Welcome (Russ Housley)


2. Host presentation (Dr. Stephen Wolff, Cisco Research Center)


3. NOC Report (Morgan Sackett, VeriLAN)


4. NomCom Chair (Lakshminath Dondeti)


5. Recognition (Russ Housley and Internet Society)

- sad news: Itojun

[ Moment of silence in his memory. ]

- Mark Foster

Many thanks.  Mark played a pivotal role in the Administrative
Restructuring of the IETF.  Without Mark’s assistance, the
restructuring would have taken much longer and been more painful.

- Postel Award (Lynn St.Amour, CEO, ISOC)

Dr Nii Quaynor says he feels humbled by this award and by what it
represents. Africa is thankful for this recognition and will be very
pleased with this contribution.  Nii also thanks his colleagues in
Africa who were pushing him along all this time.

The IETF community have helped a lot by the way the number and name
resources have been defined. That has helped Africa's understanding
and its self organisation.  With the award money a new fund for young
Internet engineers will be set up. It will be managed by AfriNIC and
AfNOG. 


6. IETF Chair Report (Russ Housley)


7. IAOC Chair Report (Kurtis Lindqvist)


8. IAD Report (Ray Pelletier)


9. AMS Secretariat Staff Introduction (Ray Pelletier)


10. IAOC Q&A

Joel: would like to hear where the tools development is going and how
the transition will be done. Traditionally this was the task of the
IETF secretariat.

Ray: anticipates that the I-D tracker will keep running. AMS has
a vibrant tool set. We will look to see whether we should take that
on board. NeuStar is doing tools development. There was an RFP
on the Django port of the IESG I-D Tracker development. NeuStar won
the bid. 

Russ: volunteer development is important. It is a way to save money.
At the moment, we are defining a process to take on tools that will be
operated and maintained by the Secretariat.  Non-Profit Open Source
License (NPOSL) version 3.0 was developed for this situation.

Dave Crocker: frequently interesting things happen at IETF
meetings. When it is of technical nature, it might be interesting to
give a summary of what took place and why. As an example: the
pecularities that took place with the audio stream this week. would be
interesting to hear the cause for that.

Joel: high availability equipment failure is responsible for most of
the outages.

Leslie: Russ said tools from the tools team is a way to save
money. But it is much more than that. This is a community that is very
much hands on. Need to understand what the long-term plan is to
support ourselves. Would like to see a plan on how we might move
forward, and how the tools process will support our community.

Russ agrees: As an example: XML2RFC is a tool we all depend on. 

Harald: every tool we develop will be supported on a best effort basis
for the next 1000 years? ;-)

Harald: how is the RFC licence agreement going?

Ray: on the website is information on how to contribute their
documents to the IETF Trust.
 
Harald: how many of the first 2000 RFCs have you gotten signed over.

Ray: we don't have such an inventory. But the names are all on the
web site.  Maybe a 1000 or so.

Russ: went through the process and it was a fairly painful only
because the part of Xerox that I worked for at the time I wrote
the RFC no longer exists. Needed to get VP approval.

Ray: also corporations signed it, e.g. IBM (all the docs by IBM
employees are signed over to the Trust)

Harald: has a question about wether or not people can take code from
RFCs and use them in implementations, in particular modified versions
of that code. Has the IETF Trust made a statement that people can do
this?

Kurtis: no. This is a point well taken and will be addressed.

Paul Hofmann: 'code' is an interesting choice of words. He has written
code that appears in RFCs (not yet signed to the Trust, but will do
tomorrow).  Often those modules are not really code.  There are very
few real code-programs in RFCs. It is more 'chunks of non-english text
that might be useful'. Suggests to be very lenient in the IAOC
statement about that.

Steve Castner : thanks VeriLan for the quality of the network. No
glitches!


11. IESG Q&A

Pete Resnick: years ago IAB and IESG switched plenary nights. That
stopped. Why? Would it make more sense if the IESG would be on Thursday
and the IAB on Wednesday? 

Spencer Dawkins: has the feeling that we gotten to the point that
opening a connection to the Internet on a computer is becoming a
challenge. Seems we reached a new level of insanity. Most what is 
driving application protocols seems to be NAT traversal these days. 

Magnus said in the tsvarea meeting: we end up having hosts hanging on
different NAT levels. We need to continue trying to dig ourselves out
of this hole, but it will take a long time. We can continue to improve
things.

Keith Moore: was surprised to see that in the behave WG that what they
are doing are piece-meal solutions, adding complexity to the network.
Was for instance told that the client server problem is solved with
NATs.

Magnus: it is on the behave WG charter to specify how NATs can behave
more reasonable. He hopes that we can have NATs in the future that
behave better and according to spec.

Keith: making multiple incremental changes to NAT is a failure. Will
not work.

Lars Eggert: Keith, which part of the work in the behave WG do you
have problems about?

Keith: it is the punching holes part of the work. It is not general
enough.

Sam Hartman: there is a discussion in STUN and ICE where it is decribed
why a general solution is not good. If you have concerns with that,
suggests to respond to that in a constructive way.

Keith: fair comment, will do that. 

Bob Hinden: went to tictoc BOF. I believe that it would be a mistake
to work on time related protocols before ntp WG is finished.

Mark Townsley: The ntp WG will be done with the IPv4 part real soon.
Agrees that there should be only one time-related WG. Has been delaying
enhancements, because the v4 part wasn't done. But this cannot be
delayed any longer.

Bob: suggests new people work in the existing WG

Mark: yes, that has been done for the last few years.
Believes it is now time to start new WG.

Yakov Stein: true, this topic is almost done in ntp. This is a no
longer an issue.

Jonathan Rosenberg: in response to Keith Moore: one of the properties
in behave is incremental deployability. Happy to discuss more offline.

Kevin Fall: question about RFCs that reference older RFC. The older ones
were informational or experiemental. The newer ones were STD track,
but did not obsolete the older ones. I asked the RFC Editor and was told
that this was up to the IESG. What is the process to obsolete an old
RFC?

Russ: This is not as simple as you think. We have to look at specific
case.  Often there are 3 or 4 generations of documents.  Need to look
at the whole picture.  The RFC Editor has asked the IESG about the
one that you reported.

Spencer: didn't see discussion IPv6 deployment on the agenda? We talked
a lot about it last time. What happened to it in the meantime?

Russ: There was a huge amount of talk about it this week and before.

Ross Callon: hears a lot of talk about NATs and address exhaustion. He
is afraid that it is always easier to do a short time fix even if that
adds complexity. At some point it might just be easier to move to new
version of IP. He hopes that the pain will be high enough to deploy
IPv6. Wonders what else we can do to encourage the move over to IPv6.

Sam: suggests that this is the wrong answer. IPv6 is catching on where
it has value. IPv6 is being incrementally deployed. Often inside
closed organisations and networks. Starting to see networking effect.
Wonders if the idea that we should all switch over to IPv6 makes that
much sense.

??: deployment is not that straight forward (involves tunnels,
administrative work etc.). All this needs to be better documented.
People in this room can help with that.

Ross: people in general are not real good at moving to where they need
to be in 5 years, but they are good at moving to where they need to be
in 5 days. What can we do to help with where we need to be in 8 or 
10 years and not have this same disussion then again.

Jari: the pain will increase. That is clear. What can we do as IETF?
We can make sure all the pieces are in place so that users can deploy.
Do we have all transition mechanisms in place? Tomorrow this will be
discussed in v6ops WG. Outside the IETF education needs to be done.
ISOC is for instance working on that. Much of the work now needs to be
done outside the IETF.

Ted Hardie: happy to hear from Sam, who talked about adoption and not
transition. We have a fundamental problem if we talk about transition.
IPv4 and IPv6 are disjoint address spaces. There will never be a
transition.

Jari: agrees. The point is that we need to provide good mechanisms to
move between IPv4 and IPv6.

Ted: question than is if 'leadershhip through pain' really works. He
is afraid it doesn't. If we are still talking about this now, how can
we expect the industry to use the right terminology. We need to get
people to understand what is happening in deployment.

Tony Li: people upgrade because they want features or because the pain
is too high. The only thing we can do is to add features.

Sam: The critical feature is the network itself.  We need to keep the
network efect in mind. We can make things easier. Some vendors are now
working to do that.

Philip Matthews: even transition to IPv6 will not get rid of ICE stuff.

Magnus: agrees. Firewalls will not go away. However, hopes that we
will have a good solution that works and will improve the situation.

Philip: what is the incentive to deploy a better solution if ICE works
in such situations.

Robert Sparks: runs an interop testing for SIP, and works very hard to
have global routable address space. At a recent meeting. at a university
campus there was one router that only worked with IPv4 and NAT. They
ended up savaging the network by setting 6-over-4 tunnels.

Sam: did they implemented v6 to v6 NAT?

Robert: Yes

Gregory Lebovitz: A killer application is needed

Geoff Mulligan: yes, but only if the killer application is available on
IPv6 and not available on IPv4.

Sam: if I only accept IPv6 connections, I can still talk to people
through IPv4.

Alain Durand: this discussion is surrealistic. This has nothing to do
with features. The motto has been for many years: bandwidth, bandwidth,
bandwidth. The motto has changed to: address space, address space,
address space.  It is as simple as that.

Joel: addresses are about end points not about applications.  When you
want to reach an end point, you need an address.  It is not about killer
applications.

Margaret: We are the IETF, and we are pretty much done with IPv6. The
single biggest barrier to deployment is unavailability of needed
equipment. There aren't enough test tools etc. There is not much the
IETF can do beyond encouragement and educatation.

Jari: very good point. There are bugs and problems with existing
equipment.  This is because not many people use IPv6 yet, so bugs don't
get detected and fixed. We need more users to fix all those. Believes it
is a matter of time.

Jonathan Rosenberg: there is no killer application. Why would a vendor
build an application that only works on a platform that is unavailable
to most users/customers. Application developers will build on a platform
that many people use, not one that most people don't use.

Fred Templin: submitted RFC4214bis to RFC Editor as an independent
submission.  What happened to it?

Mark Townsley: it was decided that any submission that would conflict
with the softwires WG would be blocked for now.

Fred: but this has already been published as an experimental RFC and
been implemented.

Mark: believes that the charter item in softwire is almost done and
then the road will be clear for that document. Will continue the
discussion offline.

Keith Moore: does anyone have a good list of things that are not in
place yet for IPv6 deployment? This would be useful for us and others.

Ron Bonica: for things that are not specified yet, this can be done in
the v6ops WG. For things that are specified but not impelemented yet is
outside the IETF.

Keith: would still be good to know about those.

Jari: there are various lists in the operators fora, can send links to
the list.

Jordi Pallet: 80% of his time is dedicated to deploying IPv6 with real
customers. Most problems are out of scope of IETF. Mostly education
related.  One open issue is translation between IPv4 and IPv6. There is
actually much more IPv6 traffic than people think.  Only 5% of IPv6
traffic is native; the rest is through tunnels.

Peter Koch (?): it is quite clear what is happening: we came up with
this huge address space, but immediate shortage problem was fixed by
NAT.  At some point we will see IPv6 on the backbone, but people will
still use IPv4 on the edges. This is almost not problem.

??: RoI has not been mentioned before.  Really sad that operators are
under-represented at the IETF.  The ops community is still unaware of
the necessity of depolying IPv6. If the IETF can talk to the ops
community that could help. However, the IETF is not to blame for slow
deployment if IPv6.

Tim Sheppard: has been using 6to4 for many years. In some sense it is
easy. Has been watching to see if IPv6 is really used. Has been using
dig on some of the TLDs. There are quite a lot of IPv6 out there, but
not for com and not for dot. The view that IPv6 isn't already here, is
only true for people who live in US and other countries where the native
language is English. If your native language is something else, people
see much more IPv6.

Mark Townsley: how about we challenge Google to offer native IPv6 before
the IETF they are hosting.

Adiel: yes, IPv6 is happening. Yes, the IETF has been doing a lot in
that area. Agree that many issues are with the operators. He knows that
all the RIRs are working with their communities on these topics. Maybe
the IETF can come out with clear messages about IPv6 readiness.

Geoff Mulligan: yes, it is a matter of addresses, addresses, addresses. 
His company will need millions of addresses, hence we will use IPv6.
Problem is that we spend so much time fixing things in IPv4, that we
don't have resources to fix things in IPv6.

??: some question related to SIP related WGs. How can we address this
problem and avoid having the wild west or a detailed 5 year plan?

Jon Peterson: it is going to take a long time to do these things. 

Dave Ward: The IESG spends a lot of time on RAI and SIP documents. We
need more people reviewing these documents. The volume is enormous.

??: Problem is not the IESG.

Henning Schulzrinne: there was general agreement that we can provide
useful auto-configuration for SIP devices, but we cannot do it because
the protocols were developed elsewhere. Now we are stuck.

Sam: suggests to get concensus on the needed reference in the WG and
get your AD to agree.

Mark Townsley: ACD documents have been adopted in the INT area. The
whole zeroconf effort is important and has a lot of history. It is
important to get it right.

Pete ??: in terms of information: specification was too restrictive at
the time it was written. In terms of process: everything is slow in the
IETF. There are reasons. One reason is speed of authors to turn around
drafts.  Other documents start off as experimental RFCs, it is often
difficult to bring to the standards track.

Cullen Jennings: need to look at what points were right and which ones
where wrong. Trying to reduce latency of drafts and increase throughput.

Lars Eggert: WG chair has the option to replace authors or add
co-authors.

Slides

Welcome
Host Presentation
NOC Report
NomCom Chair
Recognition (Part 1)
Recognition (Part 2)
IETF Chair Report
IAOC Chair Report
IAD Chair Report
AMS Secretariat Staff Introduction