[iucg] The RFC 6852 paradigm.

[JFC Morfin <[e-mail]>]

Dear all,

It seems that we have reached the crux of the whole problem: the lack of an
ultimate technical referent in RFC 6852 to decide from its reading of
the global communities' market economic consensual requirement(s). The
paradigm is not a paradigm because it is divisive rather than consensual.

We, therefore, meet four positions:

-       There is a paradigm.
-       There is not a paradigm.
-       There was a paradigm.
-       What is the paradigm?

-       I have my reading of the paradigm.
-       Who is reponsible ?
-       What next?


1. There is a paradigm.
      ===============

At 21:40 23-09-2014, Eliot Lear wrote:
We do not single out the IANA registry.  Rather ALL of our decisions
should follow that framework.  See RFC 6852 that the IAB released in
January of 2013, as mentioned in our current draft.


2. There is not a paradigm.
     =================

At 09:11 25/09/2014, S Moonesamy wrote:
I do not think that the reference is appropriamte as the document has
not been subject to IETF review and approval.


3. There was a paradigm.
     ================

At 02:06 25/09/2014, Brian E Carpenter wrote:
Now that's a good question. I'm thinking that if a parameter space
was created by IETF action (or by the IETF's predecessors, since there
are things here that date back before 1986) then logically the IETF should
contract for the *existence* of the whole registry, even if some parts
of the registry are no longer populated under IETF technical direction.
But I don't think the IETF should be held responsible for the *contents*
of those parts of the registry. (IANAL, so I will not attempt to discuss
how this should be expressed in formal language.)

Brian, I certainly agree with this, but what if: the IETF modifies a
registry framework. Or, worse, what if the IETF adapts to a foreign
registry? Then what if the SDO defining this foreign registry modifies
its framework?

The whole issue, IMHO, is that we do not have to adapt the past
("status quo") but rather to adapt to the (1) ***possible*** what is
quite complex, starting with the (2) ***probable*** I am a part of who
is willing to cooperate.


4. What is the paradigm?
     ================

Up to now, I only could appeal against RFC 6852, and it was easy for
IESG and IAB to oppose my appeals forcing me to escalate to ISOC. The
NTIA did it its own way faster than me.

Now, the co-chairs have given me a double opportunity to make the IETF
decide if the RFC 3539 is subject to RFC 6852, and how, or not. In,

1. as suggested by the first co-Chair, appealing to the IESG against
the Charter itself on the ground that, as she reads it, it would be
pro-ante-RFC 6852 status quo oriented.

2. to introduce an IUse (RFC 6852 global) community draft for this WG,
that the second co-chair promised this WG will discuss.


5. Note on my reading of RFC 6852
     ========================

For everything to be clear:

- I approve the pragmatic diagnosis of RFC 6852.
- I am concerned by its lack of definition of a "global community" vs.
   a "local network" as defined by IEN 48.
- I disapprove of its lack of solution, i.e. a conflict resolution strategy.

My pre-IEN 48 position has not changed for 37 years: an aggregate of
relational spaces VGNs by the users for the users. I am pretty
confident that this is the solution that will emerge from all this because:

- I directed it from 1984 to 1986 and I, therefore, saw it work.

- it was - only financially/politically but not architecturally -
"attenuated" along the, now removing itself (cf. OpenStand, Dubai,
Snowden, Montevideo, NTIA, Sao Paulo, Geneva), "Being Unilaterally
Global" "status quo" strategy.

- this removal may be enticed by technology, or the technology is
freed by this removal, I do not know. However, as a small local
digital services provider my need is for an SDN technology mix that I
need to be compatibly designed, documented, and supported. I am
certainly looking for an NDN oriented IANA service architecture and
protocol for my intelligent village's VGN. I hope we can document this
in coming months.

[SDN]: Software Designed Network
[NDN]: Named-Data.Network
[VGN]: Virtual Glocal Network, as in US VGN (I*core governed Internet).


6. The IETF responsibility
     =================

 From a local IUser point of view, the IETF is not the single
technology source in town. It is not even the main one. Most people do
not give a damn about ICANN. However, the whole multitude has been
used to entrust its QA to the US procurement process. This has led to
the confusion of the IUse, unstructured by nature, community and NTIA.

The current process is not to transfer anything from NTIA to ICANN. It
is to transfer from the IUse NTIA responsibility to the IUse
community. The emergence of which has to be far better helped.

All I am trying to do is to clumsily obtain and gather that help, and
to help protect the IUse community from the deepest mistakes I may
spot. A purely precautionary attempt.

The I*core and USG adaptation to the current political, financial, and
technological reality through RFC 6852 and the March 14 announcement
are pragmatic enough to be of use. However, the digital IUse community
still has to find a replacement for the NTIA other than the suggested
US jurisdiction (due to the US localization of the internet de facto
governance bodies).

I only wish that a few American IUsers more would better understand
the real stakes. Their best interest, just as is everyone else's best
interest, must be kept neutral to an autonomous ICANN vote to transfer
anywhere outside of the US and adopt a BoD and staff continent,
nationality, and language democratic numerus clausus.

Mr. Lawrence E. Strickling is trying to best protect the US digital
interests in transferring the IANA/DNS oversight from the US Executive
Branch to the US Legislative branch. This is not adequate, however,
because no national bias will be able to architecturally resist his
unleashing of the IUse multitude.

We all know it very well from the NAT experience. Therefore, it is up
to us to help the multitude to adequately organize the criticality
that he has triggered.

Otherwise, Mr. Lawrence E. Strickling will be the one who killed the
TCP/IP internet. Perhaps this is a carefully planned disruptive
innovation move. Maybe it isn't. However, this will be this WG's decision.


7. Follow-up
     =======

Anyway, my recent mails have built-up the content of an appeal to the
IESG/IAB guidance and, maybe, to a community decision, IRT.

- the consistency of the RFC 6852 paradigm with the IETF RFC 3935
   mission statement,
- its practical and precautionary articulation, on a multistakeholder
   basis involving all the global communities, including the post-NTIA
   IUse community.
- the ultimate technological referent,
- the common technological and operational use documentation of
   reference for network engineers, software designers, and lawmakers.

There is no mystery. The World Digital Ecosystem has a need. NTIA
states that such a need cannot be addressed by Governments alone. If
engineers cannot address it alone either, it becomes a common citizen
cause to be addressed by our multitude and the necessary steps must be
discussed, concerted, and engaged.

jfc