| Hi, David, See below.. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com ...
Remember when you and others were claiming that how a tunnel connects to the OS or users is an implementation issue that doesn’t belong in the doc/spec? I still disagree, because you need to explain HOW (semantically) you interface to the ultimate source or sink of the IP packets. This, however, is a true implementation issue - and a bad one at that….
Well, there’s “remember to connect this to a router *or a host*”. Then there’s how this would interact with other interfaces on that router or host - which you haven’t defined, and probably won’t make a lot of sense because you have back-to-back devices, one of which is well defined (the host or router where you implement this), and one that’s only partly explained. And there’s no good way to relate those two on the same device. Which is yet another reason why this should not be deployed with the tunnel - even as an implementation. Include a user-space router or don’t, but please don’t half-do it.
You can add an appendix that says “if you also want to connect this to a user land router, here’s how”. But again, you’re not implementing a user land router. You’re implementing something that isn’t really a router, but takes responsibility for some of the behavior of a router. This simply doesn’t belong in this spec and should not be part of the tunnel definition at all. If you want to refer readers to an example, here’s one: I.e., showing readers how to tie this to a user-space router or a kernel router (as an example) is useful. Including user space router functions as a requirement of a tunnel spec is incorrect. Joe |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
