Re: [CDNi] Content Adpatation

[ZhouZhipeng <[e-mail]>]

Morning, all, 
I have thought about a while and feel I'd better give back an email.
We are in the same river (the same industry) and we may be friends while on work we may have different opinions.
Some thing may be either correct or wrong. While some things are not on the same way.
In the industry, there may be different solutions existing at the same time.
You may like flash while other video technologies may be used by other people. It is just whether you use it or not rather than whether good or not.
I thank all that have responded in the maillists about CA. That helps me deeper thinking about the topic also.
Zhipeng

-----Original Message-----
From: Francois Le Faucheur [mailto:[e-mail]] 
Sent: Thursday, December 15, 2011 4:17 PM
To: ZhouZhipeng
Cc: [e-mail]
Subject: Re: [CDNi] Content Adpatation

Hello Zhipeng,

(As a co-chair)
I believe the IETF process has been followed correctly and a clear decision about Content Adaptation has been made.
I would now ask you to stop re-opening that discussion on the list, so the Working Group can focus its energy to progress what is in scope.
If you want to formally object to this decision, then you can follow the IETF escalation and appeal process.

Francois


On 15 Dec 2011, at 08:29, ZhouZhipeng wrote:

> Vinayak,
> Although I was not in the room, but I am quite clear of the process:)
> I know some people had raised some simple questions in the room whether the A, B, C been matched to option 1, 2,3.
> I doubt whether people have carefully read the vote options.
> For instance I have not seen any "could" while Francois think it is saying "could".
> How may you think the process:
> 
>>> Even if what you say were true, 
> Thanks.
>>> I am not seeing anyone on the list having any objections to CA being taken up later on the list.
> Why not:)
>>> I think you are just not happy with the consensus.
> No, I more care the process on this thing.
> 
> Good morning.
> Zhipeng
> 
> 
> -----Original Message-----
> From: Vinayak Hegde [mailto:[e-mail]] 
> Sent: Thursday, December 15, 2011 3:19 PM
> To: ZhouZhipeng
> Cc: Bruce Davie; [e-mail]
> Subject: Re: [CDNi] Content Adpatation
> 
> Hi Zhipeng,
> 
> Couple of clarifications:
> 
> 1. Humming as a method for consensus has already been well documented
> in the Tao of the IETF and elsewhere. Ben has referenced the sections
> in an earlier thread.
> 
> 2. The options were clarified very clearly by Francois before the
> consensus was judged. The opinions from Jabber were also taken into
> consideration. I was present in the room when this was done. So there
> is no question of ambiguity. There was consensus that CA should be
> taken up later once all the basic stuff is nailed down in specs.
> 
> 3. Lastly I think you were not present in the room when the options
> were presented. Even if what you say were true, I am not seeing anyone
> on the list having any objections to CA being taken up later on the
> list. I think you are just not happy with the consensus.
> 
> -- Vinayak
> 
> On Thu, Dec 15, 2011 at 12:24 PM, ZhouZhipeng <[e-mail]> wrote:
>> Hello Bruce, Ben and Vinayak,
>> 
>> Absolutely sometime vote may be raised in all SDOs, but before the vote
>> whether the options should be clarified to make sure the meaning of the
>> options have been clear and appropriate and let all the people to know how
>> to do after the vote before the meeting.
>> 
>> Besides, if most people in the room have not hum, may we think most people
>> are opposing to all the three options.
>> 
>> Absolutely this vote is not fully prepared, as quick as possible:
>> 
>> 
>> 
>> For your reference.
>> 
>> Zhipeng
>> 
>> 
>> 
>> From: Bruce Davie [mailto:[e-mail]]
>> Sent: Wednesday, December 14, 2011 10:53 PM
>> To: ZhouZhipeng
>> Cc: Francois Le Faucheur; [e-mail]
>> Subject: Re: [CDNi] Content Adpatation
>> 
>> 
>> 
>> Zhipeng,
>> 
>> like all IETF working groups, the CDNI WG does not conduct formal votes. To
>> quote from RFC 4677:
>> 
>> 
>> 
>>    Another aspect of Working Groups that confounds many people is the
>> 
>>    fact that there is no formal voting.  The general rule on disputed
>> 
>>    topics is that the Working Group has to come to "rough consensus",
>> 
>>    meaning that a very large majority of those who care must agree.  The
>> 
>>    exact method of determining rough consensus varies from Working Group
>> 
>>    to Working Group.  Sometimes consensus is determined by "humming" --
>> 
>>    if you agree with a proposal, you hum when prompted by the chair; if
>> 
>>    you disagree, you keep your silence.  Newcomers find it quite
>> 
>>    peculiar, but it works.  It is up to the chair to decide when the
>> 
>>    Working Group has reached rough consensus.
>> 
>> 
>> 
>> I believe that is what was done at the Taipei meeting, but Francois may wish
>> to elaborate further.
>> 
>> 
>> 
>> Yes, it is unusual if you are comparing the IETF to some other organization.
>> Some people consider this a feature.
>> 
>> 
>> 
>> Bruce
>> 
>> 
>> 
>> 
>> 
>> On Dec 14, 2011, at 6:28 AM, ZhouZhipeng wrote:
>> 
>> 
>> 
>> Morning Francois,
>> 
>> May I further ask whether the group had ever announced vote options and  the
>> rule of the vote in the maillist before the Taipei meeting .
>> 
>> It is not usual to provide three options for vote, always should be two
>> perhaps.
>> 
>> For your reference.
>> 
>> Zhipeng
>> 
>> 
>> 
>> From: Francois Le Faucheur [mailto:[e-mail]]
>> Sent: Tuesday, December 13, 2011 6:53 PM
>> To: ZhouZhipeng
>> Cc: [e-mail]
>> Subject: Re: [CDNi] Content Adpatation
>> 
>> 
>> 
>> Hello Zhipeng,
>> 
>> 
>> 
>> Yes, we need to select one approach for the working group to follow (ie one
>> option).
>> 
>> At this stage, the chairs feel that there is "rough consensus" on option 1.
>> 
>> You are right that this only conditions what is worked on in v1, and the
>> additional functionality can be incorporated in v2.
>> 
>> 
>> 
>> Cheers
>> 
>> 
>> 
>> Francois
>> 
>> 
>> 
>> 
>> 
>> On 13 Dec 2011, at 09:00, ZhouZhipeng wrote:
>> 
>> 
>> 
>> 
>> Francois, Good morning,
>> 
>> May I ask a question: how many supporters are needed if to support CA in
>> CDNI.
>> 
>> Perhaps that is more clear than the ‘HAM’.
>> 
>> Do we insist only one option even it is only 1 more than another option
>> shall be good enough.
>> 
>> In fact, the three options are all to support this functionality while the
>> difference is whether to support in v1 or v2.
>> 
>> For your reference.
>> 
>> 
>> 
>> Thanks.
>> 
>> Zhipeng
>> 
>> 
>> 
>> From: Francois Le Faucheur [mailto:[e-mail]]
>> Sent: Friday, December 09, 2011 10:33 PM
>> To: zhangyunfei
>> Cc: [e-mail]
>> Subject: [CDNi] Content Adpatation
>> 
>> 
>> 
>> All,
>> 
>> 
>> 
>> Please see the notes on Content Adaptation from the minutes of the Taipei
>> meeting at http://www.ietf.org/proceedings/82/minutes/cdni.txt.
>> 
>> 
>> 
>> "
>> 
>> Hum test.
>> 
>> Option 1 - Strong hum
>> 
>> Option 2 - weak Hum + 2 hums from jabber.
>> 
>> option 3 - silence
>> 
>> The tentative agreement is to go for Option 1. This will be validated on the
>> list.
>> 
>> "
>> 
>> 
>> 
>> If we add Alan and Yunfei's input it takes us to:
>> 
>> "
>> 
>> Hum test.
>> 
>> Option 1 - Strong hum
>> 
>> Option 2 - weak Hum + 2 hums from jabber + 2 on the list
>> 
>> Option 3 - silence
>> 
>> "
>> 
>> 
>> 
>> Unless we hear significant additional input on the list in the coming days,
>> we will consider the decision for Option 1 final.
>> 
>> Cheers
>> 
>> 
>> 
>> Francois & Rich
>> 
>> 
>> 
>> 
>> 
>> On 9 Dec 2011, at 03:04, zhangyunfei wrote:
>> 
>> 
>> 
>> 
>> 
>> +1. It's reasonable to have a simple option open for content adaptation
>> issue between uCDN and dCDN. But we needn't jump into designing the detailed
>> content adaptation para transfer mechanism right now, as agreed in last
>> IETF.
>> 
>> 
>> 
>> BR
>> 
>> Yunfei
>> 
>> 
>> 
>> ________________________________
>> 
>> zhangyunfei
>> 
>> 
>> 
>> From: Alan Kavanagh
>> 
>> Date: 2011-12-09 04:02
>> 
>> To: Scott Wainner; [e-mail]
>> 
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Hi Scott
>> 
>> 
>> 
>> Apologies for now following up sooner on this, too much traveling lately
>> etc.
>> 
>> 
>> 
>> I agree with you that these two binary options are simple and sufficient and
>> more importantly "allow us to extend" CDNI for future work, so im supportive
>> of your suggestion and hope its included in the appropriate documents such
>> as the Metadata and Control and not just the use cases drafts.
>> 
>> 
>> 
>> The reason most CDNs will set the "content adaptation permitted" flag ==0 is
>> for quality control on content being distributed where by the Authorised CDN
>> has as you say a contractual agreement with the CSP and that authorised CDN
>> is responsible for transcoding and checking it etc, that by and large covers
>> a large set of scenarios and mostly the predominant cases today. I do see
>> some CDN's that for different types of content will allow content to be
>> adopted but by and large that is not the common case of today but its an
>> option we should include and i think have those binary options covers the
>> basic cases.
>> 
>> 
>> 
>> Alan
>> 
>> 
>> 
>> ________________________________
>> 
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Scott Wainner
>> Sent: November-01-11 3:47 PM
>> To: [e-mail]
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Perhaps the answer to this dilemma is very simple ...
>> 
>> In the CDNI interface, we simply offer a binary option of the following:
>> 
>> 0) content may not be adapted
>> 1) content may be adapted
>> 
>> I suspect that the majority of the CDNI relationships will set the flag to
>> "0" indicating the asset is not allowed to be adapted.  The reason can be
>> anything including contractual between the CP and uCDN, the content is
>> encrypted, the uCDN preference, etc.
>> 
>> Now if the flag is set to "1", it is incumbent upon the dCDN to figure out
>> how to modify the content without changing the URL references, etc.
>> 
>> Scott
>> 
>> On 10/27/11 7:22 AM, Woundy, Richard wrote:
>> 
>>> In your company’s website, I just find some information
>> 
>> I have to step in as co-chair here.
>> 
>> The goal of this WG is not to align vendor product roadmaps, or to equalize
>> all vendor offerings, or to specify the entire CDNI ecosystem. The goal of
>> this WG is to enable the interconnection and interoperation of two or more
>> CDNs, within the bounds of the CDNI wg charter.
>> 
>> It is OK to have a discussion about whether content adaptation needs to be
>> performed by the dCDN, since that decision impacts the uCDN-dCDN interface.
>> So let's find a productive way to discuss this on the mailing list, and to
>> close the discussion by IETF 82 (if not sooner).
>> 
>> Can someone describe real-life examples where downstream CDN (or edge
>> cache-based) content adaptation is needed today in a production environment,
>> or shortly? Not merely a feature in a vendor's product materials?
>> 
>> Speaking as an individual, I can find a lot of examples where downstream
>> content adaptation is not needed, and any adaptation is really part of the
>> CP - uCDN interface (which is out of the scope of our charter).
>> 
>> -- Rich
>> 
>> 
>> 
>> From: ZhouZhipeng [mailto:[e-mail]]
>> Sent: Thursday, October 27, 2011 03:45 AM
>> To: Mark de Jong <[e-mail]>; Alan
>> Kavanagh <[e-mail]>
>> Cc: [e-mail] <[e-mail]>
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> 
>> Hello Mark,
>> 
>> Nice to meet you on line.
>> 
>> In your company’s website, I just find some information that addresses
>> “ Vodafone subscribers complained about video performance.”
>> 
>> See:
>> 
>> http://www.jet-stream.nl/search/?search=transcoding
>> 
>> Dear all in this group,
>> 
>> In last few days, except the public email discussions I have contacted with
>> some people and discussed with my own colleagues of all details on this
>> issue.
>> 
>> First, although the market requirement for it is very important, I feel
>> I’d better show up more information on the procedure involved. I have
>> explained many times that to support content adaptation is rather simple
>> while the wording is not enough.
>> 
>> I am busy making some contributions on this and plan to upload to ETSI
>> meeting and IETF CDNI.
>> 
>> By these work  I feel the people may catch a whole view on this issue.
>> 
>> Second, for that functionality, in implementation, if some entity does not
>> choose to support it, it may be ok. Since it may be negotiated between two
>> CDNs.
>> 
>> If dCDN does not support that, it may be the uCDN responsible to complete
>> the transcoding and deliver the content of multiple formats and rates to
>> dCDN.
>> 
>> Third, although CDNI is a new architecture, while the content operating has
>> been existed for years. As I know the content from USA to the downstream
>> operator is transferred on one copy and the downstream operator will handle
>> the transcoding.
>> 
>> Perhaps, the content adaptation is more on the mobile operating. But I feel
>> currently most operator will be a all service operator. And for the CDN
>> providers, it may be better to support all kinds of service.
>> 
>> Besides, I like say that the technology on this topic has been for many
>> years and has been rather mature, even some items in ietf such as rfc3507
>> icap. So from the technique point of view, it is a nature action to be
>> involved in CDN interconnection.
>> 
>> Thanks.
>> 
>> Zhipeng
>> 
>> From: Mark de Jong [mailto:[e-mail]]
>> Sent: Thursday, October 27, 2011 4:21 AM
>> To: Alan Kavanagh
>> Cc: Ben Niven-Jenkins; ZhouZhipeng; [e-mail]
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Hi Alan,
>> 
>> As Ben stated the overall discussion right now is about delivery, not on
>> adaptation. It is hard enough to get consensus on the delivery aspect
>> already not to mention your requirement from content adaptation added to
>> that, so I agree with Ben we should stick with the delivery aspect for the
>> first specs. I can imagine this could be a discussion later on but please
>> let us keep the scope of this be clean and transparent. It is of benefit of
>> everyone to get the first specs as fast as possible. Thanks.
>> 
>> Met vriendelijke groet,
>> 
>> Kind regards,
>> 
>> Mark de Jong
>> International Business Developer
>> Jet-Stream BV
>> 
>> E-mail: [e-mail]
>> Office: [phone]
>> Mobile: [phone]
>> Fax: [phone]
>> 
>> - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK
>> 
>> - Event: Meet us at Online Video Strategies, 19 October, London, UK
>> 
>> - Event: Meet us at CDN World Summit, 25-28 October, London, UK
>> 
>> - News: Pre-request your Technology Whitepaper now and be the first to have
>> it, check www.jet-stream.com
>> 
>> - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs'
>> brochure
>> 
>> - Blog: www.jet-stream.com/blog/
>> 
>> - VideoExchange: www.vdo-x.net
>> 
>> - Streamzilla: www.streamzillacdn.com
>> 
>> - Corporate: www.jet-stream.com
>> 
>> On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> Ben
>> 
>> Im assuming then based on your comments below are you suggesting we are
>> going to have a number of versions of the CDN-I Metadata?
>> 
>> I sympathise with what you are pointing out below and do agree that there is
>> some work to be done, but I still feel that content adaptation is to me a
>> fundamental requirement to what collectively we should address in the CDN-I
>> WG. I do agree with you that content adaptation is an optimization between
>> CDN's but it's a very important one that I know Network Service Providers
>> particularly require.
>> 
>> Alan
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ben
>> Niven-Jenkins
>> Sent: October-12-11 1:13 PM
>> To: ZhouZhipeng
>> Cc: [e-mail]
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Zhipeng,
>> 
>> On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:
>> 
>> 
>> 
>> 
>> 
>> Hello Ben,
>> 
>> The UE may select the content format on the CP web. After that the user only
>> desires to get his selected content.
>> 
>> But how the content is transferred to the client is not worried by the user.
>> 
>> The CP may create a special format as required by the user and ask the CDN
>> to deliver to user.
>> 
>> While CP may give a HD format content to uCDN and the dCDN may then
>> transform to the format as the user select.
>> 
>> 
>> Lots of things may be possible to do and CDN providers offer many additional
>> services on top of the "core" service of content delivery. However, our
>> objective (based on my interpretation of the CDNI charter) is to focus on
>> what is necessary to interconnect CDNs to deliver content from a CSP to an
>> End User that is targeted and deployable within a short time frame (18-24
>> months).
>> 
>> Content transformation/adaptation is not an essential requirement in order
>> to achieve that aim (we can deliver content from CSPs to End Users via
>> multiple CDNs without needing or requiring any CDN supports content
>> adaptation).
>> 
>> In my opinion we have enough work to do already without trying to expand the
>> scope of our work to include additional requirements that do not help us
>> address our core objectives as laid out in the CDNI charter.
>> 
>> 
>> 
>> 
>> 
>> In this case, it is nothing related to how the user select formats on CP
>> website.
>> 
>> So, it is the CP and user to decide the content format not the CDN(your
>> assert is not correct and seems you take that assert as your base for the
>> discussion).
>> 
>> As for "the core CDN functionality offered by CDNs today", I have ever
>> raised an email before that your company's webpage has claimed supporting
>> media transformation and multi-screen service.
>> 
>> Perhaps, I like asking you list some features that you feel are the core
>> functionalities by existing main stream CDNs. Thus we may compare and take
>> deep look.
>> 
>> 
>> I think the core functionality maps pretty well to the CDNI interfaces,
>> namely: Request Routing, Metadata configuration, log production and control
>> plus content acquisition and content delivery.
>> 
>> 
>> 
>> 
>> 
>> I guess many people have the experience/knowledge of content related
>> service. The user and CP only care whether the CDN providers may satisfy
>> their requirement while not care the internal process. Just as GSM/PSTN
>> interconnection, the user only care successful interconnection while not
>> care how the voice is transformed in process.
>> 
>> Besides, I like raise a case:
>> 
>> Given currently BBC recruits CDN providers that may support 10 media
>> formats.
>> 
>> One candidate is your company, another is CDN-X. The users are located in
>> France.
>> 
>> So both your company and CDN-X should connect a France CDN provider(CDN-Y).
>> 
>> If your company's solution is to send 10 streams of different format
>> 
>> of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y
>> while CDN-Y may conduct some adaptation.
>> 
>> Comparing these two solutions, for your company and CDN-X, absolutely the
>> cost of CDN-X is much lower.
>> 
>> For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in
>> solution-2, it should only receive 1 stream but need to take transformation
>> to output 10 streams.
>> 
>> Which solution is more competitive. it is Solution 1, right. Remember the
>> price from BBC is same to both your company and CDN-X or BBC would select
>> one CDN provider with the lower price.
>> 
>> If a CDN provider may not get the contract from CP, how it may say it is not
>> a core functionality.
>> 
>> 
>> What you are describing is a possible optimization that a particular CDN may
>> wish to implement not a core functionality required to enable content
>> delivery between interconnected CDNs. I can think of many optimizations that
>> a CDN could implement to differentiate their service but the internal
>> workings of an individual CDN are out of scope of our charter.
>> 
>> So to repeat my position for a final time: Content adaptation is not a core
>> function required to enable content delivery between interconnected CDNs and
>> therefore given the workload we already have to specify solutions that do
>> address the core functionality required to interconnect CDNs I do not think
>> we should be trying to add more work into that workload as it will only
>> distract us from achieving our goal of producing deployable solutions within
>> the timeframe we are being told by operators they needs solutions within.
>> 
>> Ben
>> 
>> 
>> 
>> 
>> 
>> So, if we all realize that currently the media type is rich, the CDN
>> providers should survive in the existing ecosystem and support the media
>> types as required by the market.
>> 
>> Back to the case of GSM/G.711, it just when concerning the interconnection,
>> the transformation should at once be solved. Otherwise the interconnection
>> may not be operated.
>> 
>> Br,
>> 
>> Zhipeng
>> 
>> -----Original Message-----
>> 
>> From: Ben Niven-Jenkins [mailto:[e-mail]]
>> 
>> Sent: Wednesday, October 12, 2011 12:19 AM
>> 
>> To: ZhouZhipeng
>> 
>> Cc: [e-mail]; [e-mail]
>> 
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Zhipeng,
>> 
>> On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
>> 
>> Ben and Philip,
>> 
>> I like to respond your concern in this one email:
>> 
>> Ben,
>> 
>> I feel what we are now discussing is what is the "core" function of CDN.
>> 
>> As you say, CDN is used to deliver content. That is absolutely correct that
>> the delivery capability is the core requirement for CDN system.
>> 
>> While CDN is used to provide the content delivery service.
>> 
>> What means service. It should include "time" "location" and "media type",
>> etc. These features are all the core feature for a service.
>> 
>> If we only concern "delivering one data block", I am not sure whether the
>> issues such as "logging" "geographic constraint" are the core of CDN.
>> 
>> For "without explicit knowledge of what that content actually is ", I am not
>> sure whether the wording is accurate since generally a CDN may claim it
>> support different medias.
>> 
>> By this opportunity, I like to share a use case: a call from a GSM phone to
>> a PSTN telephone, the voice stream should be transformed from GSM voice to
>> G.711.
>> 
>> For the user, he does not need to know what type of data has been
>> transferred, but the operator has done some work to interconnect two
>> systems, right.
>> 
>> I like to know whether you may accept that my use case is similar to this
>> case above.
>> 
>> I don't think your use case is similar to the analogy of mobile networks
>> being interconnected to PSTN networks. In the case of content delivery the
>> negotiation is done between the User/Client and the Content Provider and the
>> CDN is just used to execute/perform the delivery that has been negotiated.
>> The CDN is not involved in the decision making of what representations the
>> Content Provider decides to offer to the User/Client or in what
>> representations the User/Client decides to request.
>> 
>> As for you said selecting media by the "portal", you may see the way " uCDN
>> delivers multiple media streams to dCDN" is not good than "uCDN delivers one
>> media stream to dCDN and dCDN takes some adaptation to support multiple
>> media types".
>> 
>> Now what you're talking about is an optimisation, not a core function
>> required to actually deliver the content (and report, bill, etc. for that
>> delivery).
>> 
>> My position is that we should focus on how to enable the interconnection of
>> the core CDN functionality offered by CDNs today (which is also my
>> interpretation of  the scope of the CDNI working group as expressed in its
>> charter) because doing so is a significant piece of work in itself. Let's
>> not start trying to add in additional functionality beyond what the majority
>> of CDNs support today as that will just delay us getting usable
>> specifications into the market in a timely fashion IMO.
>> 
>> Ben
>> 
>> A good question is "security" since I have done six years on the DRM
>> 
>> and like to promote the DRM all around the world:) If the content is needed
>> to be protected, generally you may know all the systems should be granted by
>> the content owner.
>> 
>> Here I also like to clarify that not only the media itself but the
>> information related to service itself (such as the geographic constraint)
>> should be protected  also.
>> 
>> So, trust is not a problem for the media.
>> 
>> Philip,
>> 
>> Thank you that you feel Content Adaption is an issue for "Requirements" but
>> I do not know why it is not for Use case.
>> 
>> I like to clarify to U that it is important for you operator since it may
>> save investment if the system may support different services.
>> 
>> For us vendor, we are happy operator may install a system for the mobile
>> service and another system for the FBB service.
>> 
>> But the reality is all operators ask us to provide a system that may support
>> different service systems.
>> 
>> Frankly, Ben and Philip, I remember I have explained somewhere that to
>> implement this is rather simple .
>> 
>> At least the Use case and Requirement are informational to be referred in
>> future work. So I do really feel you may accept it.
>> 
>> Of course I like to respond your more concern and comments.
>> 
>> Thanks.
>> 
>> Zhipeng
>> 
>> -----Original Message-----
>> 
>> From: [e-mail] [mailto:[e-mail]]
>> 
>> Sent: Monday, October 10, 2011 11:22 PM
>> 
>> To: [e-mail]; ZhouZhipeng
>> 
>> Cc: [e-mail]
>> 
>> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Ben, Zhipeng, all,
>> 
>> I think that Content Adaptation is more an issue for the Requirements doc
>> than for the Use cases draft.
>> 
>> The key question is whether we want the CDNI interfaces to be able to cope
>> with a scenario where (say) HD/SD conversion is done in the dCDN & to signal
>> about this.
>> 
>> I think that coping with this scenario is a second order requirement, ie we
>> should not worry about it in the initial standards-track work. I don't know,
>> did we ever decide whether the Use cases doc is restricted to "initial"
>> scenarios, or whether it's all-encompassing, ie covering "future" scenarios
>> as well?
>> 
>> Scott,
>> 
>> Reading some of your examples, they seem to be valid even if content
>> adaptation (HD/SD) is out of scope.
>> 
>> - a dCDN might for some reason be unwilling to distribute HD?
>> 
>> - a CSP might want to make sure the dCDN can use HLS encapsulation?
>> 
>> But these sorts of examples seem to be static policy things (to do
>> 
>> with the capabilities & preferences of the CDNs & CSP), rather than
>> 
>> metadata associated with a particular piece of content. In the
>> 
>> discussion so far, I think negotiation about static policy stuff is
>> 
>> rather out of scope(?)
>> 
>> On security considerations, an interesting question is whether trust is
>> transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN
>> trusts dCDN doesn't mean that the CSP automatically trusts the dCDN.
>> However, i suspect this can get arbitrarily complex - so one possibility is
>> to say that we will only handle cases where the trust is transitive.
>> 
>> Best wishes
>> 
>> phil
>> 
>> Philip Eardley
>> 
>> Research and Technology Strategy
>> 
>> This email contains BT information, which may be privileged or confidential.
>> It's meant only for the individual(s) or entity named above. If you're not
>> the intended recipient, note that disclosing, copying, distributing or using
>> this information is prohibited. If you've received this email in error,
>> please let me know immediately on the email address above. Thank you. We
>> monitor our email system, and may record your emails.
>> 
>> British Telecommunications plc
>> 
>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in
>> 
>> England no: 1800000
>> 
>> -----Original Message-----
>> 
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> 
>> Of Ben Niven-Jenkins
>> 
>> Sent: 10 October 2011 12:04
>> 
>> To: ZhouZhipeng
>> 
>> Cc: [e-mail]
>> 
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Colleagues,
>> 
>> IMO Section 5.1.3 should be removed from the Use Cases draft. Content
>> Adaptation (i.e. taking in a content item in one format and transforming it
>> to another format or representation) is not a "core" function of a CDN which
>> typically delivers the content that is requested without explicit knowledge
>> of what that content actually is.
>> 
>> Let's not forget that in building an end to end content service the CDN is
>> only one component and is the component tasked with executing the delivery
>> of a specific representation (version/copy/format etc.) of the selected
>> content not the component tasked with deciding (or applying policy) on which
>> version/copy/representation of content should be delivered.
>> 
>> The decision as to which version/copy/representation to offer and allow to
>> be delivered to a given device/user is implemented outside of the CDN (e.g.
>> by the "portal" where the user first makes their content selection prior to
>> the CDN becoming involved in the delivery of the selected content).
>> 
>> Ben
>> 
>> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
>> 
>> Following Scott's comments on section 5.1.3, I feel Scott's description on
>> the use case of HD and SD is not exactly correct.
>> 
>> If one movie has two formats of HD and SD, then we have two content with
>> different identifier. In DRM scope, the basic unit is a content copy.
>> 
>> Here the first bullet "a subset of encodings deliverable to specific
>> devices," has listed the case of content adaptation.
>> 
>> In last month, I have contacted the Authors of this document and taken some
>> email exchanges with Grant and Philip (BT).
>> 
>> I have shown BT with some information that I know in this case and area to
>> explain the content flexibility is currently a basic requirement for CDN
>> service and related negotiation is needed in the CDN interconnection.
>> 
>> Meanwhile, I should also invite you in this group raising your comments or
>> questions on this case since I hope my use case may be incorporated in the
>> use case draft.
>> 
>> If you have any more question or comments, pls share in this thread.
>> 
>> Thanks.
>> 
>> Zhipeng
>> 
>> -----Original Message-----
>> 
>> From: Scott Wainner [mailto:[e-mail]]
>> 
>> Sent: Friday, September 30, 2011 8:02 AM
>> 
>> To: [e-mail]
>> 
>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> 
>> Section 2.3 Nomadic Users
>> 
>> This description falls under the category of Geographic Extension
>> 
>> yet the third paragraph states the case where a different device is
>> 
>> used in the same CDN coverage area.  The intent of this use case
>> 
>> needs to be clarified.  Perhaps the use case is trying to address
>> 
>> the scenario where a Nomadic User-A with an agreement allowing
>> 
>> access to content from CSP-A via uCDN moves to a dCDN in a different
>> 
>> region.  The dCDN is allowed to distribute the content of CSP-A to
>> 
>> User-A; however, not other users in the region of the dCDN are
>> 
>> allowed to retrieve the content unless they too have such an agreement.
>> 
>> Section 5.1.3 Content Encoding Restrictions Need to clarify if we're
>> 
>> talking about the restrictions on the delivery of specific content
>> 
>> or the restrictions on the ability of a CDN to deliver specific
>> 
>> content.  I certainly understand the case where a CSP will restrict
>> 
>> the distribution of content to a "managed path" if such content is
>> 
>> HD while allowing the content distribution via an un-managed path if
>> 
>> such content is SD (same could apply to encryption methods, delivery
>> 
>> methods, etc.).  On the contrary, the dCDN may have its own
>> 
>> restrictions of blocking the distribution of HD content while
>> 
>> allowing the distribution of SD content.
>> 
>> o first bullet makes sense if the dCDN can perform a subset of
>> 
>> encapsulations for a reference set of media (e.g. HLS, HSS, but not
>> 
>> DASH) o second bullet makes sense where the dCDN doesn't want to
>> 
>> offer high bit-rate variants of the media o third bullet make sense
>> 
>> if the policy addresses QoE but I don't think subscriber
>> 
>> rights/authorizations apply.
>> 
>> Section 10 Security Considerations
>> 
>> Aside from the security considerations WITHIN the uCDN and dCDN, I
>> 
>> think we can describe this in four contexts:
>> 
>> a. The relationship between the CSP and the uCDN (the principle contract
>> 
>> arrangement for distribution)
>> 
>> b. The relationship between the uCDN and dCDN (the transitive trust
>> 
>> relationship that extends the contract defined in (a) above) c. The
>> 
>> relationship between the User and dCDN (the recognition of right to
>> 
>> download predicated on (b) above) d. The relationship between the
>> 
>> User and CSP (the contract authorizing the user access to the
>> 
>> content)
>> 
>> The user is not interested in the a-b nor the b-c relationship. The
>> 
>> user is only interested in the transparency and interoperability of
>> 
>> the security relationship between d-b or d-c to the point that the
>> 
>> authorization granted in d-a is viable when the delivery is
>> 
>> initiated via either d-b or d-c.  As an example, the uCDN might use
>> 
>> URL appended tokens for authentication while dCDN might use URL
>> 
>> appended hashes.  The user doesn't want to know about the distinct
>> 
>> methods, but transparency is only afforded if the methods are
>> 
>> interoperable clearly defined when the delegation for content
>> 
>> delivery is executed.  Clearly, the choice of authentication method is
>> determined by the respective CDN's.
>> 
>> Scott
>> 
>> _______________________________________________
>> 
>> CDNi mailing list
>> 
>> [e-mail]
>> 
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> _______________________________________________
>> 
>> CDNi mailing list
>> 
>> [e-mail]
>> 
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> 
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> 
>> 
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> <image001.jpg>
>> 
>> 
>> 
>> 
>> Francois Le Faucheur
>> Distinguished Engineer
>> Corporate Development
>> [e-mail]
>> Phone: [phone]
>> Mobile: [phone]
>> 
>> 
>> Cisco Systems France
>> Greenside
>> 400 Ave de Roumanille
>> 06410 Sophia Antipolis
>> France
>> Cisco.com
>> 
>> 
>> 
>> 
>> <image002.gif>
>> 
>>  Think before you print.
>> 
>> 
>> This email may contain confidential and privileged material for the sole use
>> of the intended recipient. Any review, use, distribution or disclosure by
>> others is strictly prohibited. If you are not the intended recipient (or
>> authorized to receive for the recipient), please contact the sender by reply
>> email and delete all copies of this message.
>> 
>> Cisco Systems France, Société à responsabiité limitée, Rue Camille
>> Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux,
>> Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la
>> publication: Jean-Luc Michel Givone.
>> 
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>> 
>> 
>> 
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> 
>> 
>> 
>> _______________________________________________
>> CDNi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cdni
>> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni