Hi Martin, Thank you very much for your feedback, and apologies for the late response.
We just published an updated version of the draft (revision -10). Regarding your Discuss point, after discussion among the authors and with the WG, we aim to address the issue by stating now that: As per the present specification, the MTU size for IPv6 mesh over BLE links is 1280 octets. (Initially we thought that it might be a good idea to keep the flexibility offered by the IPSP in this regard, but we finally realized that it was not such a good idea.) Should you have further comments, please let us know. Thanks, Carles (on behalf of all the authors) > Martin Duke has entered the following ballot position for > draft-ietf-6lo-blemesh-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-blemesh/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I found this paragraph in Section 3.1 to be hand-wavy: > > "Note that this specification allows using different MTUs in different > links. If an implementation requires use of the same MTU on every > one of its links, and a new node with a smaller MTU is added to the > network, a renegotiation of one or more links can occur. In the > worst case, the renegotiations could cascade network-wide. In that > case, implementers need to assess the impact of such phenomenon." > > What are the consequences of link "renegotiation"? If every MTU downgrade > results in a storm of messages, that's a bad property. Is the use case > where > the MTU must be the same on all links an important one? If not, simply > requiring hosts to handle this case seems way cleaner. _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
