IETF 66 Operations and Administration Plenary, Wednesday July 12, 2006
Notes taken by Mirjam Kuehne and edited using audio file
by Brian Carpenter.
All presentation slides are included in the proceedings.
Please refer to them for details.
1. Welcome & intro (Brian Carpenter)
- ~1236 paid registrations
(a year ago in Paris: 1450)
- 44 countries (very encouraging)
(36 in Paris)
- slightly less than half from the US
- 76 from greater China
125 WGs: 4 new WGs, 13 WGs closed
463 new IDs
852 updated IDs
80 IETF Last Calls
96 approvals
about 138 RFCs published (88 standards/BCP)
additional IESG material:
- http://www.ietf.org/IESG/content
- IESG wiki
- informal handbook
- space for RFC 3933 process experiments
We need to reduce the traditional panic around scheduling of WGs to avoid
clashes. The only way to improve is to have more time; therefore
the proposal is to add two weeks for scheduling process.
Future Meeting dates have been announced through 2010.
2. NOC and host presentation (Ericsson)
Daniel Dulong (NOC report)
- acknowledgements
- provider: risq and canarie
- two redundant links over fiber
- two different POPs in the network
- described the network infrastructure
and some statistics
Odd Svesse, VP and GM Ericsson Canada (Host report)
Convergence Vision: see slides...
3. IASA Report
3a. IAOC General report (IAOC chair, Lucy)
(see slides)
Recent activities:
- RFC Editor RFI released
- Draft IANA SLA sent to the community
- IASA budget 2006 - 2008 submitted to ISOC
- retreat end of May
Top work items:
- Publishing the RFC Editor RFP
- Executing an SLA with IANA
- Selection of a contractor for the RFC Editor
- NSS six month review
- Neustar secretariat six month status review
Future work:
- budgeting
- NeuStar contract review
- RFC Editor RFP
- IANA SLA
- IETF Trust issues
Highlights:
- meeting planning
- host and volunteer relation
- future hosting model (at the moment the hst is responsible for
everything, plannig to make this more flexible)
- possibly outsourcing NOC services
- funding model discussion
- sponsorship, meetings, hosting etc.
- IASA goal setting
- IAD evaluation and goal setting
The IETF Trust
Web site will be moving to iaoc.ietf.org
3b. - IASA operations (Ray Pelletier)
IASA ver.01 - the first 180 days (see slides)
Some experiments:
- 66attendees@ietf.org list
- will be a opt-in next time
- there will also be a wiki or a blog next time
- mac@ietf.org
- meeting secretariat mailbox
- Dallas ++
- working on an appropriate balance for food and beverages for attendees
Future meetings (see slides)
There are still a number of RFCs in the queue for various reasons, but
there is no backlog anymore at the RFC editor
Financials (see slides)
- budget underestimated 93k USD!
Thanks the host, the city, the network provider and the secretariat.
3c. RFC Editor (Joyce Reynolds)
see slides
3d. IANA report (Barbara Roseman)
see slides
4. Tools team report (Henrik Levkowetz)
see slides
5. NomCom (Andrew Lange)
Andrew appealed for volunteers to serve on NomCom
6. Picking a direction for standards track reform (Brian Carpenter as General AD)
See draft-carpenter-newtrk-questions-00.txt
There seem to be three possible directions.
The community needs to decide amoung those three options.
RFC3774 lists a number of problem statements, some of them have been
solved through IASA and other mechanism, but this particular one has
not been solved: "In practice, the IETF currently has a one-step
standards process that subverts the IETF's preference for demonstrating
effectiveness through running code in multiple interoperable implementations."
The newtrk WG has not come to a conclusion yet.
First option: just clarify RFC 2026
Second option: document relationships (people outside the IETF can get
very confused which document is the right one to use when implementing
a standard. The proposal is to create a new series of documents to make
this clearer).
Third options: focus on maturity levels, maybe revise the standards track.
Open Discussion:
Sam Hartman: Sometimes we are spending too much time on process;
It seems the problems are not big enough.
Of course it would be nice to fix RFC2026, because we are not following it.
But doesn't seem to have high enough priority to actually fix it.
If we turn to it, we need to get it right. Easy to get this wrong and
that could be very bad. Let's "declare victory" (applause) and try some
experiments.
Scott Bradner: two different things:
- agrees with Sam, the Internet hasn't stopped, because we are not
following RFC2026
- however, wants to clarify:
He believes that a good description of the standards process would be
useful. And the three-stage process shows maturity level of documents,
but the ISD proposal would reduce the importance of these stages.
Phillip Hallam-Baker: advocates strongly for option three (his version
of "declare victory").
How? either get rid of Draft Standards
or everything that gets to Draft Standards should move automatically to
Standards after a certain time; effectively a two-stage process.
Alain Durand: those three options are not exclusive
He made a transition from a vendor to an operator and realised that
operators do not care. The level of the standard doesn't matter, only
that it is an RFC. Suggests to declare victory and proposes a one-step
process.
Ted Hardie: The problem statement was that we don't have enough interplay
between running code and revised specifications. It is important to
demonstrate the impact of running code. Today we are more about getting specs
out, not about proving it by running code anymore.
There are a lot of other options to get the running code process back
into the IETF. It should not be part of the standards track, but part of
the WG spec writing. Find a way to get WGs to respond to running code
feedback.
Marc Blanchet: Option two would still be useful.
Also thinks one step less in the standards process might be good.
David Black: Echo Sam's comments. if there is an obstacle to getting
work done, it is useful to work on process. This one is not an obstacle
however. Declare victory.
Matt Mathis: Doesn't want to spend the time, but all three options are needed.
Declare victory, but need a lightweight document to document which standards
are actually implemented. The real voter is the consumer
Keith Drage: Other organisations in the outside world do not seem to
care about the label. Thinks it just takes too long to get to STD to
be useful.
Dave Crocker: the fact that we don't move through the levels, doesn't
seem to hinder process. BUT, that means there is a lack of feedback
about the specs. Would be good to have a second label: the market
comes back and says we are using this. How? A doc goes to Proposed
Standard and has n years. If the market does not come back within n
years, it ceases to be a standard. Could do #2 independently, without
formal process change.
Dave Nelson: Declare victory and move on. The market does show what is
effectively a standard.
Clint Chaplin: What about things that are universially implemented
and not used? There are documents that are experiemtnal, not even
standards. There are things that the industry likes even thoguh they
are not standards.
Bob Hinden: we should declare victory, but we cannot leave the current
process as documented. We might have to take steps out of the
documents and see what we do with all the current documents.
Brian Carpenter: There are various interpretations of "declare
victory" here - be careful!
David Kessens: we should adopt reality and get rid of stuff we don't
actually do. That would make things simpler. (Applause)
Spencer Dawkins: what is the best way to publish useful things?
Brian: Three preference questions:
Do you prefer doing nothing over 1?
If no,
Do we prefer 1 or (2 or 3)?
If no, and assuming 1 will follow anyway,
Do you prefer 2 over 3?
Do you prefer 3 over 2?
Humming? No,the meeting prefers hand raising.
Matt Mathis: likes the 'simplify' option, but it does not seem to be
in these choices.
Brian: OK, should we just stop working on making changes to the formal standards
process as in RFC 2026? 30 hands
Who thinks we should continue working on this? 50 hands
How many people have difficulties operating caused by the standards
track? 30 - 40 hands
How many people believe they have no difficulties operating caused by
the standards track? 30 - 40 hands
How many people are willing to put work into making changes to the
process tracks. 10 hands
John Klensin: people don't seem to be willing to work on this, before it is
clear what they get out of this and why this is useful.
Leslie Daigle: doesn't want to sign blind checks. Not clear what problem we
are actualy trying to solve. There is no real proposal.
Dave Crocker: problem seems to be the book keeping is sloppy.
This doesn't motivate many people. Need to propose steps that
motivate the community, or drop the discussion.
Brian: It sounds like the problem statement was wrong.
Gets the IESG on stage
7. Open meeting - IESG on stage
Aaron Falk: a show of 30 hands is not a sign of community consensus that we
should work on this. Community in this room has spoken.
Marshall Eubanks: Timeline for scheduling WGs was proposed to change.
How does that reflect on BoFs?
Brian: the idea of the new timeline that the formal scheduling deadline
for BoFs would not be brought foreward, but draft proposal for
BoFs would be have to be sent to the AD two weeks before the cut-off for the
scheduling, so that the IESG has time to review them.
Marshall: please make sure this is properly documented on the site.
Ross Callon: this should be a collaborative effort between people who
want BoFs and those who might have some experience with setting up
BoFs. Should be reasonable to allow enough time for it.
Eric: the IESG should be more willing to say NO, not only with approving
BoFs, but also with moving BoFs to WGs.
Jordi: was surprised that when seeing the calendar that Latin America
and Africa are not on the list. We should not restrict ourselves to
just three regions.
Ray: calendar is prelimenary. open to propsals and expressions of
interests.
Fred: the guideline he used in placing meetings: if you are
participating in the IETF, the meeting should come to you. Should not
be a missionary endeavour.
Brian: has been following the same criteria as Fred (and Harald), but there is
clearly also a chicken and egg problem in going to new regions.
Eric Rescorla: Thinks there should be more consistency in the criteria on approving
documents by the IESG, or in rejecting them if they are considered harmful.
Sam Hartman: asks people to make objections clear in the last call.
[unidentified]: positive reaction was to Ted Hardie: that the running code that
is now buried in the process should be moved back into the WG.
Sam Hartman: there is nothing stopping people to determine what code
is running and use it in the WG. Don't start from the top down.
Lisa: there may not be concrete difference in the effectiveness of the
WGs that do interops or those that don't
Ted: and it is certainly not visible in the RFC
Spencer: thanks the IESG to take their work so seriously.
Michael Richardson: can you tell us what kind of consequences, what
kind of sticks do we have in the end to enforce problems with the
network at IETF (referring to the proposal to outsource)
Ray: Will be subject to RFI/RFP/SLA process.
Brian: whoever is doing the network, should have the same pride as the
host. And they will also feel the same embarrassment if it doesn't work.
--end--
|
