[IETF-IDRM] Re: [IDRM] DRM Taxonomy work -- drm framework... -- handle system

[Sam X. Sun (@S2000)]

Michael,

I'll address those issues that I think are related to this thread and
discuss the others with you offline... My comments are below...

----- Original Message -----
From: "Michael Mealling" <michael@neonym.net>

(skip...)
> > In terms of Handle System and URN, I would say that they are quite
different
> > now in terms of how they work and the issues that they want to address.
>
> Sure. From what Larry was talking about, the system is much more concerned
> about the rights metadata than the identifier resolution process...
>

Not totally right. Metadata is only one application of it. The handle system
is just a general purpose global name service. The handle system protocol
supports both handle resolution and administration.


> > distributed name administration,
>
> What's being adminstered? Is that for provisioning of the identifier or
managing
> the metadata associated with the object being identified? The first is
> interesting (and actually what the PROVREG group is doing.) The second
> is a metadata service feature....

It's totally different from what PROVREG group is doing. It's about managing
handle and the handle data, not necessarily the metadata.

>
> > internationalization
> > (i18n), and service scalability. It might be helpful if you can read the
> > latest HS drafts to understand the difference...
>
> I'll go check 'em out. Has it changed that radically?
>

Yes, it's a total redesign from the earlier version. The objective, the data
model, and the protocol are all different.

> > On the other hand, I see no
> > reason why Handle System cannot work with URN. One way to do it is to
> > register HS namespace as a namespace under URN, as we discussed earlier
last
> > year.
>
> That should be fairly painless. I'll send you the template....
>

Thanks. I will study that after I get it.

> > The issues that we need to address are how to make sure that the NAPTR
> > approach won't become a bottleneck,
>
> It really can't. You only do one lookp and the record has a time to live
of
> several _years_. From my analysis you end up doing the _exact_ same number
of
> lookups for NAPTR records in the  degenerative case (which handles would
be)
> as you do for A records....
>
> > and how to achieve service security over such approach.
>
> The same way you are now. URI resolution just gets you to the
authoritative
> server for that identifier. How secure it is after that point is up to you
and
> the types of protocols/services you require to do the task.
>
> > Maybe we should discuss these in a separate thread, or bring
> > them to the URN working group...
>
> I think that would be best. We don't want to bug these guys with
identifier
> stuff to much. ;-)
>

I will leave this for our offline discussion...

(skip....)

>
> > In fact, because DNS is
> > not secure as we know of today, that makes any name service based on DNS
> > questionable in their security.
>
> Not true. While some aspects of DNSSEC are still being worked on. It is
> very possible to have trusted DNS in normal operation.

I won't agree with you. First of all, I remember from your colleague (Mark?)
saying that the specification from DNSSEC is not compatible with current
operation. Secondly, its deployment to individual boxes is still a long
shot, especially for those existing boxes. I don't think it's appropriate to
develop a system depending on something that will be in normal operation in
some unknown future.

>
> > The Handle System is designed to be
> > independent of DNS, and to address the security and i18n issues that DNS
is
> > struggling to overcome.
>
> And the URI resolution mechanism I mentioned solve those problems as well.
> (Besides, i18n issues aren't really identifier related issues anyway.)
>

My understanding is that the DDDS (or URN/RDS) service is based on DNS. I'm
not sure how you solve the security problem without DNSSEC in place. Could
you elaborate?

Regarding i18n, I don't agree it has nothing to do with identifier.
Otherwise there wouldn't be a bof in URI i18n earlier. The problem is that
we can't find a satisfying solution. When you build an end-to-end system
like handle system, i18n must be addressed. Otherwise, we are heading to the
same troubles that IDNS (International Domain Name) working group are
dealing with...

> > It has the advantage that it's starting from
> > scratch, and doesn't have to deal with the backward compatibility issues
> > that DNS has to take care of... On the other hand, we are in the process
of
> > defining handle system URI syntax for handles to be used in web context.
In
> > that sense, Handle system defines a namespace under URI, and we are in
> > agreement there.
>
> Not really. My suggestion is that any DRM shouldn't need to make
requirements
> about the identifier itself. Any URI should be able to be used to find out
> about and get rights enabled access to any object. Digital Rights
> Management has about zero to do with the identifier used to talk about
> the object....
>

Mark has addressed this, and I won't repeat here.


> > In fact, I'm more inclined to think that Handle System is in par with
DNS.
>
> I'm more inclined to think of the RESCAP Working Group actually.
>

Besides that they prefer to start with a brand new approach with separate
protocols for resolution and administration, and decide to base their
protocols on DNS, there are many similarities to what RESCAP people want to
address and what handle system has already addressed. There used to be some
requirement drafts from that working group, but none of them are listed in
their website. Do you have the latest on that? Maybe you can tell them more
about the handle system...

> > In fact, if DNS can address security, i18n, access control on name
> > attributes, and to allow individuals to manage the names they
registered, we
> > probably won't need the Handle System.
>
> With the exception of that last item, this is _exactly_ what RESCAP was
> chartered to do. That last item, in my opinion, is not a requirement of
> digital rights management. Why do I have to use an identifier that is
> registered with some third party? Most folks would like to be able to
> manage the digital rights of http://www.joe-blow.com/music/my-music.midi
> without having to create yet another identifier for it....
>

You don't have to create another identifier if you decides to make the name
coincide with the location of the digital object.


> > On the other hand, people from DNS
> > working group has refused to apply DNS as a general name service other
than
> > network-address translation, which makes us think that an independent
name
> > service would be helpful...
>
> Sure. Everyone should consider the DNS to be at the end of its
usefullness.
> It was never intended to be any of the things you listed there.
> Where did the DNS come into this anyway? I don't think anyone has made
> the suggestion that currently deployed DNS infrastructure can handle
> any of this. This is why the URN working group did what it did. This
> is why the IESG is creating uri.arpa as an infrastructure level Internet
> technology for reliable, secure URI services such as caching/replication,
> metadata, access control, policy, etc...
>
> There has been _considerable_ work done in the IETF in this particular
area.
> I'm just suggesting that this group use that work and not chuck all of it
> in favor of one very verticle solution. Make the system modular and make
> it use the identifier infrastructure that the IETF and the W3C are
> standardizing on...

Same here...


>
> -MM
>
> --
> --------------------------------------------------------------------------
------
> Michael Mealling |      Vote Libertarian!       | urn:pin:1
> michael@neonym.net      |                              |
http://www.neonym.net
>                         |                              | go:Michael
Mealling