Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 3 Oct 2011 00:24:39 -0400

Hi,

Thanks to the authors for updating the I-D.  Overall the document looks
in good shape.  I only have the following two comments:

-          Section 4.1.1.1 - Often protocols like STUN are required to
account for NATs.  I was not sure if this requirement meant that we
should NOT use something like STUN as part of the overall DECADE
solution (especially for DECADE server to server communications)?   Is
the real intent to force all DECADE servers to be on the public
Internet?  If so then perhaps it would be better to re-phrase the
requirement?  Finally, I was confused by the reason for the separate
requirement of 6.1.2 that touched on the same issue.

-          Section 7 - What does the section title of "Discussion" mean?
If there is still open issues then the document should not go to WGLC.
If these requirements are solid, then they should be written in the same
format as the other sections of the document.

Akbar

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Thursday, September 29, 2011 8:13 AM
To: [email-masked]
Subject: [decade] Start of WGLC for draft-ietf-decade-reqs-04

Folks,

Haibin and I are starting the working group last call for
draft-ietf-decade-reqs-04,
http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed
by Monday October 17. Please send all concerns, suggestions and comments
about this internet-draft to the DECADE mailing list, [email-masked].

Authors, please do not make any additional changes to the internet-draft
unless directed by the WG chairs.

Draft reviewers, it would be helpful to get your confirmation that your
previous review comments have been correctly reflected in this version.

Thanks.

-- Rich and Haibin

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 11 Oct 2011 14:19:29 +0000

Just a reminder that the WGLC for the DECADE requirements draft (draft-ietf-decade-reqs-04) ends next Monday October 17.

If you think the document is ready to move forward, please state this on the list by Monday and not just silently agree.

It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman, and Borje Ohlman) would confirm that their draft comments were addressed in this version by Monday.

-- Rich

From: Woundy, Richard
Sent: Thursday, September 29, 2011 8:13 AM
To: [email-masked]
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-reqs-04

Folks,

Haibin and I are starting the working group last call for draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, [email-masked]<mailto:[email-masked]>.

Authors, please do not make any additional changes to the internet-draft unless directed by the WG chairs.

Draft reviewers, it would be helpful to get your confirmation that your previous review comments have been correctly reflected in this version.

Thanks.

-- Rich and Haibin

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 11 Oct 2011 14:22:30 +0000

Just a reminder that the WGLC for the DECADE architecture draft (draft-ietf-decade-arch-03) ends next Monday October 17.

It would also help if our WG expert reviewers (Martin Stiemerling, David McDysan, and Borje Ohlman) would confirm that their draft comments were addressed in this version by Monday.

-- Rich

From: Woundy, Richard
Sent: Thursday, September 29, 2011 8:14 AM
To: [email-masked]
Cc: Songhaibin; Woundy, Richard
Subject: Start of WGLC for draft-ietf-decade-arch-03

Folks,

Haibin and I are starting the working group last call for draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, [email-masked]<mailto:[email-masked]>.

Thanks.

-- Rich and Haibin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 11 Oct 2011 12:07:32 -0400

Hi Richard,

All the comments from my previous review were addressed in rev -04 of
the requirements document.  Thanks to the authors for taking care of
that.  I did however have two new comments on rev -04:

Section 4.1.1.1 - Often protocols like STUN are required to account for
NATs.  I was not sure if this requirement meant that we should NOT use
something like STUN as part of the overall DECADE solution (especially
for DECADE server to server communications)?   Is the real intent to
force all DECADE servers to be on the public Internet?  If so then
perhaps it would be better to re-phrase the requirement?  Finally, I was
confused by the reason for the separate requirement of 6.1.2 that
touched on the same issue.

 

http://www.ietf.org/mail-archive/web/decade/current/msg00517.html

 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Woundy, Richard
Sent: Tuesday, October 11, 2011 10:19 AM
To: [email-masked]
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04

Just a reminder that the WGLC for the DECADE requirements draft
(draft-ietf-decade-reqs-04) ends next Monday October 17.

If you think the document is ready to move forward, please state this on
the list by Monday and not just silently agree.

It would also help if our WG expert reviewers (Dave McDysan, Akbar
Rahman, and Borje Ohlman) would confirm that their draft comments were
addressed in this version by Monday.

-- Rich

From: Woundy, Richard 

Folks,

Thanks.

-- Rich and Haibin

---

From: ZongNing <[email-masked]>
Date: Wed, 12 Oct 2011 23:56:57 +0000

I have read the draft and think it forms a good basis for further DECADE protocol design.
Yes, I want to see it move forward.

BR,
Ning Zong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Woundy, Richard
Sent: Tuesday, October 11, 2011 10:23 PM
To: [email-masked]
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03

-- Rich

From: Woundy, Richard

Folks,

Thanks.

-- Rich and Haibin

---

From: Börje Ohlman <[email-masked]>
Date: Fri, 14 Oct 2011 13:11:56 +0200

Hi,

I think the draft is in very good shape, thanks to the authors for an excellent job. All my previous comments are addressed by this draft. However looking through it last night I have some additional comments.
----------

> 5.1. Immutable Data
> REQUIREMENT(S): DECADE MUST provide the ability to manage data
> objects that are immutable once they are written to storage.

I think this requirement is a bit unclear on what is actually meant. My understanding from our discussions is that DECADE MUST *only* store immutable data objects. If that is the intention, I think that should be stated more clearly. I don't think the word "ability" is the best to express this requirement. An alternative formulation could be:
"DECADE MUST only store and manage data objects that are immutable once they are written to storage."

If I have misunderstood the intention of this requirement and that it should also be possible to store mutable data in DECADE servers, then I think such an explicit requirement should be added.
------------

> 5.2. Explicit Deletion of Data
> REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
> to explicitly delete data from its own in-network storage.

> RATIONALE: A DECADE client may continually be writing data to its
> in-network storage. Since there may be a limit (e.g., imposed by
> the storage provider) to how much total storage can be used, some
> data may need to be removed to make room for additional data. A
> DECADE client should be able to explicitly remove particular
> data. This may be implemented using existing protocols.

When reading the rationale for this requirement I start to thinking that we might want to add something about automatic removal of old data according to some policy, e.g. that DECADE storage servers SHOULD be able to remove old data according to some policy, e.g. LLRU. This should be of interest, e.g. when a quota is being filled up, to avoid having to deny further writings. This should be especially relevant in the mentioned case of continuous writings,  e.g. for streaming data.
-----------------

	Börje

On 29 sep 2011, at 14.12, Woundy, Richard wrote:

> Folks,
>  
> Haibin and I are starting the working group last call for draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, [email-masked].
>  
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade

---

From: Richard Alimi <[email-masked]>
Date: Sun, 16 Oct 2011 08:06:29 -0700

Hi Akbar,

On Tue, Oct 11, 2011 at 9:07 AM, Rahman, Akbar
<[email-masked]> wrote:
> Hi Richard,
>
>
>
>
>
> All the comments from my previous review were addressed in rev -04 of the
> requirements document.  Thanks to the authors for taking care of that.  I
> did however have two new comments on rev -04:
>
>
>
>
>
> Section 4.1.1.1 – Often protocols like STUN are required to account for
> something like STUN as part of the overall DECADE solution (especially for
> DECADE server to server communications)?

For client <-> server communications, the intent is that we should not
be required to use something like STUN.

For server <-> server, see below...

>   Is the real intent to force all
> DECADE servers to be on the public Internet?  If so then perhaps it would be
> better to re-phrase the requirement?

Looking at this again, I think we should be more careful to limit this
requirement to client <-> server communications.  The current thoughts
for the server <-> server protocol treat servers as peers of each
other.  If servers are behind NATs I think we'd have to resort to
dirty tricks.

Any complaints with that?

As to whether they need to be on the public Internet, I could imagine
enterprise networks having deployments of DECADE servers that are not
accessible from the public Internet, but only for use by internal
applications.

>  Finally, I was confused by the reason
> for the separate requirement of 6.1.2 that touched on the same issue.
>

That one refers to the discovery protocol as a separate entity.  I
might see good reasons to be explicit about this.  Without it, I could
imagine solutions in which discovery didn't work behind NATs, and the
application using DECADE was just supposed to deal with it.

>
>
> -          Section 7 – What does the section title of “Discussion” mean?  If
> there is still open issues then the document should not go to WGLC.  If
> these requirements are solid, then they should be written in the same format
> as the other sections of the document.

To be more specific, these are issues that came up during the design
of the other requirements in the document. However, they are things
explicitly left out.  The intent was to tell the reader "yes, we
considered them, but they are not requirements and here's why".

That said, the first one (7.1. Non-DECADE Internal Protocols) might be
better placed somewhere else.

Thanks again,
Rich

> If you think the document is ready to move forward, please state this on the
> list by Monday and not just silently agree.
>
>
>
> It would also help if our WG expert reviewers (Dave McDysan, Akbar Rahman,
> and Borje Ohlman) would confirm that their draft comments were addressed in
> this version by Monday.
>
>
>
> -- Rich
>
>
>
> From: Woundy, Richard
> http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/, to be completed by
> Monday October 17. Please send all concerns, suggestions and comments about
> this internet-draft to the DECADE mailing list, [email-masked].
>
>
>

---

From: Richard Alimi <[email-masked]>
Date: Sun, 16 Oct 2011 08:41:31 -0700

> considered them, but they are not requirements and here's why".

And I left out... might there be a better suggestion for naming the section? :)

---

From: "Woundy, Richard" <[email-masked]>
Date: Sun, 16 Oct 2011 15:53:19 +0000

> And I left out... might there be a better suggestion for naming the section? :)

Future considerations.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Sunday, October 16, 2011 11:42 AM
To: Rahman, Akbar
Cc: Woundy, Richard; [email-masked]
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04

On Sun, Oct 16, 2011 at 8:06 AM, Richard Alimi <[email-masked]> wrote:
>> -          Section 7 - What does the section title of "Discussion" mean?  If

---

From: Richard Alimi <[email-masked]>
Date: Sun, 16 Oct 2011 08:53:20 -0700

On Fri, Oct 14, 2011 at 4:11 AM, Börje Ohlman <[email-masked]> wrote:
> Hi,
> I think the draft is in very good shape, thanks to the authors for an
> excellent job. All my previous comments are addressed by this draft. However
> looking through it last night I have some additional comments.
> ----------
>
> 5.1. Immutable Data
> I think this requirement is a bit unclear on what is actually meant. My
> understanding from our discussions is that DECADE MUST *only* store
> immutable data objects. If that is the intention, I think that should be
> stated more clearly. I don't think the word "ability" is the best to express
> this requirement. An alternative formulation could be:
> If I have misunderstood the intention of this requirement and that it should
> also be possible to store mutable data in DECADE servers, then I think such
> an explicit requirement should be added.

Your understanding was correct, and I agree with your suggested text.
Any complaints from others with adopting that?

> When reading the rationale for this requirement I start to thinking that we
> might want to add something about automatic removal of old data according to
> some policy, e.g. that DECADE storage servers SHOULD be able to remove old
> data according to some policy, e.g. LLRU. This should be of interest, e.g.
> when a quota is being filled up, to avoid having to deny further writings.
> This should be especially relevant in the mentioned case of continuous
> writings,  e.g. for streaming data.

This is a very good question.  Two comments here:
(1) We already have 4.4.3 which allows objects to be deleted after a
time-to-live, which can help with the streaming case.
(2) I think what you are proposing is a more general mechanism for
cache-replacement.  While I think that would be a nice feature to
have, I'm a bit concerned about the complexity.  I might imagine
something as complex as designing a new specification language for
custom cache replacement policies, or something as simple as "we
specify LRU and LFU - the rest are extensions".  The latter might work
in certain cases, but for cases such as VoD / DVR type stuff, I'm not
sure either is sufficient (I may just not have watched the program
yet).  Furthermore, what happens when multiple applications (run by
the same user, accessing the same account) each want to have their own
cache replacement policy and they might be in conflict?

Thoughts?

Thanks,
Rich

> draft-ietf-decade-reqs-04, http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/,
> to be completed by Monday October 17. Please send all concerns, suggestions
> and comments about this internet-draft to the DECADE mailing
> list, [email-masked].
>

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 17 Oct 2011 00:25:10 -0400

Hi Rich,

Thanks for your responses.  I have given my feedback identified by "**** AKBAR: ".

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Sunday, October 16, 2011 11:06 AM
To: Rahman, Akbar
Cc: Woundy, Richard; [email-masked]
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04

Hi Akbar,

**** AKBAR: OKAY.  I AGREE WITH YOUR ABOVE CLARIFICATION.*********

**** AKBAR: YES, I AGREE WITH YOUR POINT.*********

**** AKBAR: OKAY.*********

**** AKBAR: THEN I THINK THAT YOU SHOULD RENAME THE SECTION AS PER RICH WOUNDY'S
SUGGESTION IN HIS EMAIL.  ALSO I THINK YOU NEED TO ADD AN INTRODUCTORY PARAGRAPH
CAPTURING WHAT YOU SAID ABOVE.*********

**** AKBAR: OKAY.*********

Thanks again,
Rich

---

From: Börje Ohlman <[email-masked]>
Date: Mon, 17 Oct 2011 17:02:42 +0200

Dear All,

I think the current draft is in a very good shape, great thanks to the authors. Regarding my comments from the previous review I happy to say that, as far as I can see, all, except one has been addressed. The one I see not directly addressed I think is of lesser importance and maybe it was a conscious decision not to include that, if so I have no major problem with it.
I have a number of new comments regarding the current text but they do not constitute any objections but points to were the text could be made clear to avoid misunderstandings.
The one thing I comment on that could cause some discussion is whether both clients and servers should be allowed to name objects. I think it is not entirely clear from the current draft how this should be dealt with. I think both cases should be allowed.
Please see below for my review report.

Best regards,
			Börje

The previous comment that I do not see as addressed is how overbooking of resources should be dealt with in DECADE. This is probably to large extent an SLA issue, but I think it would raise the issue in this draft. In my review of the previous draft I wrote:
> Is it allowed for decade service providers to oversell the resources of their servers (both bandwidth and storage), similar to airline overbooking? I think overbooking should be allowed to maximize resource utilization. Especially regarding bandwidth I think it is unavoidable. It would be good if this was addressed in the draft, e.g. in 4.2.

For comments on the current draft:

6.1.14 last §
"If an application wishes to store such metadata persistently within DECADE, it can be stored within data objects themselves."
Add "or as separate objects" to be consistent with previous formulations regarding this.

6.2.1 §1
In the first § it is unclear if the client or the server is naming the object. If both alternatives are allowed this should be stated explicitly and it should be added a comment to the parameter NAME that it can be empty. 

Then in §4 it is stated "The application that originates the objects MUST generate DECADE object names according to the naming specification in Section 5.3." Is it sure that we want this? Sensors might want the server to generate the names.

6.2.1 last §
It states "Specifics regarding error handling, including additional error conditions, precedence for returned errors and its relation with server policy, are deferred to eventual protocol specification." Should not lack of resources be mentioned here as well as it is an obvious issue. This would be a possible place to add a comment on the issue with overbookings.

7 §2
It states "All data operations are performed on behalf of DECADE clients via explicit instruction, ..."
It is unclear from this text if the client has to be using the DECADE Protocol to perform this action or if an management or application protocol can be used to instruct the remote server. Should it not also be allowed for the client to delegate these operations to e.g. a cache managment application?

7.1 §5
It states "Though explicitly supplying these may provide additional freedom, it is not clear what benefit they might provide."
It is unclear what the "they" refers to. I have problems understanding the meaning of this sentence.

7.1 last §
It states "In the case of a GET operation, the DECADE server is to retrieve the data object from the remote server using the specified credentials (via a GET request to the remote server), and then return the object to the client."
Why should the object be returned to the client? If this is just about cache management there is no reason to return the object to the client. 
Further it states: "In the case of a PUT operation, the DECADE server is to store the object from the client..." This sounds like the client making this PUT I thought this was about server to server communication. Also should not policies for the object, e.g. ttl, be stored?

8.1 first §
It states "A DECADE server may choose to not fully store an object before beginning to serve it." The 'may choose' is not consistent with the MUST requierment to be able to deliver before fully stored.

A.1.4
s/deleting/deletion/

On 29 sep 2011, at 14.13, Woundy, Richard wrote:

> Folks,
>  
> Haibin and I are starting the working group last call for draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/, to be completed by Monday October 17. Please send all concerns, suggestions and comments about this internet-draft to the DECADE mailing list, [email-masked].
>

---

From: Richard Alimi <[email-masked]>
Date: Mon, 17 Oct 2011 23:51:35 -0700

Hi Börje,

Thank you very much for the review.  Responses inline...

On Mon, Oct 17, 2011 at 8:02 AM, Börje Ohlman <[email-masked]> wrote:
> Dear All,
>
> I think the current draft is in a very good shape, great thanks to the
> authors. Regarding my comments from the previous review I happy to say that,
> as far as I can see, all, except one has been addressed. The one I see not
> directly addressed I think is of lesser importance and maybe it was a
> conscious decision not to include that, if so I have no major problem with
> it.
> I have a number of new comments regarding the current text but they do not
> constitute any objections but points to were the text could be made clear to
> avoid misunderstandings.
> The one thing I comment on that could cause some discussion is whether both
> clients and servers should be allowed to name objects. I think it is not
> entirely clear from the current draft how this should be dealt with. I think
> both cases should be allowed.
> The previous comment that I do not see as addressed is how overbooking of
> resources should be dealt with in DECADE. This is probably to large extent
> an SLA issue, but I think it would raise the issue in this draft. In my
> review of the previous draft I wrote:
>
> Is it allowed for decade service providers to oversell the resources of
> their servers (both bandwidth and storage), similar to airline overbooking?
> I think overbooking should be allowed to maximize resource utilization.
> Especially regarding bandwidth I think it is unavoidable. It would be good
> if this was addressed in the draft, e.g. in 4.2.

My personal feeling is that this is a question of policy and not a
question for the protocol or architecture.  Do you think that leaving
it out of scope will cause issues in the design or eventual protocol
specification?  I could see policy, algorithms, and deployments
changing based on whether oversubscription is used, but what do you
think the protocol ramifications might be?  Presumably we will need
the architecture/protocol to have all the nice features of any
protocol such as overload handling anyways (those are already in the
requirements).

> "If an application wishes to store such metadata persistently within DECADE,
> it can be stored within data objects themselves."

Sounds good to me.  So noted.

> 6.2.1 §1
> In the first § it is unclear if the client or the server is naming the
> object. If both alternatives are allowed this should be stated explicitly
> and it should be added a comment to the parameter NAME that it can be
> empty.
> Then in §4 it is stated "The application that originates the objects MUST
> generate DECADE object names according to the naming specification in
> Section 5.3." Is it sure that we want this? Sensors might want the server to
> generate the names.

The original intent was for the name to be sent by the client, and
then validated by the server. That said, I have only two reservations
about having the server compute the name (if the client does not want
to):
(1) the server is forced to compute the hash which may be expensive.
I might imagine certain cases where servers disable this (knowing the
risks of not validating the hashes), in which case a request from such
a client would be rejected.  I don't think this would be common,
though.
(2) the client must trust the server if this is done (otherwise the
server can insert, remove, or completely fabricate the content and lie
about the name).

Therefore, I don't have a problem as long as the security
consideration is made completely clear.

Thoughts?

> 6.2.1 last §
> It states "Specifics regarding error handling, including additional
> error conditions, precedence for returned errors and its relation with
> server policy, are deferred to eventual protocol specification." Should not
> lack of resources be mentioned here as well as it is an obvious issue. This
> would be a possible place to add a comment on the issue with overbookings.

Would additionally mentioning "overload conditions" (as it is worded
in the requirements draft) suffice?

> It is unclear from this text if the client has to be using the DECADE
> Protocol to perform this action or if an management or application protocol
> can be used to instruct the remote server.

The intent was not to disallow access by administrative/management
protocols.  Would dropping the word "all" from the beginning of the
sentence help to clarify this?

> Should it not also be allowed for
> the client to delegate these operations to e.g. a cache managment
> application?

Can you clarify the use case?  Who owns/manages the cache management
application?  Is it the same person as the DECADE server?  Is it the
same person as the DECADE client?

> 7.1 §5
> It states "Though explicitly supplying these may provide additional freedom,
> it is not clear what benefit they might provide."

"they" refers to the data object and operation parameters.  For
example, a typical (normal) use case might be to request to download
object 1 from Server A, but indicating that it must fetch object 1
from Server B first.  Extending that slightly, I could imagine
constructing protocol messages to request to download object 1 from
Server A, but indicating it must fetch object 2 from Server B first.
There may be interesting use cases for something like that - this
sentence was merely trying to point this out.

We can drop this sentence if it creates confusion.

> 7.1 last §
> It states "In the case of a GET operation, the DECADE server is to retrieve
> the data object from the remote server using the specified credentials (via
> a GET request to the remote server), and then return the object to the
> client."
> Why should the object be returned to the client? If this is just about cache
> management there is no reason to return the object to the client.

No - it is not only about cache management. The client may not have
the object yet. However, that said, I might imagine cases where the
last step (downloading to the client itself) is optional, e.g., if it
wishes to delay downloading it over the last mile for later.  We
should add a note saying that it is optional.

> Further it states: "In the case of a PUT operation, the DECADE server is to
> store the object from the client..." This sounds like the client making this
> PUT I thought this was about server to server communication.

Yes - the server-to-server communication is explicitly controlled by the client.

Similarly, we should add a note here saying that the upload from the
client to its own server is optional (the object may already exist at
one server, and the client may want it replicated to another server).

> Also should not
> policies for the object, e.g. ttl, be stored?

Yes. This section states "DECADE re-uses the already-specified
protocols to support operations directly between servers", and these
were mentioned in Section 6.  Should we explicitly mention that such
attributes can also be configured on requests involving
server-to-server communication?

> 8.1 first §
> It states "A DECADE server may choose to not fully store an object
> before beginning to serve it." The 'may choose' is not consistent with the
> MUST requierment to be able to deliver before fully stored.

Just to be sure, you are referring to this statement?

  "A server MUST accept download requests for an object that is still
being uploaded."

That should indeed be a MAY to be consistent with the requirements
draft.  Objections?

> s/deleting/deletion/

Indeed. Noted.

Thanks!
Rich

> draft-ietf-decade-arch-03, http://datatracker.ietf.org/doc/draft-ietf-decade-arch/,

---

From: Börje Ohlman <[email-masked]>
Date: Tue, 18 Oct 2011 18:02:13 +0200

Comments inline...

> protocol such as overload handling anyways (those are already in the

Ok, fine.

> consideration is made completely clear.

I think both clients and servers  should be allowed to create name it is not up to the architecture to decide on what is appropriate in specific network environments.

> in the requirements draft) suffice?

Fine.

> sentence help to clarify this?

I think I should have included some more of the draft text here:
"All data operations are performed on behalf of DECADE clients
via explicit instruction, so additional capabilities are needed in
the DECADE client-server protocols DECADE clients must be able to
indicate to a DECADE server the following additional parameters:"

I think it is the formulation " additional capabilities are needed in
the DECADE client-server protocols" that is causing the problem by explicitly mentioning the DECADE protocols, a more neutral formulation not mentioning specific protocols I think would help.

> same person as the DECADE client?

One example would be a customer of network (and DECADE server) provider that just want to put data objects in it's 'local' DECADE storage and then want the network provider to populate other DECADE servers to provide a flexible CDN like functionality for the published objects.
> We can drop this sentence if it creates confusion.

Please do.

> should add a note saying that it is optional.

Fine.

> one server, and the client may want it replicated to another server).

Ok.

> server-to-server communication?

Would be good for clarity.

>  "A server MUST accept download requests for an object that is still

yes.

> That should indeed be a MAY to be consistent with the requirements

ok.

---

From: Richard Alimi <[email-masked]>
Date: Tue, 18 Oct 2011 09:14:56 -0700

> I think both clients and servers  should be allowed to create name it is not up to the architecture to decide on what is appropriate in specific network environments.

That's fine - but the security properties are different and need to be
called out explicitly.  Objections from others about allowing the
server to compute the name?

> indicate to a DECADE server the following additional parameters:"

Well, there is a missing period in there.  Noted :)

> the DECADE client-server protocols" that is causing the problem by explicitly mentioning the DECADE protocols, a more neutral formulation not mentioning specific protocols I think would help.

We could certainly drop the phrase "additional capabilities are needed
in the DECADE client-server protocols", but I think it would be
understood that we are only talking about DECADE (since thats what the
document is about, and the protocol that would eventually be defined).
Right?

> One example would be a customer of network (and DECADE server) provider that just want to put data objects in it's 'local' DECADE storage and then want the network provider to populate other DECADE…

I think this case can be handled by the existing architecture. The
client could give the entity doing the replication (the network
provider in this case) tokens that provide read/write access to its
data objects.

If you wanted to short-circuit this case by having the client not give
the tokens (since presumably the network provider owns the DECADE
servers and could replicate objects using some mechanism other than
DECADE), then that would be fine too - but that seems a bit too
specialized of a use case for this document.

>> That should indeed be a MAY to be consistent with the requirements

Thanks again for your detailed reading of the document!
Rich

---

From: Börje Ohlman <[email-masked]>
Date: Tue, 18 Oct 2011 19:28:53 +0200

For me your proposals are fine. No more comments.

	Börje

---

From: Songhaibin <[email-masked]>
Date: Fri, 21 Oct 2011 02:26:17 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Alimi
> Sent: Sunday, October 16, 2011 11:53 PM
> To: Börje Ohlman
> Cc: decade ietf
> > "DECADE MUST only store and manage data objects that are immutable once
> they
> > are written to storage."

I would agree with the change.

> cache replacement policy and they might be in conflict?

I think imposing some intelligent data deletion mechanism will make the design complicated. But TTL should be okay. Shall we leave them to the applications to implement and make DECADE design as simple as possible?

BR,
-Haibin (as individual)

---

From: Songhaibin <[email-masked]>
Date: Fri, 21 Oct 2011 03:07:59 +0000

Hi,

>>>> before beginning to serve it." The 'may choose' is not consistent 
>>>> with the MUST requierment to be able to deliver before fully stored.
>>> 

Shall we say the server "MUST" have the ability to serve the objects that is being uploaded, while the server "MAY" choose to do it?

BR,
-Haibin

> B?rje Ohlman
> Sent: Wednesday, October 19, 2011 1:29 AM
> To: Richard Alimi
> Cc: decade ietf
> >> I think both clients and servers  should be allowed to create name it is not up
> to the architecture to decide on what is appropriate in specific network
> environments.
> >
> >> the DECADE client-server protocols" that is causing the problem by explicitly
> mentioning the DECADE protocols, a more neutral formulation not mentioning
> specific protocols I think would help.
> >>
> >
> >> One example would be a customer of network (and DECADE server) provider
> that just want to put data objects in it's 'local' DECADE storage and then want the
> network provider to populate other DECADE servers to provide a flexible CDN
> like functionality for the published objects.
> >>
> >

---

From: Richard Alimi <[email-masked]>
Date: Thu, 20 Oct 2011 21:30:29 -0700

> I think imposing some intelligent data deletion mechanism will make the design complicated. But TTL should be okay. Shall we leave them to the applications to implement and make DECADE design as si…

I agree with having only TTL for now.  Additional deletion policies
might be done as extensions at a later time too.

Rich

---

From: Börje Ohlman <[email-masked]>
Date: Fri, 21 Oct 2011 07:47:41 +0200

Below..

> Shall we say the server "MUST" have the ability to serve the objects that is being uploaded, while the server "MAY" choose to do it?
Sounds good to me.

    Börje

---

From: Richard Alimi <[email-masked]>
Date: Thu, 20 Oct 2011 23:03:44 -0700

>From the standpoint of a DECADE client, is there value in
distinguishing between these two cases?
(1) a server is able, but not configured to to serve an object that is
being uploaded
(2) a server is not able to serve an object that is being uploaded

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Thu, 20 Oct 2011 23:51:48 -0700

On Fri, Sep 30, 2011 at 1:47 AM, Songhaibin <[email-masked]> wrote:
>
>
> Thanks to the authors for the hard work to give this update. This document
> is in good shape. I only have a few comments.
>
>
>
> Section 3, Paragraph 2, last sentence, “…to be defined within the DECADE
> Working Group.”
>
>
>
> Comment: Please note that a working group is not a long term body. But this
> document will last. So please do not refer to a working group in the
> document.
>

Good point - we will remove this reference.

>
>
> Section 4.2.1 Paragraph 1, “DECADE MUST allow clients to specify at least
> two classes of services for service: lowest possible latency and latency
> non-critical.”
>
>
>
> Comment: May need to change “two classes of services for service” to another
> description,  this sentence seems a little awkward with “services/service”.
>

Good catch. I think we can just remove the "for service".

>
>
>
>
> Section 6.1.1 Paragraph 2,  last sentence, “it may still read/write data a
> DECADE Server if authorized by another DECADE Client.”
>
>
>
> Comment: Need “from/to” before “a DECADE Server if…”.
>

Yes - noted.

Thanks!
Rich

>
>
> BR,
>
> -Haibin
>
>
>
>
>
> From: Woundy, Richard [mailto:[email-masked]]
> Sent: Thursday, September 29, 2011 8:13 PM
> To: [email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Fri, 21 Oct 2011 15:09:51 +0000

Hi,

On this comment:

> >>> 6.2.1 §1
> >>> In the first § it is unclear if the client or the server is naming
> >>> the object. If both alternatives are allowed this should be stated
> >>> explicitly and it should be added a comment to the parameter NAME
> >>> that it can be empty.
> >>> Then in §4 it is stated "The application that originates the objects
> >>> MUST generate DECADE object names according to the naming
> >>> specification in Section 5.3." Is it sure that we want this? Sensors
> >>> might want the server to generate the names.
> >>
> >> risks of not validating the hashes), in which case a request from
> >> such a client would be rejected.  I don't think this would be common,
> >> though.
> >> server can insert, remove, or completely fabricate the content and
> >> lie about the name).
> >>
> > I think both clients and servers  should be allowed to create name it is not
> up to the architecture to decide on what is appropriate in specific network
> environments.
> 
> That's fine - but the security properties are different and need to be called
> out explicitly.  Objections from others about allowing the server to compute
> the name?

IMO, in DECADE, we should leave it to the client only, otherwise the fundamental use case (application endpoint uploads named object, refers other endpoints to the objects using the name and authorization tokens) is not guaranteed to work in all cases.

For example, what if the server uses a hash algorithm that is not useful in an application context? What about compromised servers that give you a name that is not bound to the object etc?

I would prefer a clear separation of concerns: application endpoint create and name objects, DECADE servers distribute and host named objects.

Best regards,

Dirk

---

From: Dirk Kutscher <[email-masked]>
Date: Fri, 21 Oct 2011 15:09:48 +0000

Hi all,

First of all, thanks a lot, Börje, for the helpful review -- and thanks, Rich, for addressing the recent comments.

Let me comment on just this specific issue for now:

> > Shall we say the server "MUST" have the ability to serve the objects that is
> being uploaded, while the server "MAY" choose to do it?
> >
> 
> From the standpoint of a DECADE client, is there value in distinguishing
> between these two cases?
> (1) a server is able, but not configured to to serve an object that is being
> uploaded

Yes, right -- there is no way for the client to negotiate this with or request this from the server, so just requiring the capability will not help.

I'd say this could really be an implementation-specific decision. Some servers might be able to do it, others not. If you want to provide DECADE for download-based services only, you would not really need it.

So, "the server MAY...".

Best regards,

Dirk

> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of B?rje Ohlman
> >> > On Tue, Oct 18, 2011 at 9:02 AM, Börje Ohlman
> >> > <[email-masked]>
> >> wrote:
> >> >> Comments inline...
> >> >>
> >> >>>> The previous comment that I do not see as addressed is how
> >> >>>> overbooking
> >> of
> >> >>>> resources should be dealt with in DECADE. This is probably to
> >> >>>> large extent an SLA issue, but I think it would raise the issue
> >> >>>> in this draft. In my review of the previous draft I wrote:
> >> >>>>
> >> >>>> Is it allowed for decade service providers to oversell the
> >> >>>> resources of their servers (both bandwidth and storage), similar to
> airline overbooking?
> >> >>>> Especially regarding bandwidth I think it is unavoidable. It
> >> >>>> would be good if this was addressed in the draft, e.g. in 4.2.
> >> >>>
> >> >>> My personal feeling is that this is a question of policy and not
> >> >>> a question for the protocol or architecture.  Do you think that
> >> >>> leaving it out of scope will cause issues in the design or
> >> >>> eventual protocol specification?  I could see policy, algorithms,
> >> >>> and deployments changing based on whether oversubscription is
> >> >>> used, but what do you think the protocol ramifications might be?
> >> >>> Presumably we will need the architecture/protocol to have all the
> >> >>> nice features of any protocol such as overload handling anyways
> >> >>> (those are already in the requirements).
> >> >>
> >> >> Ok, fine.
> >> >>
> >> >>>
> >> >>>> 6.2.1 §1
> >> >>>> In the first § it is unclear if the client or the server is
> >> >>>> naming the object. If both alternatives are allowed this should
> >> >>>> be stated explicitly and it should be added a comment to the
> >> >>>> parameter NAME that it can be empty.
> >> >>>> Then in §4 it is stated "The application that originates the
> >> >>>> objects MUST generate DECADE object names according to the
> >> >>>> naming specification in Section 5.3." Is it sure that we want
> >> >>>> this? Sensors might want the server to generate the names.
> >> >>>
> >> >>> The original intent was for the name to be sent by the client,
> >> >>> and then validated by the server. That said, I have only two
> >> >>> reservations about having the server compute the name (if the
> >> >>> client does not want
> >> >>> to):
> >> >>> I might imagine certain cases where servers disable this (knowing
> >> >>> the risks of not validating the hashes), in which case a request
> >> >>> from such a client would be rejected.  I don't think this would
> >> >>> be common, though.
> >> >>> (2) the client must trust the server if this is done (otherwise
> >> >>> the server can insert, remove, or completely fabricate the
> >> >>> content and lie about the name).
> >> >>>
> >> to the architecture to decide on what is appropriate in specific
> >> network environments.
> >> >
> >> > That's fine - but the security properties are different and need to
> >> > be called out explicitly.  Objections from others about allowing
> >> > the server to compute the name?
> >> >
> >> >>
> >> >>>
> >> >>>> 6.2.1 last §
> >> >>>> It states "Specifics regarding error handling, including
> >> >>>> additional error conditions, precedence for returned errors and
> >> >>>> its relation with server policy, are deferred to eventual
> >> >>>> protocol specification." Should not lack of resources be
> >> >>>> mentioned here as well as it is an obvious issue. This would be
> >> >>>> a possible place to add a comment on the issue with
> >> overbookings.
> >> >>>
> >> >>> Would additionally mentioning "overload conditions" (as it is
> >> >>> worded in the requirements draft) suffice?
> >> >>
> >> >> Fine.
> >> >>
> >> >>>
> >> >>>> 7 §2
> >> >>>> It is unclear from this text if the client has to be using the
> >> >>>> DECADE Protocol to perform this action or if an management or
> >> >>>> application protocol can be used to instruct the remote server.
> >> >>>
> >> >>> The intent was not to disallow access by
> >> >>> administrative/management protocols.  Would dropping the word
> >> >>> "all" from the beginning of the sentence help to clarify this?
> >> >>
> >> >> "All data operations are performed on behalf of DECADE clients via
> >> >> explicit instruction, so additional capabilities are needed in the
> >> >> DECADE client-server protocols DECADE clients must be able to
> >> >> I think it is the formulation " additional capabilities are needed
> >> >> in the DECADE client-server protocols" that is causing the problem
> >> >> by explicitly
> >> mentioning the DECADE protocols, a more neutral formulation not
> >> mentioning specific protocols I think would help.
> >> >>
> >> >
> >> > We could certainly drop the phrase "additional capabilities are
> >> > needed in the DECADE client-server protocols", but I think it would
> >> > be understood that we are only talking about DECADE (since thats
> >> > what the document is about, and the protocol that would eventually be
> defined).
> >> > Right?
> >> >
> >> >>>
> >> >>>> Should it not also be allowed for the client to delegate these
> >> >>>> operations to e.g. a cache managment application?
> >> >>>
> >> >>> Can you clarify the use case?  Who owns/manages the cache
> >> >>> management application?  Is it the same person as the DECADE
> >> >>> server?  Is it the same person as the DECADE client?
> >> >>
> >> that just want to put data objects in it's 'local' DECADE storage and
> >> then want the network provider to populate other DECADE servers to
> >> provide a flexible CDN like functionality for the published objects.
> >> >>
> >> >
> >> > If you wanted to short-circuit this case by having the client not
> >> > give the tokens (since presumably the network provider owns the
> >> > DECADE servers and could replicate objects using some mechanism
> >> > other than DECADE), then that would be fine too - but that seems a
> >> > bit too specialized of a use case for this document.
> >> >
> >> >>>> 7.1 §5
> >> >>>> It states "Though explicitly supplying these may provide
> >> >>>> additional
> >> freedom,
> >> >>>> It is unclear what the "they" refers to. I have problems
> >> >>>> understanding the meaning of this sentence.
> >> >>>
> >> >>> example, a typical (normal) use case might be to request to
> >> >>> download object 1 from Server A, but indicating that it must
> >> >>> fetch object 1 from Server B first.  Extending that slightly, I
> >> >>> could imagine constructing protocol messages to request to
> >> >>> download object 1 from Server A, but indicating it must fetch object 2
> from Server B first.
> >> >>>> It states "In the case of a GET operation, the DECADE server is
> >> >>>> to retrieve the data object from the remote server using the
> >> >>>> specified credentials (via a GET request to the remote server),
> >> >>>> and then return the object to the client."
> >> >>>> Why should the object be returned to the client? If this is just
> >> >>>> about cache management there is no reason to return the object to
> the client.
> >> >>>
> >> >>> No - it is not only about cache management. The client may not
> >> >>> have the object yet. However, that said, I might imagine cases
> >> >>> where the last step (downloading to the client itself) is
> >> >>> optional, e.g., if it wishes to delay downloading it over the
> >> >>> last mile for later.  We should add a note saying that it is optional.
> >> >>
> >> >> Fine.
> >> >>
> >> >>>
> >> >>>> Further it states: "In the case of a PUT operation, the DECADE
> >> >>>> server is to store the object from the client..." This sounds
> >> >>>> like the client making this PUT I thought this was about server to
> server communication.
> >> >>>
> >> >>> Similarly, we should add a note here saying that the upload from
> >> >>> the client to its own server is optional (the object may already
> >> >>> exist at one server, and the client may want it replicated to another
> server).
> >> >>
> >> >> Ok.
> >> >>
> >> >>>
> >> >>>> Also should not
> >> >>> protocols to support operations directly between servers", and
> >> >>> these were mentioned in Section 6.  Should we explicitly mention
> >> >>> that such attributes can also be configured on requests involving
> >> >>>> It states "A DECADE server may choose to not fully store an
> >> >>>> object before beginning to serve it." The 'may choose' is not
> >> >>>> consistent with the MUST requierment to be able to deliver before
> fully stored.
> >> >>>
> >> >>>  "A server MUST accept download requests for an object that is
> >> >>> still being uploaded."
> >> >>
> >> >> yes.
> >> >>
> >> >>>
> >> >>> That should indeed be a MAY to be consistent with the
> >> >>> requirements draft.  Objections?
> >> >>
> >> >> ok.
> >> >>
> >> >>
> >> >>
> >> >

---

From: Richard Alimi <[email-masked]>
Date: Fri, 21 Oct 2011 08:25:50 -0700

> IMO, in DECADE, we should leave it to the client only, otherwise the fundamental use case (application endpoint uploads named object, refers other endpoints to the objects using the name and author…

The way I read his suggestion was that there is the option of the
server generating the name.  Put another way, the client still has
capability to generate the name (and the server may verify), but the
client could also be lazy and accept the security consequences.  I
completely agree that we don't want to require the server to generate
the name.

> For example, what if the server uses a hash algorithm that is not useful in an application context? What about compromised servers that give you a name that is not bound to the object etc?

I agree with your concerns, and those are the ones that would need to
be called out if we were to add something for this.

> I would prefer a clear separation of concerns: application endpoint create and name objects, DECADE servers distribute and host named objects.

That is a good point.  Maybe one possibility is to have the base
protocol without this capability, and then have an extension to handle
clients that for some-reason can't or don't want to compute a hash?

Rich

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Oct 2011 14:42:49 -0400

Hi Rich,

The one other point to consider is that in Fig. 1 and in the text we allow DECADE protocols (DRP/SDT) to run between servers only (without any clients involved).  So in that case do we still want to prohibit the server from performing the naming?

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Alimi
Sent: Friday, October 21, 2011 11:26 AM
To: Dirk Kutscher
Cc: decade ietf
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03

Rich

---

From: Richard Alimi <[email-masked]>
Date: Fri, 21 Oct 2011 13:29:39 -0700

> The one other point to consider is that in Fig. 1 and in the text we allow DECADE protocols (DRP/SDT) to run between servers only (without any clients involved).  So in that case do we still want t…

Well, whichever server has the object should already know the name
(either because it got it from the client and validated it, or because
it generated it).  The server receiving the object would then
presumably validate what it got.  So in short, the one sending an
object in the 'write' request should supply the name.

I agree that when writing this text, we need to be careful how it is
worded so we don't have issues in the server<->server case.

Thanks,
Rich

---

From: "Mcdysan, David E" <[email-masked]>
Date: Fri, 21 Oct 2011 16:38:59 -0400

I looked over the revised draft and my major review comments were addressed.

Thanks,

Dave

From: "Woundy, Richard" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 29 Sep 2011 08:13:56 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [decade] Start of WGLC for draft-ietf-decade-arch-03

Folks,

Thanks.

-- Rich and Haibin

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 21 Oct 2011 17:09:37 -0400

Hi Rich,

Exactly. The key point is that the sender generates the name. And the sender can be either a client or a server. I think that is how we should re-word it to be.

Akbar

-----Original Message-----
From: Richard Alimi [[email-masked]]
Sent: Friday, October 21, 2011 04:30 PM Eastern Standard Time
To: Rahman, Akbar
Cc: decade ietf; Dirk Kutscher; Börje Ohlman
Subject: Re: [decade] Start of WGLC for draft-ietf-decade-arch-03

Thanks,
Rich

---

From: Börje Ohlman <[email-masked]>
Date: Sat, 22 Oct 2011 07:53:10 +0200

I'ld be fine with this.

Börje

On 21 okt 2011, at 17.25, Richard Alimi wrote:

Rich

---

From: YR Yang <[email-masked]>
Date: Sat, 22 Oct 2011 15:36:20 -0400

> might be done as extensions at a later time too.

The deletion is an interesting discussion. One thing coming to mind is if we enforce a default TTL, or a maximum TTL. In other words, we make the whole storage soft state. Unless refreshed, data will be deleted by default. Otherwise, if the TTL is infinity, should the data be always there?

Richard

---

From: Richard Alimi <[email-masked]>
Date: Sat, 22 Oct 2011 15:45:44 -0700

> The deletion is an interesting discussion. One thing coming to mind is if we enforce a default TTL, or a maximum TTL. In other words, we make the whole storage soft state. Unless refreshed, data wi…

If DECADE storage is user-controlled, is there a reason that a default
TTL should be used by the server?  I would tend to think this would be
a client-side decision (maybe an implementation-specific default).  I
think one concern I would have is that it would limit the application
of DECADE to applications that are able to be running often enough to
actually refresh data (what if the user/owner goes away on vacation
and turns off the computer at home?), or have data that is only
short-lived (e.g., live streaming).

Thanks,
Rich

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 22 Oct 2011 19:51:46 -0400

On 10/22/11 6:45 PM, Richard Alimi wrote:
> On Sat, Oct 22, 2011 at 12:36 PM, YR Yang<[email-masked]>  wrote:
>>
>> On Oct 21, 2011, at 12:30 AM, Richard Alimi<[email-masked]>  wrote:
>>
>>> On Thu, Oct 20, 2011 at 7:26 PM, Songhaibin<[email-masked]>  wrote:
>>>>
>>>>> On Fri, Oct 14, 2011 at 4:11 AM, Börje Ohlman<[email-masked]>
>>>>> wrote:
>>>>>> Hi,
Default is less an issue, but allowing a very large maximum could be an 
issue. I like
your example of going vacation (say an around-the-globe-one-year one :-).
Should the user still anticipate that the data be available after the 
user is
back? If it is a persistent storage system, say S3/Dropbox, I think the 
user should.
But for a content distribution storage system, should it be? We can 
assume that
the user still pays the bill during the vacation. Or maximum TTL is a 
policy issue
that can be discovered... What do you think?

Richard

---

From: Songhaibin <[email-masked]>
Date: Mon, 24 Oct 2011 00:48:03 +0000

> From: Dirk Kutscher [mailto:[email-masked]]
> Sent: Friday, October 21, 2011 11:10 PM
> To: Richard Alimi; Songhaibin
> Cc: decade ietf
> Subject: RE: [decade] Start of WGLC for draft-ietf-decade-arch-03
> 
> Hi all,
> 
> Yes, right -- there is no way for the client to negotiate this with or request this
> from the server, so just requiring the capability will not help.
> 
> I'd say this could really be an implementation-specific decision. Some servers
> might be able to do it, others not. If you want to provide DECADE for
> download-based services only, you would not really need it.
> 

I would like to give one use case. A streaming application provider (DECADE client) may explicitly tell the DECADE server to serve its streaming data to the application clients (with embedded DECADE clients) before the upload is finished. The server is not configured, but is told to do this trough a message. Does it make sense?

BR,
-Haibin (as individual)

---

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 09:05:10 -0700

On Sat, Oct 22, 2011 at 4:51 PM, Y. Richard Yang <[email-masked]> wrote:
>>>>>> Behalf Of
>>>>> I think imposing some intelligent data deletion mechanism will make the
>>>>> design complicated. But TTL should be okay. Shall we leave them to the
>>>>> applications to implement and make DECADE design as simple as possible?
>>>>>
>>> The deletion is an interesting discussion. One thing coming to mind is if
>>> we enforce a default TTL, or a maximum TTL. In other words, we make the
>>> whole storage soft state. Unless refreshed, data will be deleted by default.
>>> Otherwise, if the TTL is infinity, should the data be always there?
>>>
> Should the user still anticipate that the data be available after the user
> is
> back? If it is a persistent storage system, say S3/Dropbox, I think the user
> should.
> But for a content distribution storage system, should it be?

Well, one thing that comes to mind is a DVR-type usage pattern. I have
programs on my DVR from April that I still haven't watched yet, but
still would like to (as long as I'm still paying my cable bill) :)  In
the DECADE use case, I might be storing some content at the server so
I could view it while I'm traveling without requiring a computer at
home to be on.

> We can assume
> that
> the user still pays the bill during the vacation. Or maximum TTL is a policy
> issue

Having it as a policy that can be discovered I think would be a good
idea (with one of the possible settings being infinity :) ).

Bringing this back to the architecture document, would it be fair to
say that we a DECADE server should be able to communicate storage
policies to clients (e.g., maximum TTL)?  Objections from anyone?

Thanks,
Rich

>>>>>> http://datatracker.ietf.org/doc/draft-ietf-decade-req
>>>>>> s/,
>>>>>>>

---

From: Richard Alimi <[email-masked]>
Date: Mon, 24 Oct 2011 09:09:37 -0700

> I would like to give one use case. A streaming application provider (DECADE client) may explicitly tell the DECADE server to serve its streaming data to the application clients (with embedded DECAD…

Well, a couple of things here:
(1) How does the client tell the server to enable this capability?
Are you proposing a new client->server configuration service within
DECADE?
(2) Even if we had (1), I would think a simpler design would be for
the client to just tell the server what it needs when it opens a
session (in this case it would include the option saying "please allow
downloading before the upload is finished").  The server then has the
option to say "sorry, I can't do that" or "sure, go right ahead".
(This is much more similar to the typical negotiation we see in HTTP,
and we still don't have to distinguish between the case of the server
not supporting it, and the server supporting it and it not being
enabled).

Thanks,
Rich

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Tue, 25 Oct 2011 09:37:14 +0800

Let me try to follow this discussion.

So, for now, we tend to allow the DECADE server deploy a default TTL for each application from a client(the client can have more than one applications running at the same time). And DECADE server can communicate with DECADE client to decide the TTL value(i.e. the storage policies in your emails). 

Well, as far as I am concerned, I would say this is a good feature to have. The DECADE server can communicate with DECADE client to decide the access policies(i.e. access control in the draft)  and resource policies(i.e. resource control in the draft) already. 

Best Regards
Gu Yingjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Richard Alimi
发送时间: 2011年10月25日 乐乐0:05
收件人: Y. Richard Yang
抄送: decade ietf
主题: Re: [decade] Start of WGLC for draft-ietf-decade-reqs-04

Thanks,
Rich

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 28 Oct 2011 16:35:06 +0000

I would like to move forward with draft-ietf-decade-reqs-04, and incorporate the comments received from WGLC. Many thanks to Akbar Rahman, Börje Ohlman, and Haibin Song for their comments on the draft!

Authors, please note that the submission deadline is Monday October 31 at 17:00 PT (00:00 UTC). Let's post a -05 version if at all possible for discussion at IETF 82 in Taipei.

-- Rich

P.S. Let's also remember to fix "Boerje Ohlman" in the Acknowledgments section.

From: Woundy, Richard
Sent: Tuesday, October 11, 2011 10:19 AM
To: [email-masked]
Cc: Songhaibin; Woundy, Richard
Subject: RE: Start of WGLC for draft-ietf-decade-reqs-04

-- Rich

From: Woundy, Richard

Folks,

Thanks.

-- Rich and Haibin

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 28 Oct 2011 16:44:27 +0000

I would like to move forward with draft-ietf-decade-arch-03, and incorporate the comments received from WGLC. Many thanks to Börje Ohlman, Dave McDysan, and Ning Zong for their comments on the draft!

Authors, please note that the submission deadline is Monday October 31 at 17:00 PT (00:00 UTC). Let's post a -04 version if at all possible for discussion at IETF 82 in Taipei.

-- Rich

P.S. The authors might want to add an Acknowledgments section. :)

From: Woundy, Richard
Sent: Tuesday, October 11, 2011 10:22 AM
To: [email-masked]
Cc: Songhaibin; Woundy, Richard
Subject: RE: Start of WGLC for draft-ietf-decade-arch-03

-- Rich

From: Woundy, Richard

Folks,

Thanks.

-- Rich and Haibin