<div dir="ltr">Hi Christian<div><br></div><div>20150608 NFD call decides to take two of your suggestions.</div><div><br></div><div><font size="4">NdnlpHeader wrapper</font></div><div>NdnlpHeader wrapper is eliminated.</div><div>Instead, header fields are placed directly under LpPacket element.</div><div>TLV-TYPE codes [81:99] and [800:959] are reserved for header fields, and [960:999] are reserved for trailer fields.</div><div><br></div><div><font size="4">Unknown Fields</font></div><div>I have adopted the idea in <a href="http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html">http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html</a></div><div>When an unknown header field appears, if its TLV-TYPE is within [800:959] range, the least significant bit determines whether to drop the packet or ignore the field. For [81:99] range, the only action is to drop the packet.</div><div><br></div><div><br></div><div>The protocol document has been updated to reflect the above (and other) changes.</div><div><a href="http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2">http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2</a><br></div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 2:28 PM, Junxiao Shi <span dir="ltr"><<a href="mailto:shijunxiao@email.arizona.edu" target="_blank">shijunxiao@email.arizona.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><font size="4">NdnlpHeader wrapper</font></div><div>In the full plan <a href="http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx" target="_blank">NDNLPv2_20150513.pptx</a> page 17-20, we have a header and a trailer. The header wrapper makes it easier to define the portion covered by HMAC signature (page 53), and permits a padding at the end of header (page 24).</div><div>2-octet overhead is negligible on the link types mentioned in "Goals" section. NDNLPv2 is not designed for 20-octet MTU links; those links need a different link adaptation layer protocol.</div><div><br></div><span class=""><div><div style="font-size:12.8000001907349px"><font size="4">Unknown Fields</font></div><div style="font-size:12.8000001907349px">Excerpt from <a href="http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx" target="_blank">NDNLPv2_20150513.pptx</a> page 27:</div><blockquote style="font-size:12.8000001907349px;margin:0px 0px 0px 40px;border:none;padding:0px">Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to understand all fields.</blockquote><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Ignoring an unknown field will cause incorrect operations, see #2520 note-11.</div></div><div><br></div></span><div>A vendor-specific extension can claim a TLV-TYPE as "known field but relevant feature is disabled".</div><div>This is not a "unknown field".</div><div><br></div></div><div class=""><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 28, 2015 at 7:33 AM,  <span dir="ltr"><<a href="mailto:christian.tschudin@unibas.ch" target="_blank">christian.tschudin@unibas.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">A packet layout question: Isn't the NdnlpHeader wrapper redundant? You can see this in the grammar where no other field can ever follow the outer NDNLP-PACKET-TYPE and -length.<br>
<br>
Or are there plans for other fields coming before or instead of the NdnlpHeader? Else I guess that this was introduced for parsing speed reasons? But the price is considerable: at least 2 mandatory bytes for every Ndnlp packet for carrying no additional information.<br>
<br><br>
- Isn't the statement that "If an incoming NdnlpPacket contains unknown<br>
  fields, the receiver MUST drop the packet" evolution-hostile, also<br>
  against the old principle of "be liberal in what you accept"?<br>
<br>
  Or expresses this a stance against the feature interaction problem<br>
  and wants to prevent vendor-specific extensions? Asked differently:<br>
  Shouldn't there be a type range reserved for experimental and<br>
  vendor-specific extensions with an explicit semantics on how to<br>
  process such packets with unknown extensions (without dropping the<br>
  packet alltogether)?<br></blockquote></div></div></div></div></blockquote></div></div></div></div>