21 November 2007
- Roll-Call, Agenda-Bash, Approval of Minutes, Administrivia
- Liaison Reports
- Concerns about Publishing an RFC in <2 Months
- SPAM and the IAB List
- IETF Agenda
- IAB Techchat, 28 November 2007
- Political Arena Updates
Joe Abley (IAB Executive Director)
Aaron Falk (IRTF liaison)
Sandy Ginoza (RFC Editor Liaison)
Olaf Kolkman (IAB Chair)
Lynn St Amour (ISOC Liaison)
Mark Townsley (IESG Liaison)
Russ Housley (IETF Chair)
1.3 Approval of Minutes
The minutes of the IAB meeting on 2007-10-17 were approved.
2.1 IESG Liaison Reports
The following report was supplied by Mark Townsley.
Since the last report on October 17, 2007, the IESG held three formal telechats, one on October 18, the second on November 1 and the last on November 15. In total, 49 Internet-Drafts were brought to the three telechats for review and action by the IESG.
Two new working groups, “HyperText Transport Protocol Bis (httpbis)” and “Performance Metrics for Other Layers (pmol)” were approved, pending minor edits of the charters from the respective shepherding ADs. Five WG recharters were approved: avt, dhc, ccamp, ipfix and netconf.
The IESG approved one new and one updated ION document: ion-2026-practice and ion-ion-store. The IESG also approved the questionnaire for IAOC nominations.
In addition to document review and WG actions:
A lot of BoF preparation was done by the IESG this past month for the upcoming IETF in Vancouver. There is too much to list here, so please see the IETF BoF wiki http://www3.tools.ietf.org/bof/trac/wiki for a status summary.
IANA experts for ipfix IEs were appointed (Nevil Brownlee, primary, and Juergen Quittek, secondary), and Dan Romascanu was appointed as the new expert for RFC 3588. The IESG approved a number of specific IANA parameters, including several new application media types (contact Chris Newman for details).
It seems that the RFC Editor is publishing the approved documents more rapidly. This is a good problem to have, but it reveals a potential race condition with our current two month window for appeal of any IESG document approval. If the IESG receives an appeal before the RFC is published, the RFC Editor places a hold on the document. However, we have no way to pull an RFC back if it is published before the appeal arrives to the IESG. While we discuss what policy should be applied here, the RFC editor will not publish any IESG approved documents until their appeal timer has expired. So, for the moment, we will see a minimum of 2-month delay after IESG approval for an RFC to be published, even if the RFC editor is clocking better time than this. We are happy to have this problem, and the discussion on what to do about it has been rather active and fully inclusive of the IAB as far as I can tell, so this really should not be news).
2.2. IRTF Chair Report
The following report was supplied by Aaron Falk.
The IESG chair has asserted that they cannot implement the process described in draft-irtf-rfcs-01 without the draft becoming a BCP. Specifically, this means they will not accept drafts for review directly from the IRTF (instead of from the RFC Editor) nor use the alternative “IESG notes” from the draft. This raises the urgency of creating an RFC to establish the stream. The level of process detail in draft-irtf-rfcs-01 is not appropriate for an RFC so the current plan is to break that document into a very short BCP that establishes the stream and an ION (or ION-like document) that describes the process details. This will permit the process to evolve in a lightweight manner.
Several IAB members and I have been iterating on an email that might go out to researcher-oriented mailing lists to attract participation in a research group that follows-up on the IAB’s Unwanted Traffic Workshop.
I’ve received an inquiry about creating a new IRTF RG to create a “QoS Policy Framework”. Based on feedback from the IRSG, IAB, and IESG, the proposers have been asked to clarify the scope and relevance of the proposal.
There are also some folks who’ve expressed very preliminary interest in an RG on virtual networks. Current work is getting them to define their interest in more detail.
“Metrics for the Evaluation of Congestion Control Mechanisms”
The IAB will be reviewing the progress of the Routing Research Group with the group’s co-chairs during the Vancouver IETF.
Yesterday the RFC Editor has published RFC 5050 from the DTNRG:
Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
Aaron was asked if any action by the IAB was needed at this point in time to address the acceptance of documents on the IRTF Stream. Aaron said that the next step was to draft a document defining the IRTF Stream, and then with the IAB’s assistance getting the document published as a BCP. The IAB Chair looks forward receiving the document when it is ready.
2.3. RFC Editor Report
The following report was supplied by Sandy Ginoza.
1. We have transitioned to the new errata system, which allows for online submission and automated notifications being sent to the authors and verifying parties.
2. We have updated the new system to include all reported errata from the pending file located at:
3. We have sent the Area Directors email that lists unverified errata for documents that originated in one of their working groups (~297 reports).
4. We have supplied the IAB/IESG/IRTF chairs with login and password information to the errata verification screens.
There is currently 1 report for the IAB to verify:
RFC 4948 Source: IAB Status: Reported Type: Editorial
5. We have received a request from Russ Housley for the RFC Editor not to publish an RFC in less than 60 days of IESG approval. We are aware that this topic is under discussion and intend to do the following until there has been some resolution, or until requested to do otherwise.
Approved documents will continue through the normal editorial process (through AUTH48). However, if a document has not been in the queue for at least 60 days, we will delay the document announcement.
2.4. ISOC Liaison Report
The following report was provided by Lynn St. Amour.
1 – ISOC will again be mentoring several students for the next IETF as part of our IETF Fellowship Program. For the list of attendees for both IETF 70 & 71 see:
– IETF 70 will see 6 students – 1 each from Ethiopia, Mauritius, Moldova, and 3 from Brazil.
– IETF 71 will see 5 students, 1 each from Bangladesh, Haiti, India, Kenya, and Pakistan
We are always looking for people willing to help mentor these students over the course of the IETF (matched by area of interest) and if you are interested, please see or write Mirjam Kuehne
2 – IGF – As Leslie is giving an update on this later in the agenda, these remarks will be very brief and talk only to ISOC’s position on the IGF. The 2nd IGF (in Rio de Janeiro) was successful and it stayed pretty true to its original concept – an open forum for exchange of ideas and best practices – no formal statements or recommendations were created as an output from the IGF (and this is very good). ISOC had a large presence there as we brought in many speakers and panelists from developing economies, and they added very significantly to the Forum, contributing directly to the success of key workshops, best practices fora, etc. In addition, ISOC had central speaking slots at both the Opening and Closing sessions, which were important to keeping the IGF on mission.
Most importantly, all the discussions on Internet Governance or Critical Internet Resources (v4/v6, root server system, etc. were fairly non-threatening), although clearly they are not going away. For more information on the IGF see: http://www.intgovforum.org/ . The Chairman’s summary is at:
And for more information on ISOC’s activities at IGF, see:
3 – The next ISOC Board of Trustees meeting will take place at the close of the 70th IETF. ISOC Board meetings are open and attendance is most welcome. The Agenda and supporting materials will be published shortly at:
and the main items are the 2008 – 2010 Plan & Budget to be reviewed and approved; there is also a follow-up session from the ISOC Board Strategic Retreat on Trust (expected to be Sunday AM). The two day meeting begins on 8 December, Saturday at 8:00 am and adjourns at 6:00 pm, we reconvene on 9 December, Sunday from 8:00 am – 12:00.
ISOC was asked if there would be report from 17 Oct 2007 meeting on IPv4/IPv6, and the existing two-page briefing paper is the planned output since it was an informal meeting.
In the future, there will be an opportunity for the NomCom Liaison to report status information. Danny, as this year’s NomCom Liaison, took an action to provide a status update on NomCom in Vancouver.
A bit of background on the IAB role: the IAB has real management responsibilities for .arpa and its subdomains. However, as the IAB does not operate the servers of the zones, it is listed as the administrative contact for the zones. The listed contacts are pragmatically the only way to communicate any kind of ownership or involvement with the domain name.
In the current request it is quite obvious that there is no change in organization, just a change in the name server being used by one organization. The IAB should acknowledge the change, and comment that we observe the lack of AAAA glue.
The IAB also got a request to hand over the public key for use in a DLV registry. DLV is a way to publish DNSSEC public keys based on draft-weiler-dnssec-dlv. Since the IAB approach is to stay out of the operations, including operations of the key management, the IAB will defer to the RIPE NCC for getting the public key, and neither endorse nor object to the use of the public key in ISC’s DLV registry or anywhere else.
The IAB chose not to post a statement on their web site regarding this message (though these minutes will be publicly posted). Few requests like this one are expected. If that expectation turns out to be wrong, a more general statement can be created at that time.
Olaf took the action to prepare a reply and coordinate it with RIPE NCC.
See email message to the whole IETF from Russ on 15 Nov.
The proposal from the IETF Chair is that when the IESG approves a document, the RFC Editor is allowed to work on the document, but they are not allowed to publish it until the appeal window closes. The belief is that if there is an appeal, the RFC Editor will have to wait until the whole appeal process is done before publishing the document.
The IAB observes that there are few documents that get published in less that two months from the time the IESG approves them. However, the RFC Editor is working to reduce the amount of time needed. It is unknown if the RFC Editor can make the process significantly faster than it is today. After a document that has taken a couple of years to get through a WG process, a two month delay does not seem to be a large penalty.
There are many potential sources of pain once an RFC is published. Only one of those is an appeal after IESG approval. The IAB, as the stewards of the RFC Series, needs to focus on the general context of events that cause an RFC publication to be undone in some fashion, not just appeals.
It should be noted that there is no existing process requirement that the IAB be able to unpublish RFCs in the face of a (website) take-down request. However, the appeals process does say that, if an appeal succeeds, the appealed decision is completely reversed. That is hard to implement, after the fact, unless an RFC can somehow be unpublished.
Thus, there are two separate issues: (1) the issue of pulling an RFC that has been published, and (2) the issue of making it as if a decision had never happened. The second issue seems to be a problem for the IETF standards process. Yet, one must must recognize that once an RFC number is assigned to a document, there will be a significant population that thinks the document is official because it shows up on various archives and so on.
If one looks to address the problem in terms of the IETF standards process, a two-phase commit process is needed. In the first phase, the IESG says to the RFC Editor that it is okay to work on the document. Then, in the second phase, the IESG indicates that the appeal process is complete and the document may be published. Many IAB members were concerned that this would be optimizing for the corner case instead of the usual case. There was also concern that such a process would provide an avenue for a denial-of-service attack against the publication process.
There was general agreement that additional community input is needed. Is the community willing to accept the publication delay? If so, then the IESG needs to put the necessary policies and procedures in place, including the two-phase commit.
The IAB recognized that there is a difference between culling an RFC from the archive because of a legal action as opposed to an appeal.
Leslie took an action to craft a reply to Russ indicating the IAB view.
Joe summarized the spam situation on the IAB mail list. It is taking a lot of time to handle the large number of messages that get caught in moderation. TMDA seems to be the answer.
Olaf took the action to determine who, if anyone, should be notified that senders to the IAB mail list might have to respond to the challenge in order for their message read.
Joe took the action to implement TMDA for the IAB mail list.
The technical topics on Sunday in Vancouver will be Elwyn on NAT-PT followed by Danny’s technical presentation that was originally scheduled for the Nov 28th Tech Chat.
Some of the BOFs scheduled for Vancouver are not covered. IAB members were asked to make sure coverage was complete.
The Techchat on the 28th is cancelled. The Techchat queue is now empty. IAB members were requested to suggest topics of interest.
8.1 IGF Update
Leslie reported from her experience attending the Internet Governance Forum (IGF) meeting in Rio. IGF is a forum for any number of stakeholders beyond the people with whom the IAB normally interacts, namely ICANN, RIRs, ITU, IETF. This includes government and representatives from civil society to discuss whatever is intended to be governance of the Internet.
Leslie reported that participating in the IGF provided opportunities to bridge some of the gaps between the usual types of people we talk to about the usual topics. It provided a perspective on other concerns. IGF is not a decision-making organization itself, but the people who are participating are the ones who will be making decisions in their own country.
No immediate action required by the IAB.
8.2 OECD Governmental
ISOC is leading the input from the technical community into this meeting. The object of meeting is to update the policy style declarations from Ottawa in 1998, intended as high-level guidance to governments as to what they should be doing with respect to policy for the Internet. ISOC is doing the heavy lifting.
In terms of what IAB might want to do, it is mainly a matter of making sure what is said is important. If we get it right, it is unlikely that there will be any real impact back on the IETF.
It is really a matter of making sure we put in the right guidance. There is a draft declaration which has been which is where these things are being put together. The current draft declaration does include some things that the IAB considers completely inappropriate. So, some individual IAB members intend to send in comments. The goal is to make it more forward looking and to make sure the Internet is seen as a tool for use in e-commerce rather than a separate item in itself. It is not isolated from the rest of commerce. Another goal is to make sure that governments realize that the Internet is still a developing thing, and that money continues to be required for research, education, and developing infrastructure.
There are still opportunities for speaking, and some IAB members were encouraged to participate.
There seems to be very little that the IETF or IAB can do at this moment.
The RFC Editor has produced an RFC errata document and a tool that implements the specified process. Olaf has received a login and password for the tool — it is for use by the whole IAB.
The RFC Editor intends to be at the breakfast meeting on Tuesday morning in Vancouver to outline some of the issues and to outline the process.
There is one errata in the queue for the IAB to review. The RFC Editor has other errata reports that have not been verified. They refer to document that either pre-date the stream concept or they are prior to the RFC Editor recording the streams.
An IAB consensus call will be used in the validation of RFC errata that are associated with IAB Stream documents.