Re: [decade] Object naming in -req and -arch

[Stephen Farrell <[e-mail]>]

Hiya,

I guess I hope that our draft (just exited IETF LC) meets
these requirements. If not, I'd be interested in what's
missing.

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-decade-ni

On 07/03/2012 06:34 AM, Zhang Peng wrote:
> Dear DECADE participants,
> 
> As pointed out by Richard in previous discussions, both the -req and -arch documents has some paragraphs describing content naming, and they need better organization: some generic requirements should be in -req, while some more specific ones should be in -arch. Here are some suggestions about how to split the content on naming in these two documents. 
> 
> The rationale for the following split is that I recognize there are two generic requirements, that is, uniqueness, and binding validation. They should be placed in the -req. In -arch, we should present the specific requirements to enable uniqueness, and binding validation, respectively. There are also some more requirements on how to improve the responsiveness of the system, i.e., the support of early name generation. See below for details (references to the original documents are given after each specific requirements):
> 
> Generic requirements (to be put in -req)
> 
> 1. It SHOULD ensure that uniqueness of object names. 
> 2. It SHOULD support the validation of name-object binding.
> 3. It SHOULD support the operation of DECADE-compatible servers under diverse administrative domains with no coordination. (not sure about what operations are meant here)
> 
> Specific requirements (to be put in -arch)
> 
> Requirements to enable uniqueness: 
> 1. It MAY enable applications to construct unique names by themselves with a high probability (ref: last sentence, pp. 11, -arch). If this is the case, it SHOULD indicate conflicts when duplicate names are constructed (ref: first para, 4.5.1, -req).
> 2. It MAY support content-dependent hash-based schemes (for general immutable objects), and content-independent enumeration-based schemes (for live streaming) 
> (ref: 2nd para, pp. 12, -arch)
> 
> Requirements to enable name-object binding validation:
> 3. Different name-object binding validation mechanisms MAY be supported, and an application can decide which mechanism to use. (ref: 2nd para, 4.4, -arch)
> 4. Names MAY be self-describing so that a receiving entity (Content Consumer) knows which mechanism is used (ref: 1st para, pp. 12, -arch)
> 5. It SHOULD provide the following name elements: (1) A "type" field, (2) Cryptographic data, (3) Application or publisher information. (ref: pp. 12, -arch)
> 
> More requirements about performance:
> 6. It SHOULD support the scenarios where a client needs to know the name of a data object before it is completely stored at the server. (This is to let clients advertise the object before having fully uploaded it) (ref: second last para, pp. 12, -arch)
> 7. It SHOULD support the scenarios where a client need to know the name of a data object before it is locally created. (This is to support live streaming) (ref: last para, pp. 12, -arch)
> 
> Any comments are welcome, thanks.
> 
> Peng.
>