Re: SIMILE PI Call, 27-July-2003, 1200 EST / 1700 BST

john erickson wrote:
 

>> Kevin Smathers wrote:
>
>> I don't buy this argument.  The top level DNS domains are essentially 
>> categories, they are analogous to HS preallocating block number 
>> ranges for certain classes of naming authorities (e.g. Simile).  That 
>> DNS defines certain well known categories, while HS does not only 
>> leads to a minor feature distinction; it doesn't fundamenally alter 
>> the scalability of either system.  Properly characterized, the HS 
>> self administered naming layer should be mapped to the DNS self 
>> administered naming layer.
>
>
> JSE: To some extent, this is what DOI accomplishes: 10.* is granted to 
> IDF, which administers everything under 10.* according to its 
> policies. The independent entities that IDF assigns this authority to 
> (i.e. namespace management under "10.1234/") are called Registration 
> Agencies, and operate across institutional boundaries. The most active 
> example is CrossRef, but there are several other major ones, with 
> acronyms like CAL, TSO, LON, and MEDRA, as well as CrossRef and 
> Content Directions.
>
> BTW, I wouldn't characterize the current DNS top-level segmentation 
> into "well-known domains" as "correct", simply arbitrary. It is not 
> clear to me how this segmentation is useful... 

The DNS top level segmentation eliminates some name competition between 
educational (.edu, .k12), commercial and other non-governmental 
organizations (.com, .net, .org), and governmental organizations (.gov, 
.mil), and between different countries (.us, .uk, .de, etc.) among other 
things.  I'm not sure where you got the 'correctness' from, but the top 
level domain is a pretty good indicator of who the sponsoring 
organization is for a particular service.

>
>
> John and Kevin continue:
>
>>> 2. NA-level self-administration has implications like, the remainder 
>>> of the DNS formalisms (second-level domain, sub-domain, etc) are 
>>
> >> unnecessary --- or, more precisely, these formalisms are
> >> defined by the governance of the particular NA and
> >> are not dictated by HS itself. The equivalent of this in DNS
>
>>> would be if .edu, .com, .mil, etc. could set their own rules for 
>>> entitlement.
>>>
>> No, it is as if in DNS the second level domains e.g hp.com, 
>> yahoo.com, etc., could set their own rules for entitlement.  As 
>> indeed they can, as can any subdomain that they further delegate 
>> control to.
>
>
> JSE: Only if you follow your earlier point, i.e. "properly 
> characterizing" (or constraining...) the HS naming authority layer to 
> align with the DNS second level...But this is not required within HS!
>
> This *happens* to be how IDF chooses to do business, but it is *not* 
> necessary for any other naming worlds to follow suit. The fact is, 
> administration levels such as what IDF represents are arbitrary. 


I'm not familiar with the IDF acronym, so I'm not sure what you are 
arguing here.  I think we were examining both HS and DNS to see if they 
both had provision for sub-authorities to set their own rules for who 
and how names can be added to that subauthority.  DNS does include this 
feature by using a multi-level hierarchy in which the rules can change 
at any point within the hierarchy, but which in practice uses fixed 
rules at the first level of the hierarchy.  HS does this by allowing the 
rules to change at the top level of the hierarchy thereby removing the 
need for a multi-level hierarchy just to get that flexibility of name 
control.

Since the same effect as the HS first level can be achieved in the DNS 
second level, I argue that these two systems are feature compatible.  As 
far as I can tell, you are arguing that since the DNS first level, by 
the fiat of the root server operators, does not incorporate the 
flexibility of the HS first level, that DNS can't do what HS does.  Even 
if the DNS top level were both arbitrary and random (which I don't think 
it is, but I think you are arguing), I still don't see why you should 
say that makes DNS feature incompatible with HS.  When comparing 
features of two dissimilar systems it generally works better to compare 
the layers that map to the same function rather than layers that have 
entirely different functions.

>
>
> Finally, Kevin sez:
>
>> Since DOI depends on HS, if we need to incorporate DOI then we should 
>> probably incorporate HS as well.  In the absence of DOI, I don't 
>> think that HS adds anything of technological significance to the 
>> system that can't be done equally well with DNS.  Technological 
>> issues aside, HS may change thought patterns somewhat, or it may 
>> represent a newer and therefor cleaner namespace....
>
>
> Regarding what can and can't be done (with the HS), the core think of 
> value that it does is provide a secure way to intrinsically associate 
> an aggregation of typed metadata with a globally unambiguous name. 
> This association is then administered securely through a single 
> protocol, from anywhere. And, if desired, each assertion of the record 
> can be authenticated as an intrinsic part of how the system works.
>
> I don't know how, in the current-generation internet naming, to 
> accomplish this sort of name/metadata binding "equally well." Yes, of 
> course mechanisms can be built to accomplish the same thing. It is the 
> intrinsic part that can't be done.

The name/type/metadata binding in DNS is built in to the system.  
Intrinsic security is built into the protocol stack that DNS sits on top 
of, and resides in the physical security and trust of the Internet core 
routers (or of the virtual core routers in the case of a VPN.) 

Administration of DNS is of course not intrinsic, but since DNS uses a 
multi-level hierarchy, it is easy to establish a particular 
administration method and guarantee that it will be available throughout 
a subtree.  Core DNS doesn't add anything here, but neither does it make 
it impossible to implement.

Cheers,
-kls


-- 
========================================================
   Kevin Smathers                kevin.smathers@hp.com    
   Hewlett-Packard               kevin@ank.com            
   Palo Alto Research Lab                                 
   1501 Page Mill Rd.            650-857-4477 work        
   M/S 1135                      650-852-8186 fax         
   Palo Alto, CA 94304           510-247-1031 home        
========================================================
use "Standard::Disclaimer";
carp("This message was printed on 100% recycled bits.");

Received on Monday, 30 June 2003 16:50:10 UTC