<div dir="ltr"><div>Hi Zhiyi</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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?</div></div></blockquote><div><br></div><div>Having a segment component is future proof: the information in a CA profile may exceed the optimal size of one segment.</div><div><a href="https://redmine.named-data.net/projects/ndn-tlv/wiki/RDR" target="_blank">RDR</a> metadata has a segment component for the same reason.</div></div></div></blockquote><div><br></div><div>but why not simply set a final block id in /<ca-prefix>/CA/INFO/version so that the requester can fetch more back?</div><div>we can omit the segment component for the first segment?</div></div></div></blockquote><div><br></div><div>Not having segment component on the first segment increases complexity, both in fetch logic and in trust schema.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>TLV evolvability guidelines should be followed by default, unless there's a reason to opt out of TLV evolvability guidelines.</div></div></div></blockquote><div><br></div><div>Hmm. I didn't see the reasons why NDNCERT needs to follow the evolvability.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div></div></blockquote><div><br></div><div>There are two options.</div><div><br></div><div>First option is to include TLV-TYPE number for each item as part of the CA profile.</div><div>The CA profile could say:</div><div><font face="monospace"><ProbeDefinitions></font></div><div><div><font face="monospace">  <DescriptionEntry></font></div><div><font face="monospace">    <DescriptionKey>email</DescriptionKey></font></div><div><font face="monospace">    <DescriptionValue>1243</DescriptionValue></font></div><div><font face="monospace">  </DescriptionEntry></font></div><div></div></div><div><font face="monospace">  <DescriptionEntry></font></div><div><font face="monospace">    <DescriptionKey>full name</DescriptionKey></font></div><div><font face="monospace">    <DescriptionValue>3186</DescriptionValue></font></div><div><font face="monospace">  </DescriptionEntry></font></div><div></div><div><font face="monospace"><ProbeDefinitions></font></div><div><div></div></div><div>This tells the requester what TLV-TYPE numbers to use.<br></div><div>The requester can then send:</div><div><font face="monospace"><ProbeParameters></font></div><div><font face="monospace">  <1243><a href="mailto:david.henson@contoso.com" target="_blank">david.henson@contoso.com</a></1243></font></div><div><font face="monospace">  <3186>David Henson</3186></font></div><div><font face="monospace"></ProbeParameters></font></div><div><br></div><div>Second option is to use DescriptionEntry structure in the PROBE Interest packet.</div><div><div><font face="monospace"><ProbeParameters></font></div><div><div><font face="monospace">  <DescriptionEntry></font></div><div><font face="monospace">    <DescriptionKey>email</DescriptionKey></font></div><div><font face="monospace">    <DescriptionValue><a href="mailto:david.henson@contoso.com" target="_blank">david.henson@contoso.com</a></DescriptionValue></font></div><div><font face="monospace">  </DescriptionEntry></font></div><div></div></div><div><font face="monospace">  <DescriptionEntry></font></div><div><font face="monospace">    <DescriptionKey>full name</DescriptionKey></font></div><div><font face="monospace">    <DescriptionValue>David Henson</DescriptionValue></font></div><div><font face="monospace">  </DescriptionEntry></font></div><div><font face="monospace"></ProbeParameters></font></div><div></div></div><div><br></div><div>Comparing these two options:</div><div><ul><li>First option makes PROBE Interest packet smaller.</li><li>Second option has less complexity in terms of binary code size.</li></ul></div></div></div></blockquote><div><br></div><div>Another possible solution is:</div><div>T:probe-parameter, L, V: first probe parameter</div><div>T:probe-parameter, L, V: second probe parameter</div><div>...</div><div>The value of probe parameters is listed in the same order as defined in CA profile.</div></div></div></blockquote><div><br></div><div>This is less flexible: what if a particular parameter is optional or repeatable?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Should the value type be defined also? if the value can be a string, an integer, or bytes.</div></div></div></blockquote><div><br></div><div>The CA profile could specify the value type. However, I'd suggest starting with strings only.</div><div>Other types can be specified through <a href="https://tools.ietf.org/html/rfc8610">CDDL</a> or similar.</div><div><br></div><div>Yours, Junxiao </div></div></div>