RE: "so-called" keyword and layer 3

[Nicolas Popp <[e-mail]>]

>I see multiple competing services with standardization of
>protocol and the facet structure.  I believe that the facet
>structure needs to be standardized or we will reinvent the
>history of (failed and non-interoperable) Internet "white pages"
>services. 

Based on this last comments and what I have read in the drafts (yours,
SLS...), would anyone disagree with the following:

1.	This effort will standardize the structure of the layer 2 data, by
agreeing on a common set of facets (e.g. common-name, country, language,
etc), possibly modeled as CNRP properties with controlled vocabulary for the
values, possibly modeled as standardized CNRP property types.

2.	We can address the names scalability issue by making sure that the
layer 2 schema includes high granularity facets that will reduce name
collisions even with rules of uniqueness on layer 2 tuples. The two proposed
facets that seem to fit the requirement so far would be: "geographic
allocation" and "category" (for both facets, we can define multiple value
types ranging from low granularity (e.g. geographical location as a country
code) to high granularity (e.g. geographical location as log, lat,
elevation) . 

3.	The architecture will support multiple independent (competing) layer
2 services. This multiplicity would take care of the ICANN / WIPO issue.
Furthermore, the so-called keyword systems (AOL, Netpia, RealNames and
al...) instances could individually decide whether they want to provide
services at layer 2 or layer 3 (or both). 

4.	As suggested in John's draft, ALL layer 2 service will have to
return tuples that contain all the standardized facets. However, specific
layer two services that don't care about one or many standardized facet(s),
would still be allowed to return result tuples with blank or "missing"
values for the facets that they want to disregard. For example, although
RealNames would let registrants specify their category value at registration
time (to be used in the context of discovery as a layer 3 service), as a
layer 2 service, it would "blank" the category facet value of its results in
order to enable "direct navigation" (as described by Mr Ko)

-Nico 

-----Original Message-----
From: John C Klensin [mailto:[e-mail]]
Sent: Wednesday, December 05, 2001 10:06 AM
To: Nicolas Popp
Cc: [e-mail]
Subject: RE: "so-called" keyword and layer 3


--On Wednesday, 05 December, 2001 09:31 -0800 Nicolas Popp
<[e-mail]> wrote:

> Thanks for the clarification. I finally undertsand what a
> "keyword system" means to you now.

Whew.  It at least helps to understand whether we are having an
argument, or just a misunderstanding about terminology.

>> (i) I'm worried about scaling with them, and especially about
>> creating yet another situation in which someone has to decide
>> who is entitled ("has rights to", "has the best claim on",
>> "most closely matches") some word or string.   In a way, that
>> is another kind of economic constraint, but, if we can meet
>> the technical and end-user requirements without having to
>> implicitly write ICANN, WIPO, or the equivalent into the
>> protocol, I think that is desirable.   I believe that the "no
>> overseer" requirement is more easily satisfied with keywords
>> at sublayer three than at two.
> 
> I see two different things in your comment:
> 1. scaling concern
> 2. regulation 

Yes, but my hypothesis is that the first causes the second.

> Could you clarify what you mean by "scaling concerns" (1)? I
> think you mean name collisions but I am not sure I understand
> considering that the uniqueness context (country, language,
> service type) is already fairly large to accomodate name
> collisions. 

As the population of entities to be registered (or otherwise
incorporated in the system) rises, the potential for collision
--or funny kludges to avoid collision-- rises with it.  That
follows more or less from the mathematics of the situation and
manifests itself as, e.g., the claim that "all the good [DNS]
names are taken".   That is a fairly classic scaling problem, I
think.

Now, if you say "the uniqueness context... is fairly large", my
reaction is "that is good, it shifts the intercept on the
scaling curve".  It is not clear that is changes the shape of
the curve, and, one way or the other, if growth continues, there
will sooner or later be a collision.  And, sooner or later,
there will either be a lot of collisions or some very important
ones.  And those will require resolution.  We've tried "first
come, first served" as a resolution process, and it doesn't
work.  That leaves either imperial rulings from kings
(monopolies are just a special case of this) or regulation.

Note that "we've made the space big enough to never have
problems" has regularly turned out to be a problem around the
Internet.  Anyone who doesn't believe it should contemplate
whichever of the following statements he or she finds appealing:

	"we will never have more than 250 hosts on the network"
	
	"we will never need an address space larger than 2**31
	minus a few"
	
	"there is no way to run out of space, or 'good names',
	in the DNS, after all, it is an arbitrarily-deep
	hierarchy"

> As far as (2), do you envision like in Michael and Leslie's
> proposal multiple layer 2 services (registries and lookup
> systems) or do you envision a unique layer 2 data set with
> multiple registrars? In other words, do you see layer 2
> standardizing the data structure / schema or do you also see it
> standardizing the data set? It seems to me that if you have
> multiple competing services at layer 2, then overseers (like
> ICANN or WIPO) are not necessary and each service can decide
> what rules/policies it wants to use to decide who is entitled
> to what name & facets.

I see multiple competing services with standardization of
protocol and the facet structure.  I believe that the facet
structure needs to be standardized or we will reinvent the
history of (failed and non-interoperable) Internet "white pages"
services. It could be that this can't be made to work, and I
think that subject would be a good one to start discussing on 
Monday.

    john