Re: [decade] Merge requirements documents?

[Richard Alimi <[e-mail]>]

Hi Ove,

We need to be careful to stay in the charter here.  The charter states:

  .. the WG will
  identify target applications to appropriately scope the problem and
  requirements. P2P applications are the primary target, but suitability
  to other applications with similar requirements may be considered
  depending on additional complexity required to support such
  applications.

The chartered work isn't "complementary" scenarios, but rather ones
with similar requirements.  In my opinion, the "do no harm" tenet can
be a good guidance to see if a particular application has similar
enough requirements.

In any case, if additional requirements are indeed being considered, I
think we need to have something concrete (e.g., a particular
application in use today).  That will tell us whether we're
approaching something with similar requirements to supporting a P2P
application, and where there might be differences in the requirements.

Rich

On Fri, Jun 11, 2010 at 3:47 AM, Strandberg, Ove (NSN - FI/Espoo)
<[e-mail]> wrote:
> Hi David,
>
> I think that one main reason for difference in opinion between us David is the basic approach and view of DECADE. You clearly think mostly about P2P application scenario. I on the other hand think that when we specify a protocol for network storage / cache (usually from an client perspective) we should make sure the same network storage / cache protocol can be used for other application scenarios too. I fully support the P2P scenario, but the effort to make the broader applicability possible, should be well worth spending. Basically it would IMHO be good for us to make the protocol more succeful. Agreed that the scope needs to be narrow enough, however if you like to look at P2P, I would be happy look after complementary scenarios ;-) However to be able to achieve this I hope that these additional requirements should be included. I am sure we will together make sure that we do not make complex recommendations in the end ;-)
>
> Br,
>
> +Ove
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On
>>Behalf Of ext David A. Bryan
>>Sent: 07 June, 2010 22:58
>>To: Strandberg, Ove (NSN - FI/Espoo)
>>Cc: [e-mail]
>>Subject: Re: [decade] Merge requirements documents?
>>
>>I actually remember things a bit differently at the meeting,
>>with my general sense being that there wasn't broad support
>>for most of the new requirements. At least for now (perhaps I
>>don't understand the rational fully), I personally don't see a
>>need to include any of them, with the exception of application
>>agnostic (in the modified form below, which isn't a
>>requirement but a guiding principal).
>>
>>I think that the mobility requirement needed more discussion
>>-- most folks seemed to feel that it was a bit too complex for
>>now, and personally, I didn't really understand the problem
>>this would address.
>>A very simplistic description of the major chartered use case
>>of DECADE is to allow a peer to make things available
>>in-network so that others can obtain it without having to use
>>the link to the peer itself. In my view, it isn't intended to
>>be generic storage for the user to place things that they want
>>to be able to access easily themselves. While having storage
>>near me topologically might reduce the cost of putting it in
>>the data locker in the first place, I don't really see how
>>mobility is very critical when the major purpose is to allow
>>me to place something in the network for someone else to obtain.
>>I may just not quite understand what you are advocating -- can
>>you clarify a use case where we need this for the main P2P application?
>>
>>Data reuse is something that I simply see as an implementation issue.
>>Obviously, a given implementation might choose to compare
>>copies of data that it is storing and to consolidate them, but
>>from a protocol/network perspective, I think we are adding
>>complexity if we track versions, number of copies stored, who
>>has shared which access rights, etc. -- so much so that it
>>seems unlikely to justify the cost.
>>My preference would be that a user has access to their locker,
>>and can place things in it, provide references to it, etc.,
>>but that each user's data -- at least from the perspective of
>>the protocol -- is unique and managed by them. Again, as I
>>said, that wouldn't preclude an implementation from making
>>this optimization, I just don't see requirement/protocol
>>design as the right place for it.
>>
>>Finally, my take on the application technique issue at the meeting was
>>this: In P2PSIP, we tried a "do no harm" approach. The
>>protocol for P2PSIP (RELOAD) is essentially a DHT protocol.
>>The protocol is optimized for use in SIP
>>registration/location, and we agreed that we wouldn't add
>>unnecessary complexity that wasn't needed by that one
>>application. That said, we have tried very hard (and
>>deliberately) to make sure that so long as it didn't increase
>>complexity, that we thought about other applications and tried
>>not to design RELOAD in a way that would preclude use for
>>other applications. I'd like a similar approach here -- we
>>deliberately design for the single application of storing
>>information for P2P applications, but if others can point out
>>other applications that dictate a design decision and
>>(critically) which do not add complexity/require new features,
>>we try to make design decisions that allow that flexibility
>>when possible. I see this as quite different from adding
>>different application scenarios and requiring that the
>>protocol support all of them -- that is, in my opinion, likely
>>to make this problem too broad and increase the difficulty of
>>designing a protocol.
>>
>>David
>>
>>
>>On Fri, Jun 4, 2010 at 3:14 AM, Strandberg, Ove (NSN -
>>FI/Espoo) <[e-mail]> wrote:
>>> Dear Decade email list,
>>>
>>> There were additional requirements identified for Decade that was
>>> presented and discussed in the Anaheim IETF meeting (see minutes in
>>> http://www.ietf.org/proceedings/10mar/minutes/decade.html). We
>>> basically brought some few additional requirements to complement the
>>> already nice requirement list in draft-gu-decade-reqs-04.
>>The authors
>>> of the draft-ohlman-decade-add-use-cases-reqs-00 draft would like to
>>> suggest that the additional requirements could be incorporated into
>>> one
>>>
>>> requirement document, albeit into the draft-gu-decade-reqs-04 draft.
>>> The two first requirements "application agnostic" and "data reuse"
>>> seemed to be well received, while the "mobility" requirement needs
>>> further discussion. What do the authors of
>>draft-gu-decade-reqs-04 think about this merge proposal?
>>>
>>> We would like to also ask the DECADE email list to make comments on
>>> the suggestion to combine both drafts into one document. Is this an
>>> acceptable way forward?
>>>
>>> Br,
>>>
>>> +Ove
>>>
>>> [e-mail]
>>>
>>> _______________________________________________
>>> decade mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/decade
>>>
>>>
>>
> _______________________________________________
> decade mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/decade
>