Subject: [decade] CDMI

From: Songhaibin <[email-masked]>
Date: Fri, 23 Sep 2011 07:40:20 +0000

Dear folks,

When I was reading CDMI protocol, it seems that the objects should be created within a "container". Then I had a question in mind. If we do not have the "container" concept in DECADE, the CDMI protocol needs change if we want to use it for DECADE. If there are many places need changes, I am not sure whether it is a good sign.

BR,
-Haibin (as individual)

---

From: Richard Alimi <[email-masked]>
Date: Fri, 23 Sep 2011 01:39:08 -0700

> When I was reading CDMI protocol, it seems that the objects should be created within a "container". Then I had a question in mind. If we do not have the "container" concept in DECADE, the CDMI prot…

Could we put all objects in a container named "decade"?

> BR,
> -Haibin (as individual)
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>

---

From: Songhaibin <[email-masked]>
Date: Fri, 23 Sep 2011 09:21:28 +0000

Hi Rich,

Thanks for the interesting answer. Then I still have doubts. Who creates this container? Who has the right to operate on this container? Maybe the DECADE service provider?

BR,
-Haibin(as individual)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Friday, September 23, 2011 4:39 PM
> To: Songhaibin
> Cc: [email-masked]
> Subject: Re: [decade] CDMI
> 
> > When I was reading CDMI protocol, it seems that the objects should be
> created within a "container". Then I had a question in mind. If we do not have
> the "container" concept in DECADE, the CDMI protocol needs change if we
> want to use it for DECADE. If there are many places need changes, I am not
> sure whether it is a good sign.
> >
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 23 Sep 2011 10:19:24 +0000

Or does the container correspond to the user? Do CDMI access controls derive from a container?

-- Rich (as individual)

----- Original Message -----
From: Songhaibin [mailto:[email-masked]]
Sent: Friday, September 23, 2011 05:21 AM
To: Richard Alimi <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [decade] CDMI

Hi Rich,

BR,
-Haibin(as individual)

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 23 Sep 2011 10:15:28 -0400

Hi Rich/Haibin/Rich,

My understanding is as follows from reading the CDMI SNIA spec
http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf

1)A container is a grouping of individual data objects.  All data
objects must be placed inside at least one level of container.  (See
data model in Fig. 6 on pg 13)

2) A user can create either an individual data object or a container
containing multiple data objects (see sec. 5.5 on pg. 11, and 1st
paragraph of pg. 14).  Similarly a user can read either the whole
container, or an individual object in the container (see sec. 5.5 on pg.
15).  Finally, the access control for the user can be applied to both
the individual data object level or the container level through the
metadata concept.

3) The HTTP PUT command used to create a new container is shown in (sec
6.2 on pg. 19).  The HTTP PUT command used to create a data object in a
container is shown in (sec. 6.3 on pg. 19).

Finally, the WEBDAV protocol also supports a concept called
"collections" (of resources) which is similar to the CDMI "container"
object (see http://tools.ietf.org/html/rfc4918#section-5).  So I think
this points to the fact that we should support some concept in DECADE
similar to a container.

Any feedback would be appreciated.

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Friday, September 23, 2011 6:19 AM
To: [email-masked]'; [email-masked]'
Cc: [email-masked]'
Subject: Re: [decade] CDMI

Or does the container correspond to the user? Do CDMI access controls
derive from a container?

-- Rich (as individual)

----- Original Message -----
From: Songhaibin [mailto:[email-masked]]
Sent: Friday, September 23, 2011 05:21 AM
To: Richard Alimi <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [decade] CDMI

Hi Rich,

Thanks for the interesting answer. Then I still have doubts. Who creates
this container? Who has the right to operate on this container? Maybe
the DECADE service provider?

BR,
-Haibin(as individual)

---

From: Richard Alimi <[email-masked]>
Date: Sun, 25 Sep 2011 21:39:13 -0700

So, here's my two cents :) Conceptually DECADE Object IDs form a flat
namespace, so that's why I was proposing to have a single "/decade"
container beneath which all of the objects could be stored and
referenced.  The container could be created at installation time or
on-demand, as determined by the DECADE server implementation.

Then, one way to think about what we are proposing is for each user to
have a "view" into the set of data objects at each particular DECADE
Server.  In that sense, Rich Woundy's suggestion of having one
container per user makes sense.  Then, data objects could be addressed
by something like "/<userid>/<objectid>".

I think that either of these addressing schemes could work. Consider a
DECADE server receiving a request with a token "userid=A,object=1234".
Using the flat namespace approach, a client would know to make a
request for "/decade/1234" and present the token. The server could
then internally validate the token and that user A does indeed have
object 1234.  Using the container-per-user approach, the DECADE client
would know to make a request for "/A/1234" and the server then
validate the token. The benefit of the container-per-user approach is
that we'd get the check "does user A have object 1234" for free from
CDMI.

As another point, one thing we should consider is how traditional CDMI
access controls interact with DECADE tokens.  One way to think about
it is that we are adding a way to bypass the normal ACL check in CDMI.
 Another, perhaps cleaner, to think about it is that we're adding a
new "validate DECADE token" entry to each object's CDMI ACL.

Rich

---

From: Richard Alimi <[email-masked]>
Date: Sun, 25 Sep 2011 21:47:45 -0700

Hi Akbar,

> this points to the fact that we should support some concept in DECADE

I think we should be very careful when adding containers.  For
example, if we were to follow the approach of allowing arbitrary
containers to be created, then we run into issues with naming.  In
particular, referring to an object by its name (content hash) no
longer makes quite as much sense since the requesting client also need
to know its path.  Following that reasoning one step further, I think
it would be better to avoid passing full paths within DRP tokens or
the applications' native protocols since that then binds their
implementations to a particular the DECADE data transport.  It seems
preferable to only need to pass around a DECADE object ID (and perhaps
a userid that has local scope to a DECADE server), and then generate
actual names in the data transport from only those components.  Then
the protocol could (eventually) evolve to allow one client to write an
object using CDMI, and another client could receive a token and read
the same object using NFS-with-RDMA.

(Note that even though I did mention multiple data transports above, I
still think we should only do one for now as mandatory - I just don't
think we should create a design which makes it hard to add a new one
later on.)

Now, that said, I do think that containers might be useful for
organizing the data objects within a *single* DECADE server. For
example, have one container per user (as mentioned by Rich Woundy).

Rich

---

From: Dirk Kutscher <[email-masked]>
Date: Mon, 26 Sep 2011 12:58:46 +0000

Hi all,

I think I agree to Rich A. here. I have not seen a strong requirement for containers in DECADE and would be hesitant to introduce the concept just because WEBDAV and CDMI support corresponding abstractions.

Also, I do agree that DECADE identifiers should be independent from the DECADE transport protocol for the reasons that Rich mentioned.

Best regards,

Dirk

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Alimi
> Sent: Montag, 26. September 2011 06:48
> To: Rahman, Akbar
> Cc: [email-masked]
> > 6.2 on pg. 19).  The HTTP PUT command used to create a data object in
> > a container is shown in (sec. 6.3 on pg. 19).
> >
> >
> I think we should be very careful when adding containers.  For example, if we
> were to follow the approach of allowing arbitrary containers to be created,
> then we run into issues with naming.  In particular, referring to an object by
> its name (content hash) no longer makes quite as much sense since the
> requesting client also need to know its path.  Following that reasoning one
> step further, I think it would be better to avoid passing full paths within DRP
> tokens or the applications' native protocols since that then binds their
> preferable to only need to pass around a DECADE object ID (and perhaps a
> userid that has local scope to a DECADE server), and then generate actual
> names in the data transport from only those components.  Then the protocol
> could (eventually) evolve to allow one client to write an object using CDMI,
> and another client could receive a token and read the same object using NFS-
> with-RDMA.
> 
> (Note that even though I did mention multiple data transports above, I still
> think we should only do one for now as mandatory - I just don't think we
> should create a design which makes it hard to add a new one later on.)
> 
> Now, that said, I do think that containers might be useful for organizing the
> data objects within a *single* DECADE server. For example, have one
> container per user (as mentioned by Rich Woundy).
> 
> Rich
> 
> >
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Woundy, Richard
> > Thanks for the interesting answer. Then I still have doubts. Who
> > creates this container? Who has the right to operate on this
> > container? Maybe the DECADE service provider?
> >
> > BR,
> > -Haibin(as individual)
> >
> >> want to use it for DECADE. If there are many places need changes, I
> >> am
> > not

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 26 Sep 2011 12:15:14 -0400

Hi Rich,

Thanks for your insights.  One practical issue that I want to restate for CDMI is that a root and/or container seems to be mandatory.  That is, even if you have only one object, it must be first placed within a root and/or container.  This means for example that you must to have some knowledge of the URI path of the root and/or container in all cases (i.e. knowledge of the URI beyond the authority part).  So the object ID itself is not enough to retrieve the object in CDMI (as you correctly pointed out in your reasoning below).

See for example section 8.2 of http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf

So if we wanted to re-use CDMI this implies that we would have to do fairly major changes to it.  I am not saying this is good or bad, I am just pointing it out!

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Monday, September 26, 2011 12:48 AM
To: Rahman, Akbar
Cc: Woundy, Richard; [email-masked]; [email-masked]
Subject: Re: [decade] CDMI

Hi Akbar,

Rich

---

From: Richard Alimi <[email-masked]>
Date: Mon, 26 Sep 2011 09:44:30 -0700

> Thanks for your insights.  One practical issue that I want to restate for CDMI is that a root and/or container seems to be mandatory.  That is, even if you have only one object, it must be first pl…

Right - the DECADE client would need to be told (presumably by a
DECADE specification) how to construct the URI for a particular DECADE
data object.  The same kind of thing would have had to be done if we
went with WebDAV or HTTP.

> So if we wanted to re-use CDMI this implies that we would have to do fairly major changes to it.  I am not saying this is good or bad, I am just pointing it out!

Well, so I don't think we need to make use of all mechanisms that CDMI
provides. For example, just because a CDMI server implementation also
gives data objects their own unique Object ID that is unrelated to
DECADE doesn't mean we need to refer to objects under that ID.

Thanks,
Rich