[discuss] IETF 89 - IGOV update.

Fri Mar 7 12:25:53 UTC 2014

http://iucg.org/wiki/IETF_89_London_-_igovupdate

I quote some parts and interspred comments:

>In this discussion:
>
>Steve Crocker summarized:
>
>There is a complex and poorly understood trio of globalization efforts
>underway.
>- One is, globalization of IANA function.
>- Second, globalization of ICANN function.
>- Third, broader discussion of Internet Governance which is broader
>than ICANN and IANA.

Correct. This is a difficulty the /1net mailing list seems to meet.

The matter is broader than ICANN and IANA. Achitecturaly and
architectonically one cannot avoid that neutral transparency to VGN
(Virtual Global Network) technologies and governance is the ultimate
target of the Internetting project. This target is technically within
reach, but is curbed by political stands and economical interests that
oppose the status-quo.

>Patrik Falström noted:
>
>You are not conflicting with the Tunis agenda, which means you are not
>requesting or supporting an initiative to have a full WSIS in 2015. It
>is important that you verify that the principles cannot be used in
>favor of having a new WSIS. [this was confirmed].

This implicitely means that the IAB stands by the WSIS principles and
believes that they are fully compatible with OpenStand, what is questionnable.

>Russ Housley concluded reviewing the Principles Guiding the Evolution
>of the IANA Protocol Parameter Registries
>
>1. The IETF protocol parameters function has been and continues to be
>capably provided by the Internet community.
>
>The strength and stability of the function and its foundation within the
>Internet community are both important given how critical protocol
>parameters are to the proper functioning of IETF protocols.
>
>We think the structures that sustain the protocol parameters function
>needs be strong enough that they can be offered independently by the
>Internet community, without the need for backing from external parties.
>And we believe we largely are there already, although the system can be
>strengthened further, and continuous improvements are being made.
>
> >> review: needs clarification about what we mean by the Internet Community

ditto for: internet and globalization.

>2. The administration of the protocol parameters function by ICANN is
>working well for the Internet and the IETF.
>
>We are pleased with the publication and maintenance of the protocol
>parameter function and the coordination of the evaluation of
>registration requests through the IANA function provided by ICANN.
>
> >>  this isn't a principle at all just a statement of fact, and maybe
>that belongs elsewhere

This is true because the Linguistic tables are not extensively
accessed what might be the case if the Unicode langtags routine were
upgraded to better operationnally support a multilinguistic
environment. The load on the IANA could then becom tremendous due to
the size of the table and the lack of an interrogation/update system.

>3. The IETF protocol parameters function requires openness,
>transparency, and accountability.
>
>Existing documentation of how the function is administered and overseen
>is good [RFC2860,RFC6220], but further articulation and clarity may be
>beneficial. It is important that the whole Internet community can
>understand how the function works, and that the processes for
>registering parameters and holding those who oversee the protocol
>parameter function accountable for following those processes are
>understood by all interested parties. We are committed to making
>improvements here if necessary.
>
> >> remove "but" (but further articulation ...)

This applies to the VGNICS as well. I have committed to IAB Chair that
we will follow the RFC 2860 principles.

>4. Any contemplated changes to the protocol parameters function should
>use the current RFCs and model as the starting point.
>
>The protocol parameters function is working well, and as a result
>wholesale changes to the role of the IETF vis a vis the function are not
>warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good
>model to work from in the event that other parties do want to contemplate
>changes. Put quite simply: evolution, not revolution.
>
> >> "this is a service to IETF, and that the IETF selects the service
>provider, not the other way around"

This is correct in the case of a unique authoritative VGN default. The
MDRS (MetaReferential Distributed System) is to extend the IANA
default to the VGNICs with others inputs related to layer six,
multiple technology, interapplications, VGN governance information and
parameters. Since VGNs form an interplus stratum above the internet,
the basic principle should however be that IETF inputs are to be
strictly respected. The idea is that MAY, SHOULD, MUST apply withing a
stratum, and that inputs from other strata are ARE. So there should
not be any conflict by vertue of the layered model. Difficulties will
be dealt at the IAB liaison level.

However, discrepancies might occur among VGN implementations due to
their different contexts. This case seems to have been considered when
"coordination" is proposed to be explored for an added principle.

>5. The Internet architecture requires and receives capable service by
>Internet registries.
>
>The stability of the Internet depends on capable provision of not just
>IETF protocol parameters, but IP numbers, domain names, and other
>registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols.
>Thus we expect the role of the IETF in standards development, architectural
>guidance, and allocation of certain name/number parameters to continue.
>IP multicast addresses and special-use DNS names are two examples where
>close coordination is needed.  The IETF will continue to coordinate with
>ICANN, the RIRs, and other parties that are mutually invested in the
>continued smooth operation of the Internet registries. We fully
>understand the need to work together.
>
> >> no comment

This extends to the stratum above (fringe to fringe) as to the stratum
below (existing relations with the plug to plus ITU).

>6.  The IETF will continue its direction and stewardship of the protocol
>parameters function as an integral component of the IETF standards
>process and the use of resulting protocols.
>
>RFC 6220 specifies the role and function of the protocol parameters
>registry, which is critical to IETF standards processes and IETF
>protocols.  We see no need to revisit or reconsider our current approach
>with regard to protocol parameters, including the ability to delegate
>operational responsibility for registries to other organizations
>
> >>  "use exactly the language of RFC 6220, and be more clear than just
>the bold text at the top that this is not about names and numbers

This is probably to explore further on experience depending on the
requirements of the interfaced technologies.

> >>> add an additional principle to talk about content of registries

In the MDRS case this is going to depend from acquired exploration and
experience but it is like that many new issues in the
active/specific/etc. content.

> >>> and think about an additional principle to deal with the coordination

It is likely that coordination above (VGNs) will be equivalent in its
structure to coordination below (ITU) if the VGN stratum can be
coordinated through one governance (http://vgnics.net attempt) and one
technical forum (interfaced through IUCG?).

jfc