IAB Minutes 2002-11-17 | Internet Architecture Board

Home»Documents»Minutes»Minutes 2002»IAB Minutes 2002-11-17

Minutes
IAB Meeting

17 November 2002, 2:00pm – 5:00pm EST
19 November 2002, 7:45am – 9:00am EST
19 November 2002, 6:00pm – 7:30pm EST
20 November 2002, 2:00pm – 5:00pm EST
21 November 2002, 8:00am – 9:00am EST

ATTENDING

Joyce K. Reynolds — Liaison from the RFC Editor
Lynn St.Amour — Liaison from ISOC

Patrik Faltstrom — invited for consideration of Item 4
Ned Freed — invited for consideration of Item 4
Frank Kastenholz — invited for consideration of Item 8
Sean Doran — invited for consideration of Item 8
Aaron Falk — RFC Editor liaison

APOLOGIES

Fred Baker

NEXT SCHEDULED MEETING

Tuesday, 10 December, 2002.

AGENDA

Rollcall, Agenda Bash and Previous Minutes
Review of Action Items
Review of Documents
Liaison Reports and Organization Updates
Internationalized Resource Identifiers
Service Blocking by Port
End-to-End DiffServ and QoS
IAB RFC Publication Procedure
IAB Review of the Routing Research Group
IPv6 Transition Workshop
IAB Plenary Session
ISOC, IETF and Government-sponsored Research
Any Other Business
- VOIP Transport Issues

NOTES

0. Rollcall, Agenda Bash and Previous Minutes

8 October 2002

1. Review of Action Items

below

2. Review of Documents

below

3. Liaison Reports

IESG
The IDN effort has been closed down, with the reminder of the material going forward as individual drafts. It was reported that there is current consideration of a draft articulating value in registry policy in this space.

The IAB security considerations document is being considered by the IESG. It is anticipated that raised concerns will be addressed with a number of edits in one further revision to this document.

RFC EDITOR
The RFC Editor reported that the Plenary session will include additional statistics on the RFC Editor queue and the associated status of documents in the queue.

IRTF
The IAB noted that the review of the Routing Research Group (RRG) was useful and informative, and the IAB thanked Frank Kastenholz and Sean Doran for their efforts in preparing for this review. It was hoped that further Research Group reviews could be conducted in the near future, noting that the face-to-face review was considered of higher benefit than a teleconference-based review for all concerned.

The IAB also noted that RGs can request meeting rooms at IETF meetings, and expressed the hope that RGs would continue to use the IETF as a meeting venue.

Vern Paxson noted that in other IRTF activity a group was in the formation stage that was proposing looking at issues associated with names and naming at a higher level than the DNS, and having some relationship to searchable structures and would contain some component of international character sets. If this was to be chartered it was anticipated to operate for 1-2 years.

The MANET WG considered a proposal to move the research component of its activity into a subgroup of the RRG. This met with WG support and a subgroup of the RRG will be formed.

There was also some interest expressed in a peer-to-peer RG with a component related to the JXTA activity. The interest was in JXTA and other peer-to-peer service models and the service distribution function. It was noted that there is some visible difference in approach between the commercial direction in peer-to-peer models and those used within the academic and research community. Such an RG effort may include consideration of scaling to very large numbers of nodes.

The IDRM RG has been at a low activity level for some time, and the observation was made that there may be no significant IETF constituency for this topic at present. There has been some thoughts in revising the group’s charter to emphasize privacy aspects as expressed as information about individuals and the rights to view such information and in what context. This is being considered by the RG and a decision will be made following this consideration.

The IRSG had also discussed the option of a workshop related to the IAB activity on Internet research topic. This will be further developed by the IRSG.

ISOC
The Board of Trustees of ISOC met on the 16th and 17th November. It was reported that it was the intent of ICANN to award the .org registry to a commercial subsidiary of ISOC, with the arrangements anticipated to be concluded by the end of November and a transfer scheduled for 1 January.

ITU-T
The IAB had received a copy of a draft ITU-T press release concerning ENUM, and will be communicating some comments to the ITU-T in response.

W3C
A joint teleconference with the W3c was held on the week of the 11th November. The topics covered included discussion over coordination efforts on MIME media types and the Internationalized Resource Identifiers proposal.

PSO-PC and ICANN
It was reported that no meetings of the PSO had been held since the previous IAB meeting, and no items to report.

RSSAC
It was noted that the IAB liaison nominee to RSSAC, Rob Austein, had not been added to the RSSAC lists. A followup with ICANN over this liaison was noted as an action.

4. Internationalized Resource Identifiers

This is a W3C proposal for a new identifier, the Internationalized Resource Identifier (IRI), intended as a complement to the current URI (draft-duerst-iri-02.txt).

While this is an individual submission to the IETF, this draft represents a W3C working group output, and there are W3C working groups, including XML Core, that are indicating some interest in the use of IRI.

The IAB discussed IRIs, noting topics of protocol and presentation elements, equivalence testing, explicit reference to character set encodings, canonical forms for protocol elements and associated preparation functions and normalization, and the issues of comparing composed and single character encodings. It was noted that the relationship of IRIs to URIs is explored in the draft but a detailed review of how IRIs and URIs inter-relate may still be required. It was also noted that there is a lack of a general normalization operation that would allow a deterministic equivalence test for IRIs.

The IAB will review a document describing the weaknesses of the IRI approach in the context of the proposed use as a protocol element, and the issues raised in the IAB consideration of the IRI proposal will be passed to the W3C Technical Advisory Group through the liaison role.

5. Service Blocking by Port Addresses

The IAB was requested to review a draft ISOC statement commenting in recent actions by a regulatory body regarding the intended blocking of service ports commonly used by VOIP applications. The IAB discussed the general ramifications of wide scale port blocking. <\p>

The general observation was made that widespread use of port blocking could lead to more cases of protocol design being undertaken in such a manner as to use a common rendezvous protocol and then to negotiate port use in terms of observed capabilities of the end-to-end network path. This could be characterized as a protocol model where the identity of the service and the service payload is deliberately hidden from the network and from various intermediaries that may exist on the end-to-end path. It was also noted that in such cases the design choice regarding protocol behaviour is not being made by the user, but by the protocol or application designer. The implications of such actions on firewall functionality, and the inherent design tradeoffs in this approach were discussed by the IAB.

A document will be prepared on this matter that describes these issues in further detail.

6. End-to-End DiffServ and QoS

In connection with current activity in the IEPREP WG, the IAB considered the issues relating to the deployment of End-to-End DiffServ in today’s IP service networks.

The IAB noted that the issues documented in RFC2990 have not changed substantially regarding the deployability of QoS systems, including signaling feedback issues associated with resource management, and the difference between per-ingress traffic management and per-path resource and performance management. In addition, it was noted that the current extensive overprovisioning practices of transit ISPs tend to obviate the strict requirement for supporting explicitly prioritized traffic in all parts of the Internet.

The IAB noted that this topic was a valid area of continued research activity.

7. IAB RFC Publication Procedure

The IAB discussed the manner by which external standards bodies can pass documents into the IETF for consideration. The IAB noted that Internet-Drafts from other standards bodies are currently published with either the editor’s name, or the organization’s name in the draft title.

The IAB reviewed a draft description of the current process for the publication of IAB documents as informational RFCs. The draft will be revised as per IAB comments and then posted for wider review and comment.

8. IAB Review of the Routing Research Group

The co-chairs of the Routing Research Group (RRG), Frank Kastenholz and Sean Doran presented a summary of the current status of the RRG to the IAB.

The objective of the RRG is the exploration of problems that are seen as important, but not yet mature enough for engineering work in the IETF, as well as offering an informal forum for reviewing relevant research work. The RRG operates in an umbrella mode, creating more specific subgroups as required to address work in particular areas of routing. It is seen that this represents an appropriate administrative framework for activities that are not-quite-IETF. There is ongoing work on inter-domain and intra-site routing issues, including the traditional intra/inter domain routing split.

Within the inter-domain area the RRG has published two inter-domain routing requirement documents as internet-drafts. It is intended to merge these two documents into a single document for publication as an Informational RFC. There are aspects of the observation that the BGP-inexpressibility of some possible actions constrains the Internet and the fact that BGP can or cannot do something are implicit constraints when phrasing current issues within inter- domain routing. As a general comment, it is recognized that overall level of knowledge in this area is very incomplete.

Micro-mobility sub-group is working on a set of drafts that originated from the SEAMOBY WG activity, and some agenda shaping is currently underway.

At this stage the RG believes that it is still grappling with an effective entry strategy, and it is not of the opinion that its yet time to consider any form of exit strategy. The future plans of the RG include continue work in inter-domain routing, micro-mobility, mobile ad-hoc networking routing issues, consideration of the total routing cost. Outside of these immediate plans the RG is awaiting further ideas and proposals.

While it was noted that there is no strong consensus in the research area as to the future directions of routing, and there are a large number of research topics in this domain.

9. IPv6 Transition Workshop

Rob Austein noted interest in this topic from the IESG, and a consensus that this was a good workshop topic. The issue here is that a number of proposed transition mechanisms create new security issues, and are not necessarily deployable solutions.

Potential outcomes include considerations document in classifying solutions in terms of their risks. The intention is to look more at classes of mechanisms rather than specific mechanisms. In practice it appears that the V6ops WG could use some assistance in this area, and it is intended to coordinate V6 and V6ops WG chairs on this. It is noted that a number of unfinished ngtrans items have not been integrated into the V6ops charter, and the utility and security of various proposed transition mechanisms has yet to be explored.

The proposal is to be recirculated with the intention of preparing logistics for the workshop.

10. IAB Plenary Session

IAB Chair
The IAB chair reported to the plenary of the IETF on recent IAB activities, including the IAB Network Management Workshop, the UNSAF RFC, the Architectural Considerations RFC, the joint IESG / IAB retreat and the responses to the ICANN Evolution and Reform process.

ISOC
Lynn St Amour of ISOC presented plaques to IAB and IESG members whose terms had ended in 2002 in recognition of their service to the IETF. Plaques were presented to Brian Carpenter, John Klensin, Henning Schulzerinne, Marcus Leech, and Jon Crowcroft (absent)

ICANN
An update on ICANN was presented, noting the intended arrangements relating to the nomination of 2 members to a Technical Liaison Group, a non-voting liaison to the ICANN Board and 1 (of a total of 19) voting member to the Nominating Committee. The relationship is noted as becoming predominately liaison related.

IANA
IANA Update report was presented to the plenary session. 13 new registries have been set up in the July-October’02 period, based on RFC documented IANA considerations. 2 x /8 IPv4 address blocks were allocated in July and August and 1 AS block in September. IANA is working on a process to create a snapshot of the registry. There is a proposed IANA Matrix to provide guidelines relating to an IANA protocol assignment process. An IANA ifType application will be bought up soon, and documents relating to IANA considerations for RSVP parameters and Port Numbers. A new IANA staff person, Jennifer Rodriguez to join Michelle Cotton.

The report described the assignment process for RFCs-to-be. The IANA process involves taking the RFC announcements and checking for IANA Considerations relating to protocol parameters. A message will then be sent to authors, WG Chairs and relevant ADs to confirm registry requirements. The IANA then sends confirmation to the RFC Editor of completion of IANA functions and then await confirmation advice from the RFC number to then complete the registry set up.

IRTF
The goals of the IRTF were described. There are currently 12 research groups, generally long-lived without specific deliverables. Most operate in an open mode, although some are closed. Noted that the crypto forum is now active. The Internet Measurement RG is now active and operates in an open mode. The Interplanetary Internet RG has been transformed into the Delay Tolerant Networking RG. The Routing RG has added a MANET subgroup. Potential additional activities include peer-to-peer technology and searchable names research group.

RFC Editor
Joyce Reynolds and Aaron Falk presented on the RFC Editor role. An analysis was presented on the RFC Editor queue. It was noted that the RFC Editor team is reported as 3 x FTE in terms of workload. It was noted that the arrivals are bursty. The queue size has increased over mid-2002. There are new management tools to track documents and to synchronize the RFC Editor activity with the IESG. Staffing issues have been addressed and SIP and SNMPv3 document burst loads have been addressed. The RFC Editor is reported to be operating at a load level that is near capacity. The Auth48 hour step is particularly onerous for the RFC Editor in terms of processing changes submitted at this point. Noted that clear concise authoring with careful attention to format assist here. All authors need to be contacted for 48 hour approval. There was an IETF audience request for structural markup to allow for clarity for checking in AUTH48 phase. Also noted some issues with transformation to runoff from the plain text draft. The RFC Editor reported that the approval to publish from the IESG, in the view of the RFC Editor related strictly to the ascii text in a formatted version, and the RFC Editor did not work from the original pre-format sources. The report noted that 192 RFCs have been published in the previous 12 months, with a total of 5,147 pages. RFC Editor draft (2223bis) has been updated. Improved internal document progress and workload tracking have been implemented. There is the intention to use an XML index file, queue statistics and links between RFCs and errata.

ISOC BoT Selection Process
Report on ISOC Board of Trustees selection process was made. A summary of the 2002 process was presented, noting the nomination of Fred Baker and Erik Huizer as the outcome. The proposed process was described, with the phases of an open call, the publication of the candidate list, IAB selection and IESG confirmation of the selection of nominations to the ISOC Board. The next step is publication of an Internet draft and IETF community review of the draft.

IANA Definition
Presentation on draft-huston-iana-00.txt by Geoff Huston. There was general assent at the plenary for this individual submission to be adopted as an IAB draft and further developed by the IAB.

UNSAF
Presentation on RFC3424 (UNSAF), noting that while there was a long term MIDCOM architecture there was a short term set of solutions that have the risk of sustaining some level of confusion. By circumventing NATS UNSAF mechanisms may also compromise deliberate and intended security mechanisms that are associated with NATS and firewalls, and there is now a round of independent processes attempting to second guess and outsmart each other.

11. ISOC, IETF and Government-sponsored Research

The IAB was briefed on activities related to initiatives in public funding of research concerning Internet security. Discussion of this topic noted possible benefit in clarifying the agenda concerning the DNS and inter-domain routing through workshops and advanced training activities.

The IAB recommended that ISOC communicate with the public funding program managers and convey the IAB’s support for such public funding of research and practice. Some possible examples of the activity could include the generation of a BCP describing responsible operational procedures that would assist in securing IP service platforms, a security gap analysis of IETF standard protocols, and an effort to complete the secure DNS activity to the point of wide availability and use in the Internet.

12. Any Other Business

VOIP Transport Issues

The IAB considered the potential position of stating a preference to use congestion control as a part of the VOIP transport service with its associated implication of the use of dynamic codec adaptation over the use of non-congestion-sensitive transports coupled with active network response mechanisms.

It was noted that the VOIP spec indicates that transports (RTP) should behave in a good manner. It was noted that the Transport ADs have considered this matter and there is some indication that DCCP is a reasonable direction, with further work required in this area. The IAB explored the scope of a potential comment along the lines of observation and definition of the problem space of voice transport, note the IETF activities in this area, and then note relevant considerations. There is the potential to recommend the use of high quality codecs that can work with what the transport area comes up with in terms of congestion detection and response. It was noted that this direction is along the lines of advocating transport control and congestion signaling to the application level.

The IAB indicated an interest in this activity, noting the requirement to involve the Transport ADs in this at an early stage.

ACTIONS and DOCUMENTS

Actions

iab.org
IAB Network Management Workshop
RFC Individual Submission review
ICANN Evolution and Reform Followup
IAB Research Agenda
ISOC Trustee Appointment Process
IAB IPV6 Deployment Security Workshop
IAB / IESG Retreat
.ARPA Domain Name Servers
SC22 Liaison
802.11 Enrolment
IAB RFC Publication Process
Internationalized Resource Identifiers
ITU-T ENUM Draft Press Release
IAB comment on ISOC statement regartding Panama and VOIP blocking
RSSAC Liaison Status
Externally submitted drafts

Documents

IAB Considerations
draft-iab-considerations-03.txt
Security considerations, including common security attacks
draft-iab-sec-cons-01.txt
Security Mechanisms for the Internet
draft-iab-secmech-01.txt
IETF PSO-PC Process
draft-iab-pso-appointments-00.txt
IAB Considerations for UNilateral Sel-Address Fixing (UNSAF)
draft-iab-unsaf-considerations-02.txt
A survey of Authentication Mechanisms
draft-rescorla-auth-mech-00.txt
Referential Integrity
Internet Architecture and End-to-End
Network Management Report
draft-iab-nm-workshop-01.txt
Internationalized Resource Identifiers
Service Identification in packets
Transport Controls for VOIP
IANA Definition
draft-iab-iana
ISOC Trustee Appointment Process

FUTURE MEETINGS

Slides used at the Open IAB Plenary

Slides – Daigle

IAB Plenary

IETF 55 – Atlanta
November 20, 2002

Agenda

Local host keynote address
- ari Pasanen, Nokia
IAB Chair’s remarks
ISOC recognition of recent IAB, IESG folk
IETF NomCom update
Update reports: IANA, IRTF, RFC-Editor
Proposed IETF ISOC BoT appointment process
Review of IETF-IANA function document
Overview of RFC3424 — UNSAF
Open mic for architecture

Chair’s Remarks
What the IAB has done lately

Network management workshop
- Report draft published (draft-iab-nm-workshop-01.txt)
Recent RFCs
- RFC 3424: IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
- RFC 3426: General Architectural and Policy Considerations
Got together with the IESG (October 17/18, 2002)
Various communications.
- http://www.iab.org/selected-iab-documents.html
- includes IAB responses to ICANN ERC updates

ICANN update

Current ICANN evolution & reform proposal, with implementation resolutions, calls for IETF input:
- TLG: appoint 2 technical people to the Technical Liaison Group
- ICANN BoT: appoint a non-voting liaison
- ICANN BoT NomCom: appoint 1 delegate annually (of 19 delegate committee)
Of note: The Protocol Support Organization goes away
Relationship is liaison-oriented

Slides – Cotton

Report on the IANA

New Registries

Our Workload – Protocols
July 2002

IANA ifTypes MIBs	4
Language Tags	9
Megaco Private Packages	4
Mobile IP Codes	1
Private Enterprise numbers	392
SCTP port numbers	1
User TCP/UDP port numbers	25

Our Workload – Protocols
August 2002

AKA Versions	1
CNRP Properties	5
CNRP Property Types	10
CNRP Status Messages	27
COPS Client Types	2
Internet Message Content Types	6
Mail Content Disposition Values	2
MDN Extension Field Names	1
MIME Media Types	41
PIBs	3
Private Enterprise Numbers	284
RTP Payloads	1
SDP Attributes	3
SIP Header Fields	1
SIP Option Tags	1
SIP Precondition Types	1
SIP Response Codes	2
Transmission Numbers	1
URL Schemes	1
URN Informal Namespace	1
User TCP/UDP Port Numbers	37

Our Workload – Protocols
September 2002

Character Sets	3
Megaco Error Codes	1
Megaco Public Packages	19
Private Enterprise Numbers	253
SDP Attributes	2
SigComp Namespace Registrations	1
SIP Header Fields	5
SIP Option Tags	2
SIP Privacy Headers	1
User TCP/UDP Port Numbers	23

Our Workload – Protocols
October 2002

DHCP Option Codes	1
Experimental Numbers	1
GSTN Extensions	6
IANA ifType MIBs	1
L2TP Attributes	4
L2TP Result Codes	2
Megaco Public Packages	5
MIB-2 Numbers	2
MIME Media Types	5
Private Enterprise Numbers	303
ROHC Profile Identifiers	1
SCTP Payload Ids	1
SDP Attributes	7
Sieve Extensions	1
SIP Methods	1
SVRLOC Templates	2
User TCP/UDP Port Numbers	25

Our Workload – Addresses

(2002)	July	Aug	Sept	Oct
IPv4 Multicast	0	0	0	2
AS #s	0	0	1 blk	0
IPv4 RIR Alloc	1 /8	1 /8	0	0

Current Projects

RFC1700 type document
IANA Matrix
IANA ifType application
More documents on IANA Considerations (RSVP and Port Numbers)
New IANA staff person:

Assignments for RFC’s-to-be

Approval
Check for IANA Actions
Check with authors/wg chairs/Ads
Note to RFC Editor
Confirmation from RFC Editor

Please e-mail any questions to
iana@iana.org

Thank you!!

Slides – Paxson

IRTF Status Report

irtf-chair@irtf.org
http://www.irtf.org/
vern@icir.org

November 20, 2002

IRTF Role & Scope:

Goals are to:

Currently, 12 RGs.
Generally long-lived, usually without specific deliverables.
Most operate open, some closed.
Closed ones maintain an open, public mailing list.

http://www.irtf.org/

Recent changes/news:

http://www.irtf.org/cfrg/

Internet Measurement RG now active:

http://imrg.grc.nasa.gov/imrg/

Interplanetary Internet ) Delay Tolerant Networking:

http://www.dtnrg.org/

Routing: adding new MANET subgroup.
Possibly brewing:

Slides – Reynolds

RFC Editor -IETF Report

Accomplishments

Published 192 RFCs in last 12 months
- That’s 5147 pages (with another 256 pages in AUTH48)
Independent Submissions have been added to:
Updated draft-rfc-editor-rfc2223bis-03.txt
Published RFC 3300
Improved Internal document progress and workload tracking

Work In Progress

XML-Based index file
- Page counts will be available in the XML version of the index.
Improving monthly queue statistics:
Improving links between RFCs & errata:

Policy Updates

RFC 2119
- This must be cited as a normative reference
Abbreviations
- Most abbreviations must be spelled out the first time they appear in a document

Throughput

MONTH	# Submitted	# Published	# Not Pub’d
July 2002	16	12	1
August 2002	19	31	2
September 2002	21	30	3
October 2002	32	17	4
November 13, 2002	17	6	2

Total in Queue	105	95	12

Queue Update

Less than 1 month

1 – 2 months

2 – 3 months

IESG:	1
AUTH48:	4
References:	5
RFC Editor:	2
IANA:	1

More then 3 months

IESG:	22
AUTH48:	19
References:	16
RFC Editor:	6
IANA:	1

TOTAL

142

IESG Documents

2 – 3 Months

draft-klensin-dns-role-03.txt	IESG/TO
draft-ietf-mmusic-fid-06.txt	AUTH48
draft-ietf-ippm-ipdv-10.txt	AUTH48
draft-ietf-snmpv3-rfc2570bis-03.txt	AUTH48
draft-ietf-rohc-rtp-lower-layer-guidelines-03.txt	AUTH48
draft-ietf-fax-service-v2-05.txt	REFERENCES
draft-ietf-ipv6-default-addr-select-09.txt	REFERENCES
draft-ietf-vpim-address-03.txt	REFERENCES
draft-ietf-rmt-pi-alc-08.txt	REFERENCES
draft-ietf-rmt-bb-lct-04.txt	REFERENCES
draft-ietf-dhc-csr-07.txt	RFC Editor
draft-ietf-rmt-info-fec-03.txt	RFC Editor
draft-ietf-rmt-bb-fec-07.txt	IANA

IESG Documents

3+ Months

draft-ietf-apex-presence-06.txt	IESG
draft-ietf-jl-pcdp-01.txt	IESG/TO
draft-tiwari-appl-wxxx-forms-01.txt	IESG/TO
draft-wu-rgmp-01.txt	IESG/TO
draft-wildgrube-gnp-03.txt	IESG/TO
draft-eastlake-proto-doc-pov-04.txt	IESG/TO
draft-new-apex-server-02.txt	IESG/TO
draft-agrawal-sip-h323-interworking-reqs-02.txt	IESG/TO
draft-heinanen-inarp-uni-01.txt	IESG/TO
draft-elson-icap-00.txt	IESG/TO
draft-mails-sonet-ces-mpls-05.txt	IESG/TO
draft-kindberg-tag-uri-01.txt	IESG/TO
draft-tegen-smqp-08.txt	IESG/TO
draft-dfncis-netnews-admin-sys-04.txt	IESG/TO
draft-mealling-iana-xmlns-registry-03.txt	IESG/TO
draft-khan-gaur-secure-mpeg-syntax-00.txt	IESG/TO
draft-fleming-ldap-printer-schema-01.txt	IESG/TO
draft-arkko-map-doi-07.txt	IESG/TO
draft-gustin-goyens-urn-id-02.txt	IESG/TO
draft-kunze-rfc2413bis-01.txt	IESG/TO
draft-walsh-urn-web3d-00.txt	IESG/TO
draft-gurbani-sin-02.txt	IESG/TO
draft-ietf-snmpv3-update-proto-08.txt	AUTH48
draft-ietf-snmpv3-update-transmap-08.txt	AUTH48
draft-ietf-snmpv3-update-mib-07.txt	AUTH48
draft-ietf-ospf-nssa-update-11.txt	AUTH48
draft-ietf-snmpv3-arch-v2-02.txt	AUTH48
draft-ietf-snmpv3-mpd-v2-02.txt	AUTH48
draft-ietf-snmpv3-appl-v3-01.txt	AUTH48
draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt	AUTH48
draft-ietf-snmpv3-vacm-v2-01.txt	AUTH48
draft-ietf-pppext-ppp-over-aal2-03.txt	AUTH
draft-ietf-sip-privacy-general-01.txt	AUTH48
draft-ietf-sip-reason-01.txt	AUTH48
draft-willis-sip-path-08.txt	AUTH48
draft-sip-call-auth-06.txt	AUTH48 (Beser Bercak document)
draft-ietf-sip-asserted-identity-01.txt	AUTH48
draft-ietf-sipping-nai-reqs-02.txt	AUTH48
draft-herriot-application-multiplexed-05.txt	AUTH48
draft-okamoto-mac-over-mapos-02.txt	AUTH48
draft-kzhang-crane-protocol-03.txt	AUTH48
draft-ietf-ipsec-dhcp-13.txt	REFERENCES
draft-ietf-iptel-cpl-06.txt	REFERENCES
draft-ietf-pppext-ppp-over-aal2-class-02.txt	REFERENCES
draft-ietf-vpim-vpimv2r2-05.txt	REFERENCES
draft-ietf-vpim-vpimv2r2-32k-03.txt	REFERENCES
draft-ietf-vpim-vpimv2r2-dur-03.txt	REFERENCES
draft-ietf-avt-rtp-mime-06.txt	REFERENCES
draft-ietf-avt-rtcp-bw-05.txt	REFERENCES
draft-ietf-vpim-hint-08.txt	REFERENCES
draft-ietf-rohc-sigcomp-extended-04.txt	REFERENCES
draft-ietf-rohc-signaling-req-assump-06.txt	REFERENCES
draft-ietf-ipv6-cellular-host-03.txt	REFERENCES
draft-irtf-nmrg-snmp-tcp-09.txt	REFERENCES
draft-ema-vpim-cb-02.txt	REFERENCES
draft-zeilenga-cldap-02.txt	REFERENCES
draft-chiba-radius-dynamic-authorization-05.txt	REFERENCES
draft-ietf-rohc-sigcomp-07.txt	RFC Editor
draft-ietf-diffserv-pib-09.txt	RFC Editor
draft-ietf-rap-framework-pib-09.txt	FC Editor
draft-rajeshkumar-mgcp-atm-package-07.txt	RFC Editor
draft-andreasen-mgcp-rfc2705bis-05.txt	RFC Editor
draft-ymbk-arch-guidelines-05.txt	RFC Editor
draft-ohta-mpls-label-value-03.txt	IANA

Slides – Falk

How long does it take to publish an RFC?

Aaron Falk

Background

The RFC Editor has been concerned over the delays in processing RFCs
We’ve spent some time analyzing the historical data on the queue
This presentation is a chance to inform the community what we’ve learned
The challenge with data is that it raises questions as it informs
- We don’t plan to do further analysis: these are just hints

The RFC Editor Process

Flow and states are defined in this diagram
> (this is online, link to follow.)

RFC Editor queue data from July 1999

Caution: the data is noisy and incomplete
- State names & definitions have evolved
Missing data in spring ’02
- This is unfortunate because the delays became quite long in this period
Values shown are medians

Measured Median Time to Publish an RFC

EDIT	7.1 wks
RFC-EDIT	3.8
AUTH48	1.6
	9.7 wks

For independent submission add:
ISR	5.2 wks
TO	5.8
	11.0 wks

Measured Median Time to Publish an RFC

– For AUTH add	1.2 wks
– For IANA actions add	3.5 wks
– For REF add	7.1 wks
– For IESG noodling add	9.4 wks

If the median is 2.5 months, why does it feel like it’s taking longer?

Distgribution has a long tail

Why have some documents been delayed so long?

The RFC Editor is a small team
- Attention to quality requires time
- Staffing issues have enhanced visibility
Document arrivals are very bursty
“Authors 48 hours” is not

Queue arrival & departure rate per month

Note bursts in recent queue

Queue Size

Things are getting better.

Have new management tools for tracking progress
- Helps ensure no docs slip through cracks (particularly important with IETF review of Individual Submissions)
- Bill Fenner’s web page checking IESG/RFC-Ed queue consistancy
Short term staffing issues are largely solved
- Increased editing capacity
Recent arrival burst has largely passed
- SIP, SNMPv3 docs
- But another may come along any time.

Challenges Remain

RFC Editor appears to be operating near capacity
Auth48 is a critical step in ensuring quality
- Again, at a cost of processing delays

What Can Authors Do?

Submit quality documents
- Clear, concise writing
Pay attention to formatting
- 2223bis has editorial policies
Be responsive
- Need all authors for final approval

Slides – Daigle

Review of IETF Internet Society (ISOC) BoT appointment question

As of last year, IETF is called on to select members of the ISOC Board of Trustees (BoT)
Followed an interim procedure last year
- Open call for nominees; IAB selection confirmed by IESG
Need to formalize a process for this and following years
Proposal outline tonight; will be circulated & discussed as I-D soon

Proposed IETF ISOC BoT appointment process

Annually, IAB to post an open call for nominations (on ietf-announce)
IAB to publish and select from candidate pool
IESG to confirm selection
Detail needed: coordination with rest of ISOC BoT election process (org & chapter elections)

Where from here

IAB will draw up an Internet-Draft capturing this proposal, with adequate detail
Community review
Implement for next year’s appointment to ISOC Board of Trustees

Slides – Huston

Defining the IANA Role

Geoff Huston

Background

ICANN Evolution and Reform Process
The IETF has an interest in ICANN
- ICANN performs the IANA protocol parameter registration function for the IETF
- Can we describe, clearly and precisely, the IANA role undertaken by ICANN for the IETF?

Why Define the IANA Role?

We have no agreed description of the IANA function for the IETF
What we do have:
- We have IANA Considerations in RFCs (RFC2434)
- We have an IAB Charter that says that the IAB is responsible for the IANA function (RFC 2850)
- We have a MoU with ICANN that describes ICANN’s role (RFC 2860)
But no definition of the IANA function itself

Plenary Proposal

That the IAB adopts a formal definition of the role of the IANA for the IETF
- The “IETF-IANA”
That this definition clearly define the IETF’s requirements for protocol parameter registration functions
That this definition exist independently of any delegation and/or contractual arrangements that may exist between the IETF and the delegated IETF-IANA operator.
That future contracts or agreements may refer to this IETF definition as a statement of work

Summary of IETF-IANA Role

Review and Advise
- Review Internet-Drafts and advise the IESG of relevant IANA Considerations
Register
- Operate a registry of protocol parameter assignments according to “IANA Considerations”
Mailing Lists
- Operate mailing lists as defined in IANA Considerations sections of IETF documents
Liaison
- Liaison to IESG and IAB
Reporting
- Performance report to the IAB
- Periodic reports to IETF Plenary
This definition is not intended to alter or redefine the role of the IETF-IANA as currently undertaken by ICANN

Status

Individual Proposal from Geoff Huston and Scott Bradner
Soliciting comments from the IETF regarding its accuracy clarity in defining the role of the IETF-IANA
Propose that the Internet Architecture Board adopt this draft and submit it through the IETF publication process as a BCP

Slides – Daigle

UNSAF Considerations (RFC3424)

What: “UNilateral Self-Address Fixing (UNSAF)”
- some originating process attempts to determine or fix the address (and port) by which it is known
- to be able to use address data in the protocol payload
- to advertise a public address from which it will receive connections.
Why:
- NATs cause discontinuity in address realms
- originating process may not know about that discontinuity
- the mapping is locked up in the NAT box

Architecture & Reality

Dogma: Not a problem if you have end to end, global addresses
Long term: Middlebox Communication (midcom)
In the meantime: heuristics & work arounds proposed

Architectural considerations

How does an UNSAF client find an appropriate UNSAF server to reflect its address?
- an address can only be determined relative to one specific point in the network.
By circumventing the NAT, UNSAF mechanisms may also (inadvertently) circumvent security mechanisms
- processes are second-guessing each other
Timeliness: UNSAF process must take care to react to changes in NAT bindings for a given application flow, since it may change unpredictably.
Brittleness: more points of failure & maintenance of state:
- UNSAF client & server are required to maintain information about the presumed state of the communication in order to manage the address illusion.

Practical Realities

There is no NAT standard
NATs don’t all behave alike
- may not handle UDP at all
- Lvariations in timeouts for holding address bindings
- etc

Role of RFC3424

Tool for documenting these considerations
Suggests some things that interim fixes might consider to mitigate the risks
Is intended as a “health warning” as to why these short-term fixes should be just that

These minutes were prepared by Geoff Huston; comments should be sent to iab-execd@iab.org. An online copy of these and other minutes is available at: http://www.iab.org/documents/IABmins/

The IAB Web page is at http://www.iab.org

Minutes IAB Meeting

ATTENDING

APOLOGIES

NEXT SCHEDULED MEETING

AGENDA

NOTES

ACTIONS and DOCUMENTS

Actions

Documents

FUTURE MEETINGS

Slides used at the Open IAB Plenary

Slides – Daigle

IAB Plenary

Agenda

Chair’s Remarks What the IAB has done lately

ICANN update

Slides – Cotton

Report on the IANA

New Registries

Our Workload – Protocols July 2002

Our Workload – Protocols August 2002

Our Workload – Protocols September 2002

Our Workload – Protocols October 2002

Our Workload – Addresses

Current Projects

Assignments for RFC’s-to-be

Please e-mail any questions to iana@iana.org

Slides – Paxson

IRTF Status Report

IRTF Role & Scope:

Recent changes/news:

Slides – Reynolds

RFC Editor -IETF Report

Accomplishments

Work In Progress

Policy Updates

Throughput

Queue Update

IESG Documents

IESG Documents

Slides – Falk

How long does it take to publish an RFC?

Background

The RFC Editor Process

RFC Editor queue data from July 1999

Measured Median Time to Publish an RFC

Measured Median Time to Publish an RFC

If the median is 2.5 months, why does it feel like it’s taking longer?

Why have some documents been delayed so long?

Queue arrival & departure rate per month

Queue Size

Things are getting better.

Challenges Remain

What Can Authors Do?

Links

Slides – Daigle

Review of IETF Internet Society (ISOC) BoT appointment question

Proposed IETF ISOC BoT appointment process

Where from here

Slides – Huston

Defining the IANA Role

Background

Why Define the IANA Role?

Plenary Proposal

Summary of IETF-IANA Role

Status

Slides – Daigle

UNSAF Considerations (RFC3424)

Architecture & Reality

Architectural considerations

Practical Realities

Role of RFC3424

Minutes
IAB Meeting

Chair’s Remarks
What the IAB has done lately

Our Workload – Protocols
July 2002

Our Workload – Protocols
August 2002

Our Workload – Protocols
September 2002

Our Workload – Protocols
October 2002

Please e-mail any questions to
iana@iana.org