Subject: [decade] Fwd: [yale_lans] Decade naming req

From: Haiwei Xue <[email-masked]>
Date: Mon, 2 Jul 2012 23:58:55 -0400

Dear list

The follows are my comments on the split of req's related with naming in
-req and -arch.

Thanks.

---------- Forwarded message ----------
From: Haiwei Xue <[email-masked]>
Date: Mon, Jul 2, 2012 at 5:04 PM
Subject: Re: [yale_lans] Decade naming req
To: [email-masked]
Cc: Ning Zong <[email-masked]>

Hi Richard,

I have dug out all the naming requirements in the two documents:

In -req:

R1. DECADE-compatible protocol must support naming scheme.

R2. Naming scheme should keep uniqueness.

R3. Naming operations on diverse DECADE-compatible servers should have no
coordination.

R4. Naming scheme should provide collision handling mechanism.

R5. DECADE-compatible server SHOULD be able to give a respond to
DECADE-compatible client to indicate the result of naming operation.

In -arch

A1. Should be able to validate Name-object binding

A2. Should support different binding validation

A3. Content Distribution Applications can decide which validation to use.

A4. App. can be able to construct unique names without coordination.

A5. Names should be self-describing.

A6. Names should be Uniqueness

A7. Names should be Flexibility.

A8. Naming scheme SHOULD provide the (following) elements

A8-1. A "type" field that indicates the name-object validation
function type.

A8-2. Cryptographic data (such as an object hash) that corresponds to the
type information

A8-3. Application or publisher information.

A9. Should make object visible in the namespace as soon as they are created
(not closed)

A10. Not sure yet. ( I don't fully understand the last paragraph of Sec.4.4
in -arch. )

Base on these requirements. I would like to give the following comments:

1. A1, A2, A3 are talking about the same quesion: validation. I think A1
and A2 are more general, A3 is somehow in detail, So How about move A1 and
A2 to -req.

2. R3, A4 are talking naming should independent without coordination of
servers or applications. I would like to merge the two requirements move
put it into -req.

3. A5, A6 and A7 are more general, so it may be better to move them to -req.

4. A8, A8-1,  A8-2 and A8-3 are talking about elements in naming 'field'.
These requirements may stay in -arch, and I don't think it is essential to
mention 'elements' in -req, because everybody know that naming scheme
should provide some 'elements ' to carry on some specific information.

5. A9 is general, and it is better to move it to -req.

6. R1-5 are good I think, you can leave them in -req. But you may need
merge some of them with requirements in -arch. E.g. R2 can merger with A6.

BTW: I like the way you call the naming problem: name-object binding. But
the term 'name-object binding' are first appeared in -arch. I think it may
be better to give a clear definition of naming problem by using
'name-object binding'.

Thanks.

Haiwei

On Mon, Jul 2, 2012 at 10:26 AM, Y. Richard Yang <[email-masked]> wrote:

> Hi Haiwei, Peng,
>
> Are you able to help with the split of req's related with naming in -req
> and -arch? General reqs should be in -req (before design), and specific
> reqs in -arch as they depend on a particular arch. What do you think?n
>
> Can you send out a proposal by Tuesday?
>
> Thanks!
>
> Richard
>