Re: [decade] Merge requirements documents?

["David A. Bryan" <[e-mail]>]

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
>
>