Dear Toerless, Please see inline.
Cheers, Med >-----Message d'origine----- >De : Toerless Eckert [mailto:eck...@cisco.com] >Envoyé : vendredi 19 juillet 2013 05:13 >À : BOUCADAIR Mohamed OLNC/OLN >Cc : Reinaldo Penno (repenno); Charles Eckel (eckelcu); int-area@ietf.org >Objet : Re: [Int-area] FW: New Version Notification for draft-eckert- >intarea-flow-metadata-framework-01.txt > >On Thu, Jul 18, 2013 at 02:11:21PM +0200, mohamed.boucad...@orange.com >wrote: >> >[RP] I believe the end-point making the request for flow characteristics >> >will be the CPE in many cases where the applications is not metadata >> >aware. In other words, the CPE makes the request on behalf of >applications. >> [Med] I'm more interested in this CPE flavor (managed CPE) since it >avoids relying on applications to benefit from the added value of this >approach. This is worth be discussed in the document too. > >See section 3.1.4.1 which talks about proxies. The problem really is where >the proxied information comes from. If the proxy is doing DPI inspection to >deduce it or some configured mappings, then it's likely going to be >unreliable >(encryption) or suffer from problems in getting it provisioned. [Med] Section 3.1.4.1 as it is does not provide decent discussion of these deployment issues and considerations. Sketching the expected behavior of such intermediary functions would even be better. This applies also for the other deployment-related issues I listed in my initial e-mail. > >To me these inspecting proxies are a way to get a foot in the door with >the method while it takes its time to persuade app-developers (or >middleware >like browsers) to signal the information explicitly (couple of years ?...). > >> [Med] The question is not whether a secure transport is used or not but >to what extent the flow description is accurate (e.g., send fake flow >description, systematically request treatment with higher priority, etc.). > >Right. That was the intention of 3.1.4.2. Ultimately the network taking >action on the metadata needs to trust the authenticated identity >associated with the attributes to not lie about the attributes - OR >enforce the semantic of the attributes signalled. > [Med] this discussion about trust is worth to be elaborated further in the document. For sure, this point will be raised by others. >Cheers > Toerless _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
