I have a couple of observations There is a desire to make host to network signals processable in fast router paths without variable length packet processing. Yet at the same time, there is a requirement for encryption. Processing variable length packets is going to be a lot easier in the fast path (all it takes is a barrel shifter) than decrypting parts of a packet; so, it would appear that these are conflicting requirements. Both are, of course, implementable with the appropriate hardware resources, but I suspect it will take a lot of persuading to get any vendors to do that.
In section 2.2, you make the claim that the actual host to network services should be vendor specific. Yet in section 2.3, the example services you mention are all things that should, in fact, be standardized. While I am willing to accept that there are examples where vendor specific services should be supported, the main focus should be a model for describing standard services as well. I am speaking as the maintainer of host networking software and by extension the applications that use it. Asking applications to interface to potentially hundreds of different vendor protocols is unmanageable (from the standpoint of the application developer) and will most like result in none of them using any of it. In section 6, I would also claim that it's a requirement that any vendor specific services must be registered with the IANA and fully described in documentation provide free of charge by the vendor. Re: |Name: draft-herbert-net2hostsig |Revision: 00 |Title: Host to Network Signaling |Date: 2023-09-27 |Group: Individual Submission |Pages: 22 |URL: https://www.ietf.org/archive/id/draft-herbert-net2hostsig-00.txt |Status: https://datatracker.ietf.org/doc/draft-herbert-net2hostsig |HTMLized: https://datatracker.ietf.org/doc/html/draft-herbert-net2hostsig _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
