Hi Med, I agree with you that we need to cover in more detail the managed CPE deployments but I wonder if this is the best document to do it.
Maybe a use-cases draft based on very concrete scenarios would be best. Thanks, Reinaldo On 7/19/13 4:57 AM, "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> wrote: >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
