Subject: Re: [iucg] [Ianaplan] Trial balloon: suggested text

From: JFC Morfin <[email-masked]>
Date: Wed, 19 Nov 2014 09:46:45 +0100

At 05:16 19/11/2014, Miles Fidelman wrote:
>>That seems much preferable to committing today to negotiate
>>prices with a monopolist. *That* would be irresponsible.
>
>I've periodically wondered about this.  IEEE does an awfully good 
>job at managing the various registries for the standards they maintain.
>(Names and addresses are, of course, different beasts - by the 
>nature of the volume of data and transactions involved.)

Miles, Milton,

The IETF is to be consistant. What is discussed is a whole - let call 
it I*Doc - including names, numbers, documentation and parameters. 
Parameters are public domain. Documentation is not (subject to BCP 
78). I do not know about names and numbers. They are privately owned 
(except these which belong to parameters) but I suppose their 
knowledge/use is public domain?

Why would IETF pay to get someone to republish something in public 
domain? So the problem is only BCP 78. And in BCP 78 the provision 
regarding derivative works (such as IAB's demanded internetsec), what 
may also aspect special parameters uses.

What is needed is a stable format for public domain I*Doc 
publications that repositories can adapt to their RFC 6852 global 
market because "we embrace a modern paradigm for standards where the 
economics of global markets, fueled by technological advancements, 
drive global deployment of standards regardless of their formal status".

May I remind you that "in this paradigm standards support 
interoperability, foster global competition, are developed through an 
open participatory process, and are voluntarily adopted 
globally.  These voluntary standards serve as building blocks for 
products and services targeted at meeting the needs of the market and 
consumer, thereby driving innovation.  Innovation in turn contributes 
to the creation of new markets and the growth and expansion of 
existing markets."

This is why the few following things to do are:

1. make "http://iana.arpa" resolve.forever.
2. make ".arpa" reserved in every DNS class.
3. put RFCs and parameters in public domain with the impliction that 
the use of names and number is free.
4. support information on internetsec at http://internetsec.arpa
5. accustom users to use ".arpa" in makig http://ietf.arpa, 
http://iesg.arpa, http://irtf.arpa, and http://iab.arpa to also resolve.

Then to seat and wait.
jfc

---

From: JFC Morfin <[email-masked]>
Date: Thu, 20 Nov 2014 20:05:04 +0100

Dear John and Richard,

The Last Call period is over. Now, we are waiting for the Chairs to 
decide on the Rough Consensus that they observed. Therefore, the IESG 
can start an IETF Last Call and can make a decision that I will most 
probably appeal.

Being barred from sharing in the IETF Last Call, I am now at ease to 
organize a Libre involvement in what is to follow. Moreover, 
circumstances have unexpectedly led to an early friendly fork, while 
I feared an unfriendly and later one.

The questions are:
- who will be the final Internet referent to replace the NTIA oversight?
- what will be its accountability framework?

I hereby identify several candidates.

1. The US arrangement is the FCC.
2. The WEF arrangement seems to be ICANN.
3. The ISOC strategy has to adapt to Fadi's/Rosetta-NETmundial 
initiative and hesitates.
4. The de facto one is IAB.
5. The ITU-I is the most obvious one if the I*/WEF, etc. people do not agree.
6. A mess.
7. The emergence of a global Rastafarian "overstanding" based on the 
RFC 6852 paradigm, ITU/USG multistakeholderism, Libre's contribution, 
multitude's polycracy, etc.

The short-term solution is #4.
I analyzed the way the IAB can still easily address the situation now.
However, the IAB selection mode will not be enough unless the secure 
internet project takes off and gives technology leaders a respite. 
However, it is unlikely that the non-secure-internet IETF designer 
will be trusted very much by the world (nothing to with the people, 
but with the Tao).

IMHO, the long-term solution is #7.
The priority is, therefore, a precautionary approach of its emergence 
mechanism. To reach stability, this mechanism must be in tune with 
the political evolution and target the completion of the IEN 48 
internet project objective, i.e. "to allow new networking technology 
to be introduced into the existing catenet while remaining 
functionally compatible with existing systems".

There are currently two architectonical visions that I adhere to:
- my Intersem proposition of an inter-semiotic network for the whole 
digital ecosystem (WDE).
- Russ Housley's IAB requirement because the Intersem can only be 
confidential by default.
The question that needs to be answered now is which architecture is 
the best for both of them in considering the currently installed 
architecture (infrastructure, governance, contracts, and usages) and 
existing established trends.

There is a need for a major improvement for the IANA concept.
I extend the concept to what I call the MDRS (the "multiple 
definitions on record, metadata registry, multilingual distributed 
referent, etc. system): in order to include a single documentation of 
reference, to support multilinguality (i.e. the multilingualism 
cybernetics), to be multitechnology, and most of all to be locally 
distributed and processed at  everyone's machine.

Now, what to do?
If you want to negotiate, the best thing to do is to take the 
initiative and build your own independent solution. My target should, 
therefore, be:

A. on the technical side
-----------------------------

1. to maintain an <http://iana.zone/>http://iana.zone site 
replicating the iana.org site.
2. to progressively enhance that site with the help of the community.
3. to use the IUWG as a non-BCP78 restrained Libre (CC BY SA) working site.
4. to initiate an IU experimental Intelligent Use DNS class for IUI 
(Intelligent Use Interface) interoperations.
5. to foster Libre development/experimentation for my local 
non-profit Digital Services Providers project and Lab in the:
     - confidentiality area
     - MYCANN plug-in
     - intelligent networking
     - presentation layer.
6. to discuss and experiment a polycratic governance

B. on the political side
----------------------------

1. to appeal the final IETF position if it does not match our 
requirements that I stipulated.
2. to develop the FSP4NET (fail safe project for the net) as an 
operational Libre enhanced coalition (Govs, Industry, CS)

This already creates a few things that need to be done.

Best
jfc

At 11:08 19/11/2014, John C Klensin wrote:
>--On Wednesday, November 19, 2014 09:56 +0100 Richard Hill
><[email-masked]> wrote:
>
> >> 2) In case of future need to transition the operation of the
> >> protocol parameters registries from ICANN to subsequent
> >> operator(s), this transition will be smooth and have minimum
> >> disruption in the use the protocol parameters registries or
> >> other resources currently located at iana.org. This
> >> arrangement should be comparable to current obligations
> >> established under C.7.3 and I.61 of the current IANA
> >> functions contract between ICANN and the NTIA [NTIA-Contract].
> >
> > I think that we need to add at the end: " and it must allow
> > the new IANA functions operator to use the IANA trademark and
> > the IANA.ORG domain name."
>
>Richard,
>
>I'm glad you said "allow" because anything stronger would make
>my somewhat-negative reaction below much more intense.
>However...
>
>That result, independent of text, would be my preference too if
>the circumstances were right.  However, I think there are just
>too many possible scenarios, include splitting up the IANA
>function(s), that would make the text you propose more a source
>of difficulties and disruptive attempts at hair-splitting (or,
>in a different metaphor, baby-dividing) than a help.
>
>"will be smooth and have minimum disruption in the use [of] the
>protocol parameters" seems to me to require availability and use
>of the IANA trademark and IANA.ORG for all of the simple cases
>because not having them available and using them so would be
>much more disruptive.  If that is correct, the added text is
>potentially useful for some edge cases and, at least IMO, it is
>at least as likely to be problematic for other possible cases as
>to be a benefit.
>
>Stated differently, if any major transition in the IANA
>functions operator or how those functions are organized is
>needed, those who have to deal with it will have to sort out an
>array of tradeoffs in which they try to minimize both short-term
>disruptions (including service disruptions) while maximizing
>long-term stability including references from specifications and
>other documents that will not change.   Those two objectives
>conflict, so there are no obvious answers.  I actually predict
>some decisions would likely have to be made on a per-registry
>basis rather than "for the IANA Function(s)".   Because we
>cannot predict all of the scenarios, putting in text that could
>later constrain or complicate choices seems unwise unless there
>is a compelling reason to do so... and I haven't heard or seen
>that reason, especially in the light of comments that several of
>us have made about how small a portion of the transition
>problems things like the IANA name or the domain actually are
>likely to be.
>
>best,
>     john
>
>
>
>
>
>_______________________________________________
>Ianaplan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ianaplan