[IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt

[Mark Baugher]

Thanks for the clarification, Larry.  I have another question.

At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote:
>I'll let Sam answer the hard questions, but I believe your second point 
>goes fairly directly to the 'semantically meaningful naming authority 
>issue.' If the naming authority moving from X to Y is 10.3692 then the 
>revealed information is a little obscure. If you have a good memory or 
>access to administrative logs you may be able to tell that the 
>handle10.3692/abc used to be owned and administered by X but has now moved 
>to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the 
>situation is a little more confusing. This has been the subject of a good 
>deal of discussion over the years and I strongly encourage non-semantic 
>naming authorities. The commercial publishing world, as an example, 
>instinctively understands and supports this approach (cf.
>ISBNs) and in the DOI world we have already had at least one instance of a 
>block of handles moving from one owner to another with no apparent 
>problems (American Chemical Society selling a journal to Wiley). So there 
>are two potential problems with the transfer of ownership of Handles or 
>Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of 
>handles under one NA across two or more owners who want to administer 
>their handles on different local handle services - this is possible 
>because the granularity of ownership is at the individual handle level and 
>a potential problem because clients are directed to local services by the 
>global root based on NA. This situation hasn't arisen (all DOIs, e.g., are 
>in a single local service) but could be forbidden by local service policy 
>(the DOI choice) or by providing clients with non-deterministic answers. 
>This potential problem was a direct trade-off for 1) allowing local 
>services and 2) putting ownership granularity at the handle level. So far 
>it seems like the right choice.

A big question for me is what happens when John Wiley, let's say they are 
naming authority "167," transfers ownership of a work to Springer-Verlag 
who are "203."  Since the work is prefixed with 167 forever, doesn't that 
mean that John Wiley's naming authority will always get queried for this 
work?  That the trust and security for this work will reside with a John 
Wiley server and not with a Springer server?  Or will the John Wiley server 
always need to redirect the client to the Springer server?  If so, 
hopefully Springer won't sell it or it won't be sold many times - or else 
the client will be chasing around the Internet for awhile.

thanks, Mark



>Larry
>
>At 09:36 PM 5/24/01 -0700, Mark Baugher wrote:
> >Here are the remaining questions and comments from the 
> draft-irtf-idrm-handle-system-00.txt.  Regarding my previous comments,is 
> it accurate to say that the Handle System protocols could in principle be 
> used with a variety of different servers/resolvers including DDDS?
> >
> >I have five points.
> >
> >1)  Section 1, under "Secured Named Service" describes specific 
> cryptographic mechanisms but "Distributed Administration Service" does 
> not.  By briefly mentioning specific security and cryptographic 
> mechanisms in this document, rather than in the later documents where 
> they are specified, I think you raise more questions than you can answer 
> in an Overview document.
> >
> >2)  Section 2, para 2, suggests that a persistent name can never be 
> moved between naming authorities.  If all rights to a content work were 
> completely transferred from a corporation operating naming authority x, 
> to one operating naming authority y, then the content work will still 
> have x in its name.  This seems like a problem to me.  The DOI Handbook 
> makes a point about handles being "dumb numbers," but these handles 
> reveal information that will persist even when no longer valid.
> >
> >3) Section 4, para 3, last sentence, defines an enormous PKI for a 
> global namespace and I have some doubts about providing a security 
> service for referencing potentially any content item in the world.  It is 
> a scalability issue if the handle system is not designed for 
> smaller-scale and private use or if the trust and security mechanisms 
> cannot be tailored to the needs of individual organizations and national 
> considerations.  There are large political issues here.  This is the main 
> problem I have with the Handle System.  We may have an opportunity to 
> consider this at length when discussing the next two drafts.
> >
> >4) Section 4, para 5, should discuss the assets to be protected (e.g. 
> handle metadata), the risks to those assets (e.g. corruption of handle 
> metadata), and the sources of threats (e.g. hackers seeking fame or 
> criminals seeking fortune).  I believe the sentence "To trust a Local 
> Handle Service means to trust that it will correctly respond with data 
> that was entered by the administrator" is a too general to be useful.
> >
> >5) The document needs a security section and should follow the other 
> guidelines for formatting and mandatory sections of RFC 2223.
> >
> >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote:
> >>Oh, by the way, this note is commenting upon 
> draft-irtf-idrm-handle-system-00.txt and not 
> draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the 
> Subject line that I'll correct in subsequent responses.
> >>
> >>Mark
> >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote:
> >>>I have a number of comments on this draft.  I also plan to post 
> comments on the two other handle drafts, 
> draft-irtf-idrm-handle-system-def-00.txt and 
> draft-irtf-idrm-handle-system-protocol-00.txt.  I'll start with 
> draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since 
> my other questions and comments may be resolved along the way.
> >>>
> >>>My first comment is that there does not seem to be name-resolution 
> draft in the mix.  Is this not to be published?  I can see a lot of uses 
> for a namespace that is not global, such as between a content provider 
> (publisher) and service provider (distributor) that want to use the 
> metadata facilities of handles to store rights information with the 
> content work and to identify one or more "official repositories" for the 
> content work.  If you're requiring a global namespace but not publishing 
> the resolution mechanisms, then this seems to be an impediment to many 
> business-to-business uses.
> >>>
> >>>Mark