[IDONS] MechanismSoftware :: pdf :: context view

inbound links:
Related, Not Here

Related, Not Here

  1. Public Opinion and Politics
  2. Registration Policy; dealing with community wide, durable conflicts.
  3. Resolution Policy; dealing with local, momentary conflicts.
  4. References

Abstraction Level

(needs a better heading)

The software layer MUST? be defined in terms of wire protocols and data formats. If possible using established standards. It MUST NOT be defined by implementation. (Though a reference implementation would not harm ;-)

KISS?!

The System will need to provide a programming language to write executable registration policies (executable contracts) in. A community/federation/quorum/group of cooperating root servers MUST ONLY update their local version of the common view of the domain registry, when that "script" agrees. See subscription, reputation, support. No such policy MUST be part of the kernel system as designed here.

Ideas:

Avoid fixation to:

Client Side

The Cache/clients that query the P2P? side and then provide lookups to users not using the P2P? client. From the user perspective it is just another DNS Server

The hard part. Detailed in client software.

Server Side (Peer)

The P2P server side that manages domain registrations.

The easy part, see peer software for existing solutions/systems and proposals.

Peer To Peer Channel

Everything about "how to get a message from machine A to B". p2p channel be it crypto, stegano, collaboration, store+forward, pull...

General Considerations

General Considerations

what is DRM:

  1. ARM (Actual Restriction Management) - "physical", applied by local administrative power
  2. LAW (Logical Attribution of Warrants) - "virtual", applies to "global" listings

    ARM breaks LAW. That's a fact to live with.

Open problems


Last modification: Wed, 15 Dec 2010 18:30:51 +0100

Author(s): jfw,

Document number A5afeb39445695358a1d5cf9425159a3a (version 434) delivered to public at Tue, 12 Dec 2017 11:31:36 +0100

short comments

add comment