IUCG/UR

From IUCG - Internet Users Contributing Group

The discussion for such an I_D is to be conducted on the iucg@ietf.org list.

Target date for a first text: december 15th.

2011/11/05 JFC to Michelle Cotton

At 01:33 05/11/2011, Michelle Cotton wrote: I think some of the conversation got derailed (at least I thought it did - not sure others agree). I was just trying to get back to specific things to be fixed, label them simple/more complex....I need to go back to my developer with a list of things to change/fix. Figure out what changes can be made without any RFC revisions/etc.

Michelle,

There actually are two classes of people to make happy:

• the IETF information registrants - on this IETF list they should have the priority.
• the IANA users who may include non-IETF registrants since the IANA charter is not limited to IETF registries.

I am not competent to discuss the first class.
I am definitly pionneering the second one with the IUCG as the "Internet, IETF, IANA users contributing group": people targeted by RFC 6417. To fully understand what our/their needs are, along with the Internet common way, we have to discuss, experiment and propose.

To that end I started keeping updated a IANA WinHTTrack copy with the files linked on external sites.

This currently represents :

• 23,143 files (of which 4962 have an IANA URL).
• 3,793,589,988 bytes (of which 28,370,696 comes from the IANA server).

(I can send you a copy of my findings as a table or a csv file, for comparison).

Attracting researchers and lead users to the IETF (RFC 6147) calls for matching their culture. They will want accessible, reliable registries they and their applications can directly interact with and use for additional registries (statistics, tests, etc.). They will therefore demand a stable and enforced documentation on the IANA file directories, logic, content, file format, etc..

The main contention I had during the RFC 4646 saga was the size of the langtag tables and the lack of end-user update system; except a complete download of the table. This would quickly double the whole internet traffic in just accessing the IANA if every user requested a daily update (full table download) to be sure his/her smartphone is linguistically up to date.

This is why I think the best solution would be :

• to conceive an independent intermediate documented stable IANA structure
• to publish a formated daily reports, applications might use to request urgent updates
• for everyone to be able to maintain his/her own tables
• the inner IANA system freely evoluate only having a fixed information structure.

At this stage I am interested in (on an experimental basis):

• understanding which directories (IANA directories and external sites) the IANA really represents.
• experimenting their stability and interfacing their format.
• building a single base that can be zipped (probably as an SQLite file) on AKAMAI, with a reader and an updater for futher local copies distribution.
• exploring the best/cheapest way to keep its information updated at million sites.
• adding global, specialized and private use registries.
• documenting the whole set.

I whish to know:

• if this is acceptable to your strategy.
• your comments.
• how your team could help.

jfc

20111107 JMBdeP

Jefsey,

I looked at the initial table you produced.

the work ahead seems to be consequent. Moreover if there is no warranty of a stable format from the IANA. Did you consider your "intermediary formated structure" as an test MDRS structure?

Anyway what we would all need is an "insider" technical description of the IANA architecture, and a searchable file content database. This would also document the IANA team's experience. Does such a document exist? From your table, most of the IANA files are HTML only one PDF, so I guess not. There is nothing looking as a IANA developper manual or even a printed/maintaiend user information.

Or should we try to document each of the 4962 "iana files" in the table? In such a case we should probably:

• produce a .csv format
• develop a program to extract this table and consider its evolution easily. I can have a look at an rdlab development.

Best would be a cooperation with the IANA team.

20111108 - JFC - Response to JMBdeP

Jean-Michel,

This is the crux for us, and for the Internet.

At 01:39 07/11/2011, jean-michel bernier de portzamparc wrote:

Jefsey,

I looked at the initial table you produced.

the work ahead seems to be consequent. Moreover if there is no warranty of a stable format from the IANA.

...snip...

• develop a program to extract this table and consider its evolution easily. I can have a look at an rdlab development.

The general issue, as I perceive it from the different inputs on the happiana mailing list, results from Peter Saint-Andre's impossible targeted task. I'll quote him here:

We're not here with a clean slate to rewrite RFC 5226 or core IANA procedures. Instead, we're here to improve the interface to the

...snip...

tend to help process standards tree registrations for web technologies, but there might be other SDOs in the mix).

This is to say: I want a very nice, wide car, doing what I want on the road, security for my family, impress my neighborhood, be able to transport all of my friends, etc. but all I have is a bunch of bikes and I do not have the money for any other vehicle. I want to focus on being happy, and not on the work that is to make it happen.

So, as a result:

As I wrote yesterday to the ietf@ietf.org list, as part of our work here we might collaborate on

...snip...

from, say, the W3C could see their request as it moves through the process without needing to pester the relevant Area Director.

This means that one can only (too complicated otherwise) plaster patches on the bikes and tell people how to use them as if they were a big, nice car.'

I'm out of time for now but just wanted to make sure that we have a broadly similar set of expecations about what we're trying to accomplish here.

What we need is a clear description of the IANA engine for all the seasons, the way it works and the way that it is to be used, and the IANA specifications that are to be approved by the IESG as the exact program for that IANA engine to run along the RFC, i.e. its user manual.

This really means a clean slate approach. Either this is engaged by the IETF for the Internet, written by the IANA team and documented for its clients (including the IETF), or it is designed elsewhere. This problem is a recurrent problem that I have faced for 35 years: to jointly document the network to peers, so that they can themselves document it to their users. From this I identified the need for a distributed system permitting everyone to document everything to the attention of everyone who needs it and of his/her machines. I called that system MDRS, which stands for Meta-Data Registry/Multilingual Distributed Referential System. This turned out to be the Intersem Internet-IANA architectural equivalent (and probable extension/continuation).

Until now, I have only tried to avoid complicating the resolution of this complex issue, in particular in the multiglobal area (multilingual, multitechnology, international, national strategies, cultures, transdisciplinary exploration, etc.). I hoped Peter's effort can be a basis for a step ahead. I am afraid, from reading the happianna mailing list that the only solution is for the IUsers (Interdigital ecosystem users) emerging community to do this for themselves, based on the existing IANA, ISO, Linguasphere, etc. material, our passed Intlnet and JTC1, IETF DDDS/DNS deployment experience, and Intersem under the exploration requirements.

Now, the issue we also have to match, towards good and robust MDRS specifications, is simplifying complexity. This means understanding in a practical manner what complexity and simplicity are and how to computer assist them in the best way, which means to equally master meta-complexity and meta-simplicity. This may seem somewhat esoteric at this stage, but it is necessary when considering the seed of the system to actually structure the semantic layer of communications.

Understand that for the sole Internet (passive content strata) there are 96 different IANA related RFCs, if you add ISO 3166 and 639 etc., ISO 11179 series, Linguasphere open source elements, it becomes which is, actually, way too much.

Best would be a cooperation with the IANA team.

Up to them to decide.