Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De : ietf [mailto:ietf-bounces@xxxxxxxx] De la part de Nico Williams > Envoyé : mardi 11 avril 2017 19:50 > À : Melinda Shore > Cc : ietf@xxxxxxxx > Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft- > mm-wg-effect-encrypt-09) > > On Tue, Apr 11, 2017 at 09:31:41AM -0800, Melinda Shore wrote: > > On 4/11/17 9:18 AM, Nico Williams wrote: > > > 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?). > > > > There have been a number of efforts to provide mechanisms for > > applications to communicate explicitly with middleboxes. None > > has gotten any traction, and for the moment it looks like > > anything that requires changes to middleboxes along those > > lines is unlikely to be successful. That said: > > Sure, but if we wanted to have an Informational RFC describing all the > goodness and badness and history of middle-box-aware protocools, that > might not be bad, and we could detail all those protocols that failed to > get traction and why. I think such a document would end up favoring > end-to-end protocols, even if it didn't start out with that as a goal :) > [Med] This may be applicable for some cases under some conditions ... but I'm afraid this may not be applicable to all of them. This is why it is important to understand the intended usage (draft-dolson) before going further in the discussion (e.g., whether it makes sense to call for a generic recommendation, standardize a given network-located function a la BEHAVE, etc.). For example, an operator will need to detect and mitigate DDoS attacks without interfering with legitimate traffic issued/send to customers. "Something" is to be done at the network side to that aim. We are investigating how endpoints can help to achieve that goal.