Re: IAB: Programs, Initiatives and Responsibilities

I note that the term "user" appears only twice (not as possible
interlocutors or contributors) in the "Internationalization program"
section. There are now more than two months that Jefsey Morfin has appealed
the IAB over the IDNA2008 publication informational context. There is no
answer yet.  However, the IESG has expedited that publication. This makes
the IAB response difficult, unless it was completed before the publication.
Then, why is it not published?

This mail of the IAB Chair is in line with some of the appeal topics. Yet it
seems to:

- introduce the concept a primary alliance between ITU and ISOC. This would
favor ISOC Platinum and Gold Members along with the ISOC disregard of lead
users (Global and Sustaining Members are like ICANN @larges: they have no
Board Members, the same as IETF Users have no publishing stream).

- tell the "interationalizing users": we know better, we have a program to
internationalize you. When IUs specficly do not want internationalization
but need a plain uniformization of the Internet.

I think this is important.

For years, Jefsey Morfin tries to keep IETF Users and Internet lead Users
within the IETF. His rationale is that the IETF is being disconnected from
users and from their needs for the very reasons expressed by the IAB in its
RFC 3869. So, it belongs to the Users to respond the IAB's plea instead of
the  governments misinformed, and to architecturaly contribute where
governments were asked to financially contribute.

I oppose this Jefsey's hope as non-realistic.

Good or bad, the IETF has now been sold to ISOC. And ISOCANN is the enhanced
cooperation for the Internet adminance the WSIS did not want, but the
Industry supports. ITU represents the Governments infrastrural
responsibilities. Jefsey Morfin/Russ Housley's IUCG was a good step ahead as
a direct liaison between a users' SDO and the engineers' IETF. However, that
Users' SDO is still missing.

Why a users' SDO. This is because IUsers do not want to be ISOC copyrighted
via the IETF Trust. They want to be and stay public domainers, as
Governments do. They are copywished. Everyone must freely be able to share
and upgrade a Free Architecture (Architecture Libre in French, making it
named "ALFA", like there are FLOSS softwares. Users do not want to get money
from their technology documents, but from their smarter technology usage.
ALFA is not a business, it is - like the governments which should sponsor it
- a people's common good.

IDNA2008 is now published. IAB has not published any guidance on the way to
read it. The Internet RFC1958/RFC3439/IDNA2008 architecture is now the
Internet IETF architecture. Quite a change from RFC 3935, except the
previous AD and a few of us, who knows it?

So, what do we do?
- do we do like Jefsey, claiming in deserto that we need to wait for the IAB
response to his appeal, so we have done the maximum not to split the "legacy
internet" from the "on-going internets".
- do we publish JEDI's (Jefsey's disciples as per Martin Dürst) inherited
concepts as a public domain book and public domain softwares, (Jefsey cannot
object since he claims his propositions are public domain!) never mind the
impact?

The decision is (y)ours.

Stephane Lancel.

PS. Since Jefsey Morfin is impeached to contribute on this list, I will copy
his response. I suspect he and some others will be upset. But I think there
are occasions where caution, vacations, egos and politics should be forgot.

2010/7/28 IAB Chair <iab-chair@iab.org>

>
> 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@iab.org
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>