Dear Colleagues,
The IAB is working towards implementing structured approaches by which
it can more effectively execute its chartered responsibilities; in
particular improving the long-term perspective on the Internet informed
by technical and architectural considerations.
Below I first describe the general working method and then describe
the various programs and initiatives that we have currently identified
and have started to execute.
We will be publish this information in a more maintainable and
accessible after the vacation period.
=== On Initiatives and Programs ===
Traditionally the IAB has taken an interest in a number of
architectural areas. Among the architectural areas, in no particular
order:
- IPv6 and its adoption and transitional coexistence with IPv4 given the
realities of an IPv4-dominated Internet;
- DNS health and security;
- Web security;
- The realities of maintaining the end-to-end and layered
architecture;
- Prevention of unwanted traffic;
- The security and stability of the routing system; and
- Internationalization of the Internet and balance with localization
and retention of a global network.
For some of the areas the IAB may consider committing a short-term
effort, where an activity is expected to be completed in less then one
tenure of an IAB member. We call such activities initiatives. Usually,
the outcome of an initiative will be guidance provided in the form of
IAB Stream RFCs, statements, or working group/plenary presentations.
There are some areas that require long-term perspective and may involve
various activities and deliverables. For instance, such complex area
may require a separate activity for scoping the work (BOFs,
presentations, position papers), progressing the work, or stimulating
the charter development of new work in the IETF. Such effort may
involve collaboration with other organisations.
Work in such areas is organized in the form of a program.
A program is a long term activity scoped and managed by the IAB,
although for the actual work the IAB may form a team with specific
expertise needed for the activity, which may not be within the IAB.
Structuring work in this way has several objectives:
- minimise dependency on the current IAB composition and specific
expertise and competencies of its members;
- minimise dependency on the tenure of IAB members;
- increase bandwidth by shifting responsibilities of IAB members from
doing the actual work to organising and delegating work, and
providing guidance;
- shift the IAB focus from the specifics of an activity to the
development of the vision and maintenance of the big picture, to
selecting priority areas and carrying out respective efforts.
- improve visibility of the activities the IAB is busy with and provide
an opportunity to the community to provide feedback on the content and
priority of specific activities.
Programs can be thought of as IAB directorates, small task forces, or
ad-hoc bodies of (independent) technical experts (see RFC2850 Section
2.1).
The program lead will usually be an IAB member. The objective of the
program lead is to facilitate activities within the program, provide
an oversight and ensure continuity . The lead doesn't need to have
specific expertise in the area, but must have good general
understanding of the issues from technical, business, and or policy
perspective. The lead is expected to bring the IAB perspective to the
work. The IAB as a whole will periodically review the state of the
program and the progress, and make necessary adjustments and
prioritization.
The subject areas and related programs are periodically reviewed by the
IAB. Selected programs and initiatives form an activity plan. This plan
is communicated to the community and feedback is solicited.
--------------
Below you will find a description The Actual Programs and Initiatives
as committed to by the IAB. For completion we have also listed the
reoccurring responsibilities.
--------------------- Programs ----------------------------
1. Privacy Program =================================
1.1 Description
The IETF is known for its contributions to the design of the Internet
and the specifications IETF participants produce belong to different
categories, such as technical specification, best current practice
descriptions, and architectural documentation. While these documents
do not mandate a specific type of implementation they are often, if
not always, impacted by different architectural design decisions.
These decisions are influenced by technical aspects, expectations
about deployment incentives of the involved entities, operational
considerations, security frameworks, etc.
Privacy is another one of those design considerations. More and more
information is being digitized and made available electronically.
Unfortunately, as this information becomes available, it gets exposed
in unpredictable and surprising ways. IETF specifications cover a wide
range of technologies; some of them expose more privacy sensitive
information than others. From the long experience of the IETF, the IAB
believes that an important initial step is to consider privacy while
designing protocols and architectures, rather than having privacy be
something that is "bolted on" as an afterthought. The IETF has
successfully applied this method with a number of design criteria in
its process, most notably security.
The IETF has been considering privacy in protocol designs for many
years already, although often implicitly and without thorough
documentation. As initial work the IAB hopes to incorporate the aspect
of privacy more explicitly in the design of protocols. This requires
IETF participants to understand the terminology, and to be alert to
factors that negatively influence privacy.
Privacy poses challenges for many different entities and sectors
involved in the development and use of technology. Implementers and
developers, regulators, law enforcement, and other SDOs all have
strengths and weaknesses when it comes to identifying and addressing
the portion of the privacy puzzle that they are best suited to tackle.
In discussion with the IETF community, the IRTF, other SDOs developing
standards related to the Internet, and other stakeholders, the IAB
will try to investigate the role of standards developing organizations
in their work on more privacy friendly systems, and at the same time
gain an understanding of where the influence of the IETF ends.
Part of this IAB privacy program is to
1. provide consistent terminology for discussions relating to privacy,
2. foster discussion within SDOs and academia relating to the role of
privacy in Internet standards,
3. determine how the IETF can be most effective within that context, and
4. determine whether formalizing a set of privacy principles or
guidelines would be a helpful step in the development of IETF
specifications.
1.2 Responsible persons
- Hannes Tschofenig (IAB)(Lead)
- Bernard Aboba
- Jon Peterson
- Danny McPherson (IAB)
2. Internationalization Program ======================================
2.1 Introduction
Internationalization: continuing the development of guidelines with
respect to the trade-offs that need to be made when internationalizing
user facing protocol parameters.
2.2 The position of the IAB
The IAB has taken several initiatives to further Internationalization
(i18n) work within the IETF. Choices in architecture and protocol
design may affect a large set of Internet users and the lessons
learned from earlier experiences Those experiences include the
development of protocols to permit internationalizated content in
electronic mail and on the web, policies for character set usage and
coding, and the development, evaluation, and evolution of
internationalized domain names. That work can and should be subject to
ongoing review and generalized and extended into additional areas.
With this program the IAB intends to create a longer term effort that
not only involves ongoing evaluation and the development of guidance
but working with other organizations to expand both our understanding
of the issues and theirs.
2.3 Goals
Develop and provide guidance for architectural and strategic efforts
surrounding internationalization. Generate working documents,
organize workshops, and propose and develop relationships with other
organizations as needed.
3. IANA Evolution Program ==============================================
3.1 Introduction
Over the many years of its existence IANA, the IANA functions, and the
interpretations of its corporate governance have evolved in scale,
role, and management. The IETF has very specific needs with respect to
the protocol parameter registries and the Internet technical community
has a strong interest in stable evolution of all IANA functions to
continue to have the functions meet its need.
3.2 The role of the IAB
IANA was originally created in cooperation with the IAB; the current
IAB Charter [RFC 2850] includes responsibility for IANA oversight.
3.3 Charter
The IANA Evolution program members serve in an advisory role,
informing the IAB on issues related to IETF registries and the IANA
function and providing the IAB with non-binding advice.The program
will initially assist in the development and implementation of the
IAB’s position with respect to IANA’s evolution in the context of the
IANA functions contract rebid by the US Department of Commerce.
The members of the program team are appointed by the IAB. Its charter
and membership are reviewed annually.
4. SDO Coordination Program ======================================
4.1 Introduction
SDO coordination: this program is an effort to further coordination
between the various IETF-SDO liaison managers and the IAB. We will
initially shape this program around the ITU-T relationships, where
some of the highest frequency interaction currently takes place. The
objective of this initial phase of the program is to monitor and aim
to guide the emergence and development of close or possibly
overlapping work items in IETF and ITU-T. Examples include:
- Q.Flowstatesig in ITU-T SG11 Q5
- Codec in IETF RAI
- DPI in ITU-T SG13 Q17
- MPLS-TP in ITU-T SG15
Late exposure of these issues and lack of proactive coordination and
context may result in ad-hoc discussions and a less than ideal
reactive mode of handling this relationship.
To meet the objective it is proposed to create a subcommittee that
includes current liaison managers to ITU-T, as well as respective
liaison shepherds.
4.2 Role of the IAB
The IAB Charter (RFC2850) defines the external liaison role of the
IAB:
The IAB acts as representative of the interests of the IETF and the
Internet Society in technical liaison relationships with other
organizations concerned with standards and other technical and
organizational issues relevant to the world-wide Internet. 3.4.3
Charter
4.3 Charter
To fulfill its external liaison role the IAB appoints a number of
liaisons to ITU-T, and the IETF maintains liaisons at ITU-T and the
SG-level. However, as is intended, most of the inter-SDO work takes
place on an informal level and based on personal contacts, presence
and participation in both organizations.
At the same time the IETF is best served if developments are noticed
early and the leadership can make informed decisions about appropriate
actions to further the IETF work in the context of developments within
ITU-T. Equally, if work is being proposed in the IETF that may overlap
with work in the ITU-T, recognition and express consideration of this
by the IESG and IAB is necessary.
The IAB SDO Coordination subcommittee on ITU-T related technical work
is chartered to:
- Coordinate between different levels of liaison activity: the IAB
level and the IETF liaison level
- Produce proposals for IAB actions
- Track technical work within the ITU-T that relates to or has impact
on IETF work items and/or responsibilities and report consistently
- Perform advisory role to the IAB when handling developments in ITU-T
ITU-T SDO Coordination Sub-Committee members are appointed by the IAB.
Membership is based primarily on expertise and/or perspective, as well
as joint participation that members bring to the group. Members serve
on personal title. All appointed IETF liaisons to ITU-T are expected
to be members of this group, as well as at least one ISOC
representative.
--------------------- Initiatives --------------------------
1 "Data in the DNS" Initiative
What are the considerations for publishing data in the DNS instead of
using the DNS in order to get to a data store function. In addition to
applications using the DNS as a direct lookup mechanism, we also have
concerns about applications that require authentication, applications
that don’t return the same result to all queries, etc. trying to use
DNS “because it is there”. In addition, a number of issues have
recently arisen relating to the secure use of DNS for service
delegation.
2 "Canonicalization for Security Contexts" Initiative
Identifiers that are used for security purposes often occur in
protocols. Clear canonicalization rules are needed in order to be able
to unambiguously compare strings. This work will result in a document
providing the various considerations and pitfalls in designing
canonicalization rules.
3 "HTTP Guidelines" Initiative
The development of guidelines for the use of HTTP as either a substrate or foundation for other
protocols and applications that will reflect practices and experience
with BCP56.
----------------- Responsibilities --------------------------
1 Reoccurring Responsibilities
The IAB has a number of regular responsibilities in 2010-2011 that
fall under the periodic and reoccurring responsibilities umbrella. The
IAB will need to:
• confirm the IESG candidates (RFC3777)
• appoint a member of the ISOC board of trustees (RFC3677)
• appoint the IRTF chair (RFC2850)
• appoint the ICANN Board Liaison (ICANN Bylaws, Article VI, section 9, par. 1(f))
• handle any appeals
5.2 RFC Editor Model
The IAB is also responsible for RFC and Internet standards process
oversight and in that context it is responsible for tracking the
evolution and the implementation thereof. By the end of 2010 the
Transitional RFC Editor is expected to converge to final
recommendations. The IAB will be involved in the consideration and
approval of any of the recommendations provided therein. Depending on
the recommendations the IAB may have an important role in acquiring a
RFC Series Editor.
--Olaf Kolkman
IAB Chair
-----------------------------------
The Internet Architecture Board
www.iab.org
iab-chair@xxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf