Dear Mirja (and Ben), Many thanks for reviewing this document! > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with one of Ben's comments in that I'm not certain about the intended > document status as PS. I think Informational might be more appropriate, as it > rather describes an approach based on existing protocols than a normative > protocol specification.
This was long debated and went back and forth. We finally settled for STD track after the review by Dave Thaler. There's actually generic normative text in this document, in the forwarding fragments section. Any spec that provides a fragment forwarding technique should normatively refer this and abide by that text. As an example, but there's more: " Since the datagram_tag is uniquely associated to the source Link- Layer address of the fragment, the forwarding node MUST assign a new datagram_tag from its own namespace for the next hop and rewrite the fragment header of each fragment with that datagram_tag. When a forwarding node receives a fragment other than a first fragment, it MUST look up state based on the source Link-Layer address and the datagram_tag in the received fragment. If no such state is found, the fragment MUST be dropped; otherwise the fragment MUST be forwarded using the information in the state found. " This is why we ended up with STD track. You found reviewing https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery that there's already a std track with a normative reference to this. Many thanks again! Pascal _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
