<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 dir="auto"><div><span style="text-align:center">Anyway, I've tested the service.</span></div><div><span style="text-align:center">CA profile retrieval is working now.</span></div><div><span style="text-align:center"><br></span></div><div><span style="text-align:center">However, the NewResponse packet is encoded incorrectly - it contains an unrecognized TLV element of critical type 0x9B.</span></div><div><span style="text-align:center">Packet capture is attached.<br></span></div><div><span style="text-align:center"><br></span></div><div><span style="text-align:center">I can see that the offending line is here:</span></div><div><span style="text-align:center"><a href="https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L91" target="_blank">https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L91</a></span></div><div><span style="text-align:center">The protocol doesn't have a Status field in this packet:</span></div><div><span style="text-align:center"><a href="https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3/0d11d48d9ebee022eee71dee14f1342e0905a620#232-packet-format" target="_blank">https://github.com/named-data/ndncert/wiki/NDNCERT-Protocol-0.3/0d11d48d9ebee022eee71dee14f1342e0905a620#232-packet-format</a></span></div></div></div></blockquote><div><br></div><div>I remembered we have this status field in the original doc. I guess it was removed in later edits.</div><div>Anyway, do you think we should have this field in the NEW Data packet to indicate the current status?</div></div></div></blockquote><div><br></div><div>What are the possible values for the Status field in NewResponse? If there's only one possible value, it's unnecessary to include this field.</div><div>Note that error conditions would cause the CA to generate an ErrorMsg packet instead of NewResponse.</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 dir="auto"><div dir="auto"><span style="text-align:center"><br></span></div><div><span style="text-align:center">Your decoding function is not implementing TLV evolvability correctly.</span></div><div><span style="text-align:center">
</span><div><span style="text-align:center"><a href="https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L102" target="_blank">https://github.com/Zhiyi-Zhang/ndncert/blob/cac27f1128883096c803d70b3c6d2cab50e1cd10/src/detail/new-renew-revoke-encoder.cpp#L102</a></span></div><div><span style="text-align:center"></span></div>

<span style="text-align:center">If it encounters an unrecognized or out-of-order field of a critical TLV-TYPE. However, the current decoding function would erroneously accept any unrecognized or out-of-order fields of critical TLV-TYPEs.<br></span></div><div><span style="text-align:center">All new NDN software is expected to 
properly implement TLV evolvability. Please see ndn::Interest type in ndn-cxx for an example.<br></span></div></div></div></blockquote><div><br></div><div>Okay. BTW, should there be some helper functions from NDN libraries to help with this?</div><div>I feel it's not very developer-friendly considering the alternatives like JSON.</div><div>Compared with forwarder development, maybe we should relax this requirement for application development?</div></div></div></blockquote><div><br></div><div>Yes, this functionality should ideally come from the library.</div><div>Two of my three libraries have <b>evolution-aware decoder</b> functionality. See code samples here:</div><div><a href="https://github.com/yoursunny/NDNts/tree/a42b94a793e479aaeac163bec8d30e328875ea58/packages/tlv#evdecoder">https://github.com/yoursunny/NDNts/tree/a42b94a793e479aaeac163bec8d30e328875ea58/packages/tlv#evdecoder</a><br></div><div><a href="https://github.com/yoursunny/NDNph/blob/10e1b0ea77af890a0d7b8453060529924b7dadc8/src/ndnph/packet/interest.hpp#L412-L436">https://github.com/yoursunny/NDNph/blob/10e1b0ea77af890a0d7b8453060529924b7dadc8/src/ndnph/packet/interest.hpp#L412-L436</a><br></div><div>You can either ask the library maintainer of other libraries to add this feature, or switch to one of my libraries.</div><div><br></div><div>Nevertheless, it is your responsibility as application maintainer to ensure the evolvability guidelines are in the application, especially for NDNCERT that is a critical part of the NDN testbed infrastructure.</div><div><br></div><div>Yours, Junxiao</div></div></div>