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

[Larry Lannom]

I'll let Sam answer the hard questions, but I believe your second poi=
nt goes fairly directly to the 'semantically meaningful naming author=
ity issue.' If the naming authority moving from X to Y is 10.3692 the=
n the revealed information is a little obscure. If you have a good me=
mory or access to administrative logs you may be able to tell that th=
e handle10.3692/abc used to be owned and administered by X but has no=
w moved to Y. If the handle was JohnWileyAndSons.JournalDivision/abc =
then the situation is a little more confusing. This has been the subj=
ect of a good deal of discussion over the years and I strongly encour=
age 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 ins=
tance of a block of handles moving from one owner to another with no =
apparent problems (American Chemical Society selling a journal to Wil=
ey). So there are two potential problems with the transfer of ownersh=
ip of Handles or Handle NAs: 1) semantically meaningful NAs and 2) sp=
litting a set of handles under one NA across two or more owners who w=
ant to administer their handles on different local handle services - =
this is possible because the granularity of ownership is at the indiv=
idual handle level and a potential problem because clients are direct=
ed to local services by the global root based on NA. This situation h=
asn't arisen (all DOIs, e.g., are in a single local service) but coul=
d be forbidden by local service policy (the DOI choice) or by providi=
ng clients with non-deterministic answers. This potential problem was=
 a direct trade-off for 1) allowing local services and 2) putting own=
ership granularity at the handle level. So far it seems like the righ=
t choice.

Larry

At 09:36 PM 5/24/01 -0700, Mark Baugher wrote:
>Here are the remaining questions and comments from the draft-irtf-id=
rm-handle-system-00.txt.  Regarding my previous comments,is it accura=
te 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 cryp=
tographic mechanisms but "Distributed Administration Service" does no=
t.  By briefly mentioning specific security and cryptographic mechani=
sms in this document, rather than in the later documents where they a=
re 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 we=
re completely transferred from a corporation operating naming authori=
ty 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 val=
id.
>
>3) Section 4, para 3, last sentence, defines an enormous PKI for a g=
lobal namespace and I have some doubts about providing a security ser=
vice for referencing potentially any content item in the world.  It i=
s a scalability issue if the handle system is not designed for smalle=
r-scale and private use or if the trust and security mechanisms canno=
t be tailored to the needs of individual organizations and national c=
onsiderations.  There are large political issues here.  This is the m=
ain problem I have with the Handle System.  We may have an opportunit=
y 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 han=
dle metadata), and the sources of threats (e.g. hackers seeking fame =
or criminals seeking fortune).  I believe the sentence "To trust a Lo=
cal Handle Service means to trust that it will correctly respond with=
 data that was entered by the administrator" is a too general to be u=
seful.
>
>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 subsequen=
t 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 co=
mments 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 s=
tart with draft-irtf-idrm-handle-system-00.txt comments, a couple at =
a time since my other questions and comments may be resolved along th=
e 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 pr=
ovider (publisher) and service provider (distributor) that want to us=
e 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 no=
t publishing the resolution mechanisms, then this seems to be an impe=
diment to many business-to-business uses.
>>>
>>>Mark