Hi Nico, hi Stephen, hi all, replying to this mail because that seems to be the right point to comment on the intent of the draft (and maybe also why it was presented in tsv-area). Yes, this draft could be phrased in a more neutral way, however, this draft is in an early state and the author received this feedback already in tsv-area. I’m sure they will incorporate this in the next version. But more important to say is that the intent is not to describe the good and the bad or the pros and the cons. This would be a completely different document. The intent of this document is actually to describe the benefits in the sense of why do operator deploy those middleboxes. Deploying and operating middleboxes costs money (and induces complexity, as described below in this mail) but there are still perceived benefits for operators otherwise the would not go through the hassle. Understanding these benefits is the first step to have a discussion on how to replace current practices as performed by middleboxes today with either end-to-end schemes, or at least middleboxes that are less intrusive or maybe find a way to provide in-network services with user consensus, or whatever… This document can be seen as input from operators to the IETF community. Again, I agree that any language that indicates any request to the IETF community to support any of these current practices should be removed. But I also believe it’s easy to misinterpret the current text if that’s what you already have in mind when you read the doc. And again, this is work in progress and that is not the indention. Further, regarding the points listed below on problems with middbleboxes. This would be a completely different document, which could be valuable as well. However, here the focus would be providing information to the operators and I really wouldn’t want to mix this up. Also I believe especially for such a document the current document could be good input as a basis to refer to when discussing specific problems of specific functions. The more constructive next step I would like to see, where this document from my point of view also provides the basis for the needed input, is to talk about mechanisms that realize the same benefits in an encrypted world, hopefully with less middbleboxes, and then point the operators at these documents, rather then just saying: what you do is bad, please stop. Mirja > Am 11.04.2017 um 19:18 schrieb Nico Williams <nico@xxxxxxxxxxxxxxxx>: > > On Tue, Apr 11, 2017 at 09:51:14AM +0100, Stephen Farrell wrote: >> On 11/04/17 09:15, mohamed.boucadair@xxxxxxxxxx wrote: >>>> I hope that the IETF never publishes >>>> draft-dolson-plus-middlebox-benefits; it makes claims about the >>>> benefits of specific solutions for different use cases with the >>>> goal of justifying those solutions. >> >>> [Med] I'm afraid this is speculating about the intent of >>> draft-dolson. Assured this is not the purpose of that document. The >>> motivation is to document current practices without including any >>> recommendation or claiming these solutions are superior to others. >> >> Just to note that I completely agree with Martin's interpretation >> of the thrust of this draft and I totally fail to see how your >> argument above can be justified given that draft title, abstract >> and even filename (and also the content;-). When the abstract >> says "This document summarizes benefits" then I cannot interpret >> that as other than being intended to justify the uses described. >> >> A fairly thorough re-write to aim to describe the pros and cons >> would be a different and more useful document. Similarly a draft > > Documenting the good, the bad, and the ugly, would be much better than > documenting only the good. Documenting only one half of the story seems > to me like a bad idea on its face. > >> that strives to neutrally describe existing reality could maybe >> be useful (*) but one that only describes middlebox friends with >> "benefits" is not IMO beneficial ;-) > > Agreed. > > I can think of a number of problems with middle boxes: > > - scalability > > Middle boxes may need to expend much more computational power in > order to do more than forward packets, and they need to do this for > as many extant packet flows as will fit on their pipes at full tilt. > > Middle boxes may also have to be stateful, which quickly turns into a > morass. > > - security > > Middle boxes can get intrusive and require sharing either more > information with the public at large, or more information with > "trusted" middle boxes, which in turn requires more complex key > management and more failure modes. > > - reliability > > More failure modes (see security above). More middle boxes to > inspect for diagnostics. More middleboxes to fix. > > - extensibility > > Want to extend the protocol? You can't. You'd have to upgrade all > the middle boxes first. You can only get the extensibility that you > can foresee. If you screw up the first time, the screw up will take > 15 years to work out of the Internet in the best case, and in the > worst case you'll never get it out. > > I can probably add more later when I have more time for this thread. > > One could give a lot of advice for design of protocols with "friendly" > middle boxes. Merely saying "hey, they are good" is not enough. We > might want to revisit end-to-end protocol design as well (e.g., maybe > ICMP isn't working so well; what can we do?). Perhaps we can get some > of the benefits of middle-box-aware protocols without the middle boxes. > Suppose a secure middle-box quench protocol by which nodes under DDoS > can enable DDoS counter-measures in upstream routers... Suppose a > generic, non-TCP congestion control capable but UDP-like transport with > a reusable header prefix and ICMP-ish messages for QoS and congestion > control... I'm certain we can do more within the end-to-end model with > minimal middle-box involvement (though never zero; we need at least > packet forwarding middle boxes). > > IMO the IETF must not publish draft-dolson-plus-middlebox-benefits as it > is today. > > Nico > -- >