OK, I see where you are coming from and it makes sense. Hopefully that will become clear when the IANA Considerations section gets completed.
Just out of curiosity, how would key distribution and updating work for the encryption? From: Int-area <int-area-boun...@ietf.org> On Behalf Of Tom Herbert Sent: Friday, September 29, 2023 11:12 AM To: Robinson, Herbie <Herbie.Robinson=40stratus....@dmarc.ietf.org> Cc: Tom Herbert <tom=40herbertland....@dmarc.ietf.org>; int-area <int-area@ietf.org>; tsvwg <ts...@ietf.org> Subject: Re: [Int-area] [EXTERNAL] Fwd: New Version Notification for draft-herbert-net2hostsig-00.txt [EXTERNAL SENDER: This email originated from outside of Stratus Technologies. Do not click links or open attachments unless you recognize the sender and know the content is safe.] On Thu, Sep 28, 2023 at 9:32 AM Robinson, Herbie <mailto:Herbie.Robinson=40stratus....@dmarc.ietf.org> wrote: > > I have a couple of observations > > > 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. The relevant text is: "An outcome of this design is that there is no requirement for a standard set of signals that all networks must support; signals can be defined in each provider network per their needs and the network services they offer." It's not so much about being vendor specific, it's more about avoiding a "one size fits all" approach. An automotive network may offer very different services than a mobile network which may be different than a cloud provider. There may be a common set of signals for each of these types of networks, but I think we want to avoid mandating that the services and their signals have to be used by everyone. > 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. Yes, applications should only need one protocol. For the actual signals, they only have to support the carrier in packets. For requesting signals, I would envision that applications contact an agent in the network that makes their request. Maybe something like REST with some XML description of parameterizations. Since these requests are not inline with the data path, the requests for services could be a rich set of parameters (frame rate, latency, anti-censorship, etc.). The set of possible parameters could be standard, but it becomes a network specific thing to turn these parameters into a signal for the services they support in the network the host can use with its packets. > 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
