[Nfd-dev] Update on NDNCERT protocol

[Junxiao Shi]

Hi Zhiyi


>> 1. sec 2.1.2 why we need version + segment components? I understand the
>>> use of version component but why bother segment component? What's the
>>> benefit of using these two rather than timestamp?
>>>
>>
>> Having a segment component is future proof: the information in a CA
>> profile may exceed the optimal size of one segment.
>> RDR <https://redmine.named-data.net/projects/ndn-tlv/wiki/RDR> metadata
>> has a segment component for the same reason.
>>
>
> but why not simply set a final block id in /<ca-prefix>/CA/INFO/version so
> that the requester can fetch more back?
> we can omit the segment component for the first segment?
>

Not having segment component on the first segment increases complexity,
both in fetch logic and in trust schema.
I would suppose the /<ca-prefix>/CA/INFO prefix to be published by a repo
controlled by the CA. Then, the requester can discover the latest version
of CA profile using RDR protocol, then retrieve it with SegmentFetcher.

3. sec 2.1.4 do we need to consider the evolvability here? given it's an
>>> application layer protocol and all fields clearly defined.
>>>
>>
>> TLV evolvability guidelines should be followed by default, unless there's
>> a reason to opt out of TLV evolvability guidelines.
>>
>
> Hmm. I didn't see the reasons why NDNCERT needs to follow the evolvability.
>

It's the opposite. If you do not see a reason why a particular protocol
should opt out of TLV evolvability guidelines, the default is to follow TLV
evolvability guidelines.


>
>>
>>
>>> 4. sec 2.2.2 you suggested the type name be email and full name, do you
>>> expect them to be pre-defined as TLV types? If so, it's really a usability
>>> issue because different CAs may require totally different information for
>>> the probe.
>>>
>>
>> There are two options.
>>
>> First option is to include TLV-TYPE number for each item as part of the
>> CA profile.
>> The CA profile could say:
>> <ProbeDefinitions>
>>   <DescriptionEntry>
>>     <DescriptionKey>email</DescriptionKey>
>>     <DescriptionValue>1243</DescriptionValue>
>>   </DescriptionEntry>
>>   <DescriptionEntry>
>>     <DescriptionKey>full name</DescriptionKey>
>>     <DescriptionValue>3186</DescriptionValue>
>>   </DescriptionEntry>
>> <ProbeDefinitions>
>> This tells the requester what TLV-TYPE numbers to use.
>> The requester can then send:
>> <ProbeParameters>
>>   <1243>david.henson at contoso.com</1243>
>>   <3186>David Henson</3186>
>> </ProbeParameters>
>>
>> Second option is to use DescriptionEntry structure in the PROBE Interest
>> packet.
>> <ProbeParameters>
>>   <DescriptionEntry>
>>     <DescriptionKey>email</DescriptionKey>
>>     <DescriptionValue>david.henson at contoso.com</DescriptionValue>
>>   </DescriptionEntry>
>>   <DescriptionEntry>
>>     <DescriptionKey>full name</DescriptionKey>
>>     <DescriptionValue>David Henson</DescriptionValue>
>>   </DescriptionEntry>
>> </ProbeParameters>
>>
>> Comparing these two options:
>>
>>    - First option makes PROBE Interest packet smaller.
>>    - Second option has less complexity in terms of binary code size.
>>
>>
> Another possible solution is:
> T:probe-parameter, L, V: first probe parameter
> T:probe-parameter, L, V: second probe parameter
> ...
> The value of probe parameters is listed in the same order as defined in CA
> profile.
>

This is less flexible: what if a particular parameter is optional or
repeatable?

Should the value type be defined also? if the value can be a string, an
> integer, or bytes.
>

The CA profile could specify the value type. However, I'd suggest starting
with strings only.
Other types can be specified through CDDL
<https://tools.ietf.org/html/rfc8610> or similar.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20200303/63c4feb2/attachment-0001.html>