On 09-Sep-19 16:11, Joe Touch wrote: > > >> On Sep 8, 2019, at 8:50 PM, Brian E Carpenter <[email protected] >> <mailto:[email protected]>> wrote: >> >> On 09-Sep-19 12:15, Joe Touch wrote: >>> >>> >>>> On Sep 8, 2019, at 1:26 PM, Brian E Carpenter <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected]>> >>>> wrote: >>>> >>>>>> >>>>>> Wouldn't that require the middle box to become an architectural element? >>>>> >>>>> Yes, but not just “an” (one): >>>>> >>>>> Touch, J: Middlebox Models Compatible with the Internet. USC/ISI >>>>> (ISI-TR-711), 2016. (Type: Technical Report | Links | BibTeX) >>>>> >>>>> * https://www.strayalpha.com/pubs/isi-tr-711.pdf >>>> >>>> I'll take the liberty of pointing out that we've known for many years that >>>> there are multiple types of middleboxes and they have multiple facets: >>>> https://tools.ietf.org/html/rfc3234 >>> >>> Facets are just properties. That doc makes no attempt to describe them as >>> architectural roles. >> >> Agreed. My point is that the issue has been lying on the IETF table for many >> years, and we've collectively chosen to ignore it. > > By “we”, I’m not sure who you mean. There have been plenty of us complaining > about this gap for a very long time in the IETF.
Yes, but the IAB hasn't really taken up the issue and we haven't ever had a WG that seriously tackled it, IMHO. > >> >>>> >>>> So far, we haven't added them to any formal architectural description of >>>> the Internet, probably because we don't have one. >>> >>> RFC1122, RFC1123, RFC1812 as standards. >>> >>> I (and IMO those RFCs) disagree with the position you took in RFC1958, FWIW. >> >> "you" = the IAB in 1996; I was only the document editor. > > Fair point, but presumably you were on the IAB at the time? Yes indeed. But although it's almost my most-cited RFC, I don't deserve sole credit or sole blame. > >> But IMHO those RFCs are not architectural as such. They describe functions >> of nodes, not how the nodes work together as a system. > > An architecture is (IMO) the behavior of a system that is the consequence of > the behavior of its components and the ways in which they interact. > > Arguably, those RFCs - adding 791 and 3819, and a few others, do exactly > that. In a nutshell: routers relay; subnets (as links) interconnect), and > hosts source, sink, and do the rest (including reliability), all based on > globally-unique addresses in that can be aggregated by bit prefix. No, > there’s no “roadmap” doc that provides the top-level description, but the > rest is definitely there in those and other docs. Yes, we agree about that. It's the roadmap that is missing. > IMO, the issue is that middleboxes can’t simply be added to that list > consistently - they aren’t a third thing that can be peers to routers or > hosts. There is a way to describe them that’s consistent, though - but only > if they are different elements when viewed from different points in the > network (as I described in the tech report). I can't disagree. Brian > > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
