Hi Mališa, On Wed, Mar 25, 2020 at 10:37:57PM +0100, Mališa Vučinić wrote: > Hi Ben, > > There has been an extensive discussion on this issue in the WG. As Tengfei > stated, since MSF operates exclusively at L2, reading DSCP values from the > IPv6 header would constitute a layer violation. It was decided that MSF would > implement the recommendation from draft-ietf-6tisch-minimal-security by > recommending the rate limit on DSCP-tagged traffic, at IPv6 layer as outlined > in Security Considerations. That said, other scheduling functions that may > operate higher up in the stack, e.g. to establish end-to-end tracks between > nodes in a mesh, may adhere to this requirement from minimal-security. > Therefore, for the sake of future scheduling functions that may get > standardized, it was deemed appropriate to leave the recommendation in > minimal-security as-is. > > Hope that clarifies.
It does help clarify, thanks. I'm still not happy about ignoring the SHOULD from -minimal-security but can't really refute the technical points being made, so I will remove the Discuss point about it. That said, it seems like a slight rewording of -minimal-security might be in order, since: AF43. Companion SF documents SHOULD specify how this recommended behavior is achieved. One example is the 6TiSCH Minimal Scheduling Function [I-D.ietf-6tisch-msf]. seems to imply that MSF is an example of "specify[ing] how this recommended behavior is achieved", since it is just left to "the implementation" (i.e., not fully specified). Thanks, Ben _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
