IAOC/IESG Plenary
31 July 2008

Agenda

 1. Welcome
 2. NOC Report (Andrew Lange) (see slides)
 3. IETF Chair (Russ Housley) (see slides)
 4. IETF Trust (Ed Juskevicius) (see slides)
 5. IAOC (Jonne Soininen) and IAD (Ray Pelletier) (see slides)
 7. NomCom (Joel Halpern) (see slides)
 8. EDU Team Update (Margaret Wasserman) (see slides)
 9. IAOC Q&A
10. IESG Q&A
11. IAB Q&A


IESG Q&A

Henning Schulzrinne: follow-up question regarding the bonjour
documents.  It was promised at the last IETF that this would be
progressed, what is the status on that?

Mark Twonsley: that document depends on another document. This other
one is now done, so the document in question will be progressed really
soon now.

Keith Drage: how do the PROTO write-ups help and how do they affect
the timeline?
 
Cullen Jennings: the PROTO write-ups help very much

Jon Peterson: yes, agree. We use them. 

Mark Twonsley: PROTO write-ups are a good thing, the other comments
sometimes yes, sometimes no.

Dave Ward: they absolutely help, especially in areas I am not so much an
expert on.

Lars Eggert: the process if applied should work pretty well.

Keith Drage: there are large pieces of the RFC that defines the PROTO
process that we are at the moment not followed, but should be.

Brian Carpenter: as a Gen-ART reviewer, the PROTO write-ups are
extremely useful. Last Call reviews would be easier if a PROTO
write-up were available.

Russ Housley: the Secretariat has been posting the PROTO write-up as
the first comment in the Data Tracker.  It is available to everyone.

John Klensin: there was a discussion on the list regarding extending
the sessions on Friday afternoon in Minneapolis. Is the IESG getting
back to the community with a decision?

Russ: this is still under discussion. More community comments would be
good. It will be a management item on the next telechat and then
reported back to the community.

John: I have had several conversations this week with several
ADs, on an individual basis, regarding my recent appeal.  I have
been pleased by the things that those ADs are saying about
process and rules, although I don't know if their opinions
represent the IESG as a whole.

Ted Hardie: I was also very happy with your response to John's appeal,
made the right decision. I agree that there should be a dialogue about
this. However, I am not sure that it should be the IESG running that
dialogue. We still have a problem with the review process. Can you Russ,
in your role as General Area Director, offer any clever way to have such
community discussion that does not end up into a fight?

Russ: I have some thoughts, none that are fully worked out.  I would love
to brainstorm with anyone who has any good ideas about process change.

Lisa Dusseault: I posted a mail to the list with some proposed changes.
If that helps to develop a better procedure, that would be great. I
invite comments and feedback.

Jeffrey Hutzelman: any time the IESG looks at someone cross-eyed, five
people jump up to complain that the IESG has too much power.  The
primary job for the IESG is to manage the process. Wouldn't it be
easier if we would concentrate on technical work rather than changing
the process every five minutes?

Russ: there is definitely need for some process changes, maybe not in
all areas suggested. I'm all for incremental improvements. Magnus is
working on a document that will be sent out to the community shortly.

John: my gratification was not about the appeal response.  I was
appalled that the IESG apparently felt under pressure to respond the
way they did, in legalistic, narrow, language that completely ignored
the main point of the appeal itself and that, even on the narrower
issues, immediately followed an appeal response that indicated they
were going to unblock the document with proposed text for it that many
people felt was petty and punitive.  I'm glad the latter got
straightened out too, but getting to a reasonable result should not be
this painful for either the community or the IESG.
			      
Spencer Dawkins: I could not understand the IESG's response. Not sure
what actually happened, even though he is a scribe at IESG telechats.
The technical discussion about the appeal was not minuted. The
discussion that is happening doesn't need to disappear just because
one person in the community makes an appeal. I think this is the first
time we had a response to a technical appeal like this one. As a member
of the community: he did not understand what happened at the telechats.

Lisa: this document did not come back to a telechat, because the
issue was cleared in between telechats. This is not a rare case.

Spencer: the point is that this was not very transparent.

Russ: to clarify what a DISCUSS-DISCUSS is: sometimes review of a
document raises a question. There is a real concern if the answer to
the question is A, but no concer at all if the answer is B. During the
telechat the sponsoring AD will usually provide the answer to the
question. Sometimes the answe comes before the telechat. Once the
answer is known, the DISCUSS-DISCUSS is either cleared or turned into
an actionablee DISCUSS. The explanation of DISCUSS-DISCUSS is not very
clear, and the IESG has taken the action to explain it better in
an updated document.

Harald Alvestrand: this is a symptom, not a disease. I disagree that
this can be improved by incremental changes. People waste time on the
wrong things. It is not the individual's problem, it is the system that
needs to be changed.

Russ: I would love to hear your ideas on how it ought to work.

Scott Bradner: the problem is that we never defined the internal workings
of the IESG. This was brought up in Yokohama. We have a process in which
one individual IESG member for whatever reason can stop progress in a
very non-democratic or non-technical way. And this is frustrating and
not-understandable by the WG. The way the IESG makes decisions, is not
well defined.

Russ: since the IESG started using the Tracker, things have become much
more transparent.  Now, anyone can see the status of the review and see
what comments need to be resolved for the document to progress.

Pasi Eronen: the Tracker has been unchanged for a long time. One thing
that is probably very confusing: that it doesn't allow you to determine
if only one AD has a problem or if some or all ADs agree with the
blocking comment. That is not visible to the community.

Scott: I was on the IESG when the tracker was developed. Some of us
pushed extremely hard to get the tracker out. But we hoped that the
community and the NomCom would make use of the information in the
Tracker, and that is not happening.

Sam Hartman: I want to talk about appeals. RFC 2026 says that the
appeals process is supposed to be open. While I was on the IESG, the
answer often was: if you had an open appeals process, how would we be
impartial about the second level appeal. He would much rather see appeal
handling be extremely open. It would be more useful to have a dialogue
with the community and have a community consensus at the end and not a
decsion made by the IESG internally.

Dave Crocker: the Tracker is excellent. Obviously it has problems,
because it is big and complex tool and process. Would like to thank
Pasi for bringing up his point. Would encourage that if an AD has an
issue, he or she should register that separately. Bottom line: if you
go back and check why the IESG is in charge, it was exactly to address
the problem of late surprises: the issue of the community being
pre-empted. This has not changed. We still have the same problem. Every
time an issue gets raised: dominant response is either that this is a
problem with the Tracker or it is a dismissal of a "whiner".

Ron Bonica: I heard that we need to have a discussion about the IESG
behaviour. I heard that this should maybe not led by the IESG. Can the
community then suggest another forum and what the exact topic? 

Tim Polk: a longer and more open review might conflict with other goals
the IESG has, like efficiency and timeliness. Much more effective to look
at the Tracker and find out some other AD is already taking care of a 
certain issue. One person should hold the DISCUSS and then others add
comments to show they agree. This way, only one AD needs to clear the
DISCUSS to get the document approved.

Chris Newman: agrees with Tim, but also with Pasi. Nominating one AD
to take care of one DISCUSS is faster.

Magnus Westerlund: we need to work bottom-up: cross-area reviews need to
be happening. Many of the issues that come up in a DISCUSS should be
addressed early on in the review process.

Dan Romascanu: sympathises with visibility issues raised by Dave
Crocker.  We need participation from the community, technical experts
in the review teams, and also response from the authors when the
comments are sent back to them.

Ross Callon: during the telechats it usually it is not important enough
to put a comment in the Tracker to indicate agreement with the comments
of other ADs unless I want to be involved in the email discussion about
this DISCUSS.

Thomas Narten: Tracker is great. Observation: how long are we using
it? 5 years? Are we still using version 1.0? Regarding feature richness
and so on. The way ADs are using the Tracker, it is hugely variable.
Consistency would be helpful. We also need to step back and go to the
next level and make the work flow of the tool better.

Russ: that is on the to-do list. There were meetings this week to
talk about Tracker enhancements.

Pasi: the tool is not so easy to change. But we are working on it.

Pete Resnick: WGs are thinking what should we do to satisfy the AD.
That is wrong.  If a DISCUSS goes on a document, then there should be
an agreement that the community goes to that WG for a discussion of
the concern.

Lars Eggert: agree that the WG needs to be involved if it is a serious
issue. We are indeed sometimes working around idiosyncrasies of the
tool.

Pete: we need to be careful of how artifacts are influencing the way
we handle things.

John: I've been in software development for a long time.  If a group
that is supposed to use discretion and good judgements says that it
can't be done because of the tools they use, I get the chills.

Lars: that is not what I said or meant

Lisa: it is a fact that tools, and even email, influences the way things
are done. It has side effects. But without a tool, the decision would be
even more judgemental.

John: afraid that the tool makes you confuse consensus with rough
consensus.

Lisa: none of us have a simplistic way and blame the Tracker. 

John: problem is when DISCUSSes become blocking issues over trivia.
If there is disagreement between the IESG and the community, if it
is a trivia or a serious issues, there needs to be better
communication.

Jari: agree that the way the ADs communicate to the WGs about
DISCUSSes needs to be improved.

Ron: we should focus on the type of DISCUSSes that deal with 
serious issues, even though they happen very rarely.

John: agree, but I am afraid that the trivial kinds of issues are a
waste of time for the IESG.

Spencer: regarding the question how the communication should go forward
in the various DISCUSS cases. Maybe it would be worthwhile to set up a
group or panel and work on that and come back with a proposal as was
previously suggested in Vienna.

Loa: I have been a WG chair for some time. I have experienced a number
of ADs. Sometime I get all the three types of DISCUSSes on my document.
They have helped to improve the document. Also, I am a liaison to the
IESG. The problems we talking about stem from a very few number of
DISCUSSes. Overall the work done is great.

Hadriel: regarding not having enough time and possibly adding time on
Friday in Minneapolis. We have not nearly enough time to meet with all
the WGs in the area he is working in. To have 7 hours spent on
plenary does not seem time well spent (5 hours plus 2 hours
re-arranging the rooms).

Russ: re-arranging the rooms won't be necessary in Minneapolis. And we
are also considering 1 instead of 2 plenary sessions. We are working
on that problem.

Hadriel: or maybe put one of the plenary sessions on the Friday
afternoon slot and see how many people show up?

Margaret: disagree with extending to Friday afternoon. People already
loose one weekend before the IETF. Can we not start earlier in the
morning? One plenary session might help and will provide another
slot. Making it longer doesn't seem to be the only or best solution.

Ross: not all work is actually done in open sessions. You end up doing
breakfast- and lunch-meetings to talk about documents or other work
issues. Not humanly bearable to do this for an entire week. Maybe we
should consider doing more work during meetings.

Mark Townsley: evaluate if your WG actually needs to meet at every
meeting.

Keith Drage: ad-hoc meetings are necessary. Some people go home on
Thursday, we need to suggest everyone stays until Friday.

Thomas Narten: yes, more work needs to be done outside the meeting.
Look at when I-Ds are published.

Margaret: maybe we could have calls in between meetings. Not everything
has to be done during this one week. 


IAB Q&A

Gregory Lebovitz encourages everyone to use their roles and functions in
their communities or companies to help deploy IPv6.

Scott Bradner: there was an appeal on the NomCom process last time. What
happened with that?

Dave Oran: I am the liaison to the NomCom from the IAB, and I encourage
input from the community. We met with the new NomCom chair today and
discussed the issue of sharing information about the candidates with the
confirming body. We reached agreement on how do facilitate information
sharing between the IAB and the NomCom. I do not anticipate problems.
This may not make everyone comfortable. But he does not think that this
particular issue will come up again.

: What does the IAB think about adding new congestion control
algorithms to TCP? We view a aggregated UDP/IP header as just the
"layer 3" datagram layer over which we run this TCP implementation as
opposed to sticking with TCP or using another congestion-controlled
transport like SCTP or DCCP?  This was an issue that came up in the
TANA BoF this week.

Stuart Cheshire: I understand the tension between the IETF which makes
long-term standards, and companies that want to ship a product this
year, and not wait for Microsoft to release the next Windows version
that implements the new TCP congestion control algorithm. I personally
think that it is a good approach to experiment with this at user-level
running over UDP, and then when the algorithm is worked out it can be
standardized, and then gradually make into the mainstream TCP
implementations over a longer time frame, like five years.

Dave Oran: not sure I agree with Stuart on this. We have to be
extremely cautious with congestion control algorithms. There is a
balance to be struck. Involvement of the sponsoring ADs and the relevant
ICCRG (Internet Congestion Control Research Group) is important. Let's
move with much speed and low haste.

: The issue is that the purpose was not to simply mirror TCP
congestion control with UDP protocols, but to have a different congestion
control that by backing off much more than TCP, serves effectively as a
separate less-than-best-effort traffic class.

Stuart: I view UDP as just IP with port numbers for demultiplexing. I
personally think it is a historical design mistake of IP that the IP
header has no port numbers for demultiplexing, so every single
transport protocol running over IP has to have its own port number
space. AppleTalk, for example, had the port numbers in one place, in
the datagram header, instead of that functionality being duplicated in
every transport protocol. Given that, I don't see it as inherently
ugly to layer transport protocols over UDP, or "architecturally clean"
to layer new transport protocols directly over IP. I'd be happy to see
all new transport protocols layered over UDP, and just treat UDP/IP
together as the new datagram header. Demultiplexing belongs at the
internetworking layer ("layer 3") not the transport layer ("layer 4"),
so let's just treat UDP/IP as the new "layer 3" header.

: You should use UDP when you want peer-to-peer
communication between peers stuck behind NAT gateways, and TCP for
everything else.

Stuart: No. This is a red herring. Broadly speaking, you can do
NAT-to-NAT peer-to-peer communication equally well with either TCP or
UDP. The reason TANA wants a new congestion control algorithm is because
they want something less aggressive than today's TCP. It's nothing
to do with NAT gateways.

Patrik Faltstrom: when working with international domain names, to
include this in all the protocols will not work. Today we are using
IPv6, DNSSEC and other new technologies, why not also do some serious
work across the protocols to include UTF-8.

Olaf: yes, this is well noted.

Scott: when I was a transport AD, we had a lot of people who wanted to
use UDP. That as usually a way to say TCP was to heavy and is too slow
etc.  Would be very concerned what the underlying excuse is.

Gonzalo: agrees. Has to be evaluated on a case by case basis.

Marshall Eubanks: there was a BoF on Experimentation in LISP. Does the
IAB have comments if this ready to work on in the IETF?

Dave: every BoF is attended by at least one IAB member and we advice
the IESG of the architectural aspects on it. But the process for
chartering a WG is run by the IESG.

: a follow-up comment on the UDP discussion. pure client-server
communications, TCP is the natural choice. If you need to use
NAT-to-NAT it requires UDP.