Re: [Pesci-discuss] [Fwd: I-DACTION:draft-davies-pesci-initial-considerations-01.txt]

At 13:54 20/01/2006, Spencer Dawkins wrote:

>From: "Brian E Carpenter" <brc@zurich.ibm.com>
>>
>>My thought is that the spaghetti-like nature of the current documents is
>>actually a problem, especially for newcomers. But it's separate from
>>the core problem. It's why I wrote draft-carpenter-procdoc-roadmap and why
>>I intend to maintain that draft.
>
>Just to chime in here, since both the IETF home page and the RFC 
>Editor page point directly to RFC 2026 with no qualifiers as "the 
>Standards Process", it is possible that we are confusing more than 
>newcomers :-(
>
>Just for fun, follow the "updates/obsoletes" chain for 2026, and see 
>how clear our document structure really is to anyone who doesn't do 
>IETF for a living.

Correct!
May be this input can give some ideas? May be a (manual) work on RFC 
2026 along these lines could be of interest? .

I first semi-clarified the IETF IPR issue with Brian. Then we started 
trying to build a DNS compendium in a way we could "automate" for 
other topics (and multilingualise  [not internationalise] meaning 
that we could both translate RFC inputs but also add non-English 
inputs, for example ccTLD rules, terms and conditions, tables, 
charsets, etc. treating every language on an equal basis, what 
creates additional problems).

We went on the RFC -Editor and searched fro "DNS". We took the list 
of RFCs (obsolete as well) and made a list. Then we took all their 
ASCII text and tried to work out some automated structuring from the 
TOC. Then we built a registry, indexing all the paragraphs with the 
number of the RFC, if it is obsolete or not, reserving a ThematicID. 
Then we started trying to build the Registry meta-model (the works 
goes in parallel with the development of a registry manager - this 
DNSreg is one of the test application).

The main problem we observe right now is the obvious lack of 
cross-rfc meta-model to describe the covered topics. There are 
Introduction, TOC, security and IANA considerations, links. This is a 
beginning. We should totally rebuild the titles of the parts to get 
some consistency. Our first analysis shows that we should probably 
rewrite many "blocks" to keep them consistent and address repeats. We 
need a "confusion waiver" system of rules. Then there is the update 
problem when information is not renewed in the new version. We had an 
English variation n-gram run which shows there is no really 
consistent style (far less than in ISO or ETSI documents). We were 
told this may indicate less precise documentation.

Obviously we could have chosen a simpler case than the DNS, but we 
need to have a good command of the whole experience for our work 
taowards a DRS  (distributed registries system) moke-up. This was 
also the topic where we could have the largest number of relevant 
entries in the largest number of languages, and therefore ways to 
test the LNS DRS core (language naming system).

We would like to see how we can get applications from this. A DNS 
ontology? One of the target is to investigate a digital ecosystem 
multitechnology documentation registry. The target is also to include 
the DNS registries in the system. We would structure for that the top 
zone information we maintain (http://afrac.org/intlfile.txt) on a 
daily basis. Using our own formating generator for parallel multiple 
language structures. From then on, ISO 11179 compatibility, using ISO 
639-6 language codes for example, and some geographic registries [or 
telephone numbering plans] could permit local roots and PADs [private 
alias directories] easier management, and ML.ML naming support. We 
would like to see if we can get a root matrix from all this (all the 
top zone ML.ML and ML.LOCAL variations - and transtechnology 
services). The standard name resolution would be carried via DNS 
servers or access engines. The whole thing would permit, for our 
Naming Registry Manager generic system, to propose an online support 
complete documentation.

Associated thematic grids could permit to produce easily specialised 
abstracts or aggregats. In the way Doug Engelbart's Augment system 
did. This could be used for trouble shooting; all the documentation 
would progressively follow the investigation.

I hope we will compile experience during this quarter, adding the 
first propositions for the IGF, and get something online in May/June. 
It would be embryonic but a moke-up for comments (that is if 
competition does not push me out the IETF before or pump too much on 
my time/budget).

jfc

_______________________________________________
Pesci-discuss mailing list
Pesci-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/pesci-discuss