On Fri, Sep 29, 2023 at 8:49 AM Robinson, Herbie <Herbie.Robinson=40stratus....@dmarc.ietf.org> wrote: > > 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?
Herbie, That's a very good question, and probably one of the more interesting sub-problems of host networking that we'll have to solve! That is: How do we implement distributed security with potentially multiple nodes performing decryption of the data in the high performance datapath? Tom > > 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
