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

[Stephen Farrell <[e-mail]>]

On 07/04/2012 09:05 PM, Zhang Peng wrote:
> Hi Stephen,
> 
> I have read your documents on hash-based naming. It designs a good URI format and mapping scheme to HTTP URL. For DECADE, since our requirements include uniqueness, name-object binding validation, I wonder how we can apply your scheme to meet them. 

ni URIs are as unique as the collision resistance of your hash
function supports basically. If you pick sha-256 that won't be
an issue.

ni URis support name-data integrity (incl. in the code we've
released) which I think is the same as what you're calling
name-object binding validation.

So my answer for both is: just use ni URIs to meet these
requirements:-)

> BTW, can you give more details on what you mean by "meets these requirements"? Thanks.

I meant: if there's some requirement that can't be met using ni URIs,
then I'd like to know about that before its too late. (I realise
that the decade WG might still change reqs of course but wanted to
check now before we're done with our doc.)

S

> B,
> 
> Peng.
> 
> From: Stephen Farrell
> Date: 2012-07-03 03:26
> To: pzhang.thu
> CC: [e-mail]
> Subject: Re: [decade] Object naming in -req and -arch
> 
> 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.