Competition ? Re: [governance] is icann ...

[Dr. Francis MUGUET]

Dear Avri
>
> On 21 Sep 2009, at 13:14, Dr. Francis MUGUET wrote:
>
>> except for some fields like the CNAME that you mentioned at the 
>> workshop,
>
> this is not just any old field but an essential feature, a resource 
> record type that, until and unless it is changed makes the entire 
> project unworkable as the namespaces will leak into each other.  
You are dramatizing a little bit with visions of floods...

,without indication of class, the default is the class IN. 
<http://en.wikipedia.org/wiki/CNAME_record>
and
although the  /CNAME/ record <http://en.wikipedia.org/wiki/CNAME_record> 
can be a convenient shortcut,  everything can be done with A records,

So for the class IN,  for legacy reasons,  the CNAME could only be used 
for aliasing
names in the class IN....   no big deal
and in the new /classes, / 
either we modify the syntax for the CNAME
( which is possible, since there no legacy )
or CNAME would be avoided unless aliasing to a domain name in the IN 
class...
so no big deal...
and above all,  no confusion

or, other idea,, may be better,  we adopt the rule
that aliasing can only be done with the same /class./

> Even if  you intend your new Class not to use it, the fact that in can 
> be used 
cf infra
> means that the namespaces can't be isolated from each other - hence 
> putting us back in need of a single global name space.   i.e. right 
> back were we are now.
>
>> almost everything is in the RFCs
>
> not by a long shot.
>
> two things that immediately come to mind are a well formed definition 
> of these Classes and a well formed URI scheme f
exactly, I neved hide this fact in my presentation,  the class field 
must become represented in the URI,  with
an added syntax feature.
> or naming your new services/objects so that apps, apps that would need 
> to be modified, can use the new namespace.
yes of course, to use new things, the apps must be updated, nothing 
wrong with this
>
> and things in the RFC that have not yet been implemented and tried may 
> or may not work.
>
> and how many DNS implementations would need to be updated?
all,  it is like a software update
>
> as for http://www.icann.org/en/meetings/stockholm/unique-root-draft.htm
>
> The problem here is that was just an assumption, but when people 
who ?
> started looking at doing it, they started to find all the reasons why 
> it would be very difficult.
>
be more specific

> my prediction is still that even if you can get the resources and 
> talent to do all the necessary research work and if it is indeed 
> doable, which won't be known until some ways down the road, I still 
> predict a decade is the shortest time before deployment - and possibly 
> 2 decades before it might see wide spread use - if it proves to be 
> feasible at all. I admit this is slightly better then the infinite 
> time prediction I gave you on first hearing the proposal (the last 
> thing I predicted infinite time on was IPv6 and yeah, maybe i was 
> wrong on that.  maybe
your track record on prediction reassures me ;-)
> .)  as i said, i love seeing people find clever uses for unused 
> protocol features, but one must be realistic about the effort involved 
> in making it work and deployment.  i think there is some cleverness in 
> the proposal but the road to deployment is really really difficult and 
> very very long. I
we agree to disagree on this later point...
the deploment is going to depend on the adoption of the DNS software 
update by the majors ISPs,
but since they might not lose OoS on the IN class, I seen no reason why 
they should not perform the update,
unless they resist for political reasons in order to maintain a monopoly...
in the long run, this is going to depend on the request of  their 
customers...
 ( ie why I can't access this site... etc.... )
and if whole communities, spread all over the world
request for the /class/ feature .... it could spread like wildfire...
be the "In" thing ( intended pun )

Best

Francis

>
> a.
>
> ____________________________________________________________
> You received this message as a subscriber on the list:
>     governance at lists.cpsr.org
> To be removed from the list, send any message to:
>     governance-unsubscribe at lists.cpsr.org
>
> For all list information and functions, see:
>     http://lists.cpsr.org/lists/info/governance
>
> .
>


-- 

------------------------------------------------------ 
Francis F. MUGUET Ph.D 

MDPI Foundation Open Access Journals
http://www.mdpi.org   http://www.mdpi.net
muguet at mdpi.org       muguet at mdpi.net

KNIS http://knis.org
Academic Collaboration / University of Geneva
http://syinf.unige.ch/recherche/cooperation

Mobile France       +33 6 71 91 42 10
       Switzerland  +41 78 927 06 97
       Cameroun    +237 96 55 69 62 ( mostly in July )

World Summit On the Information Society (WSIS)
Civil Society Working Groups
Scientific Information :  http://www.wsis-si.org  chair 
Patents & Copyrights   :  http://www.wsis-pct.org co-chair
Financing Mechanismns  :  http://www.wsis-finance.org web
Info. Net. Govermance  :  http://www.wsis-gov.org  web

NET4D : http://www.net4D.org 
UNMSP : http://www.unmsp.org 
WTIS : http://www.wtis.org   REUSSI : http://www.reussi.org
------------------------------------------------------ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igcaucus.org/pipermail/governance/attachments/20090921/bbf46761/attachment.htm>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance