draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Martin, all, 

I have a comment about this particular part of your review.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : ietf [mailto:ietf-bounces@xxxxxxxx] De la part de Martin Thomson
> Envoyé : vendredi 7 avril 2017 05:25
> À : ietf@xxxxxxxx
> Objet : Review of draft-mm-wg-effect-encrypt-09
> 
> 
> 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. There is a need to understand the motivations why operators need to enable some of these features. For example, means to help on-path devices executing their service are needed for network operation purposes (e.g., protect a network, detect cover channels, help selecting the portion of traffic to be filtered rather than directing all the traffic to a black hole during attacks, etc.). 

Of course, authors of draft-dolson understand there are deployment cases where middleboxes may not be required at all. Their presence may even be a source of trouble if badly tweaked, for example. That’s an evidence. 

Authors of draft-dolson does not claim middleboxes is the only way to meet the technical objectives listed in the draft, but they are documenting sample features that are needed to be supported at the network side. 

Solution designers can refer to draft-dolson to explicit how they solve a particular problem without requiring services from an on-path device.


  At the same time, it fails
> to
> recognize the existence of alternative,

[Med] It does not do so because it is out of scope. Before discussing alternatives, we need first to understand the goals that motivated current practices. Future documents can refer to draft-dolson to describe alternatives.  

 often superior,

[Med] I don't see how you ended to such conclusion as a general statement without even looking at the needs! It may be tempting to ask, for example, what are these superior alternatives to help operators detect and mitigate DDoS, but as mentioned above, it is early at this stage to discuss these alternate solutions.   

 solutions for
> those use
> cases.  In other words, it has many of the same issues as this document.
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]