Hi Med, Thanks for your review. Inline with [RP]
On 7/18/13 6:13 AM, "mohamed.boucad...@orange.com" <mohamed.boucad...@orange.com> wrote: >Dear Charles, all, > >The idea of an application sending flow characterization messages to the >network is interesting. This is an idea which is worth to be discussed >and challenged. Thank you for writing this document. > >The proposed framework makes sense in some contexts but I'm afraid it >does not solve the limitations you listed in the document (e.g., avoid >some classification functions in the network). The framework as it is >won't simplify the network side since in addition to legacy tools, a new >function to intercept the flow characterization messages will be needed. [RP] Interception is only needed with some transports. We should certainly highlight that. >The benefit of the approach depends on the willing of application >developers to signal the flow characteristic to the network. [RP] Yes. I believe this is somewhat a chicken and egg thing. Because such functionality was never truly available in the network, there was no incentive to applications developers. > > >IMHO, it would be useful if the document elaborates on deployment aspects >and what are the facilitators to ease adoption of such approach. For >example, why an application relying on HTTPS would sent a non-encrypted >flow characterization message for analytic purposes? What is the role of >a CPE in such model? [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. >How to trust the data sent by an application? These are examples of >points which should be further discussed in the document. [RP] I think this depends on the transport. Some transports like PCP or STUN have some built-in authentication. > > >If the purpose of the document is not to claim the limitations you >identified will be mitigated but instead this framework is an additional >tool at disposal for implementers/operators/etc to ease service ordering >and delivery, then a note should be added to the draft. This will be >helpful to avoid any confusion. > >Personally, I'm not a fun of solutions which requires explicit resource >invocation before making use of a subscribed service. [RP] Me neither. I was hoping the draft did not come as that. The idea here is that any metadata could be send before or after connection is established and reservation is not required at all. In other words, applications will work as always have but could request metadata service if they so desire. If request is denied, everything continues to work as is. >This mode should not be generalized (it does make sense if a very few >services rely on that mode). I understand there are deployment cases >which would rely on such mode but this should be discussed in the >document too. > >I didn't understood well why the encoding is discussed in this document. >The focus should be on the information model not data models (which are >protocol-specific). > >Cheers, >Med > >>-----Message d'origine----- >>De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la >>part de Charles Eckel (eckelcu) >>Envoyé : lundi 15 juillet 2013 23:07 >>À : int-area@ietf.org >>Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea- >>flow-metadata-framework-01.txt >> >>We have submitted and would appreciate comments on the following draft. >>It >>provides a framework for applications and network devices to communicate >>characteristics and service attributes for traffic flow. One aspect we >>anticipate to be of particular interest to this audience is the use of >>IPFIX in the information model we defined. >> >>Cheers, >>Charles >> >>-----Original Message----- >>From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >>Sent: Monday, July 15, 2013 1:41 PM >>To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno >>(repenno); Charles Eckel (eckelcu) >>Subject: New Version Notification for draft-eckert-intarea-flow-metadata- >>framework-01.txt >> >> >>A new version of I-D, draft-eckert-intarea-flow-metadata-framework-01.txt >>has been successfully submitted by Toerless Eckert and posted to the >>IETF repository. >> >>Filename: draft-eckert-intarea-flow-metadata-framework >>Revision: 01 >>Title: A Framework for Signaling Flow Characteristics between >>Applications and the Network >>Creation date: 2013-07-15 >>Group: Individual Submission >>Number of pages: 17 >>URL: >>http://www.ietf.org/internet-drafts/draft-eckert-intarea- >>flow-metadata-framework-01.txt >>Status: >>http://datatracker.ietf.org/doc/draft-eckert-intarea-flow- >>metadata-framework >>Htmlized: http://tools.ietf.org/html/draft-eckert-intarea-flow- >>metadata-framework-01 >>Diff: http://www.ietf.org/rfcdiff?url2=draft-eckert-intarea- >>flow-metadata-framework-01 >> >>Abstract: >> This document provides a framework for communicating information >> elements (a.k.a. metadata) in a consistent manner between >> applications and the network to provide better visibility of >> application flows, thereby enabling differentiated treatment of those >> flows. These information elements can be conveyed using various >> signaling protocols, including PCP, RSVP, and STUN. >> >> >> >> >>The IETF Secretariat >> >>_______________________________________________ >>Int-area mailing list >>Int-area@ietf.org >>https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
