Re: [CDNi] 答复: Preparing draft-ietf-cdni-problem-statement for WG Last Call

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Mon, 24 October 2011 14:35 UTC

Return-Path: <ben@niven-jenkins.co.uk>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6A21F8E4E for <cdni@ietfa.amsl.com>; Mon, 24 Oct 2011 07:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.85
X-Spam-Level:
X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfg3BnZ19KME for <cdni@ietfa.amsl.com>; Mon, 24 Oct 2011 07:35:32 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC8A521F8E47 for <cdni@ietf.org>; Mon, 24 Oct 2011 07:35:31 -0700 (PDT)
Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1RILcg-0004EV-AT; Mon, 24 Oct 2011 15:35:30 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="GB2312"
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
In-Reply-To: <FB5FB22A028BA44DAC87981CED1F0B4F15EFFA06@szxeml524-mbx.china.huawei.com>
Date: Mon, 24 Oct 2011 15:35:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEC849E4-4D2C-40E3-A031-A39A3C7ADB8A@niven-jenkins.co.uk>
References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <FB5FB22A028BA44DAC87981CED1F0B4F15EFFA06@szxeml524-mbx.china.huawei.com>
To: Will Li <lijincheng@huawei.com>
X-Mailer: Apple Mail (2.1084)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Cc: "cdni@ietf.org" <cdni@ietf.org>
Subject: Re: [CDNi] 答复: Preparing draft-ietf-cdni-problem-statement for WG Last Call
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 14:35:33 -0000

Will,

Thanks for reviewing the draft & proposed changes, my opinion is inline below.

On 19 Oct 2011, at 10:24, Will Li(jincheng) wrote:

> Hi, Ben,
> 
> Thank you for the efforts. Two more comments.
> 1) In section 3, do you think it is helpful to add some description on each role (i.e. CP, Upstream CDN, Downstream CDN), and their business relationships assumed in CDNI?
>  This could facilitate people to understand the figure and the draft better.

The different roles are defined as part of the terminology in Section 1.1.

I don't think the Problem Statement draft should try to describe the different business relationships as they are many and varied depending on things like the purpose of the specific CDN, the market it is deployed in etc and it would be very difficult to describe all the different business relationships and we would risk getting distracted by comments along the lines of "what about this business relationship that you haven't described" and "you haven't adequately captured how this relationship could work" etc.

Section 1.2 already states that "Readers are assumed to be familiar with the architecture, features and operation of CDNs." and I assume if readers already have that familiarity with how CDNs work & are operated then they can understand how CSPs, upstream CDNs, downstream CDNs may fit together as part of the CDNI reference model.
 
> 
> 2)Another editorial one: In bullet 5 of your previous mail, changing ITU to ITU-T could be more specific.

Good catch! I will use ITU-T when I update the draft.

Ben

> 
> BR, Will 
> 
> -----邮件原件-----
> 发件人: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] 代表 Ben Niven-Jenkins
> 发送时间: 2011年10月17日 19:08
> 收件人: cdni@ietf.org
> 主题: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call
> 
> Colleagues,
> 
> At the last IETF I said I would try to prepare a version of the CDNI problem Statement (draft-ietf-cdni-problem-statement) that is ready for WG Last Call before IETF82 in Taipei.
> 
> As part of that I have reviewed the complete draft and made some minor editorial clean-ups to my working copy. However, there were a number of other areas where I think changes need to be made to the document that I think warrant wider WG review/consensus and I have listed them below along with the changes I am proposing.
> 
> Could you please provide your feedback on the areas/proposed text I have highlighted below as well as any other areas of the document that you think require additional work/cleanup before you consider the document is ready for a WG Last Call.
> 
> 1) Section 2: Update the last paragraph to reference the WG draft for CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e.
> 
> OLD:
>   Use cases for CDN Interconnection are further discussed in
>   [I-D.bertrand-cdni-use-cases] (which contains a merged set of use
>   cases previously presented in [I-D.watson-cdni-use-cases] and
>   [I-D.bertrand-cdni-use-cases-00]).
> NEW:
>   Use cases for CDN Interconnection are further discussed in
>   [I-D.ietf-cdni-use-cases].
> 
> 
> 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) that are each just a couple of sentences, so I propose merging them into a single section and changing the first two sentences of section 4 appropriately, i.e.
> 
> OLD:
>   This section expands on how CDNI interfaces can reuse and leverage
>   existing protocols.  First the "reuse instead of reinvent" design
>   principle is restated, then each inetrface is discussed individually
>   with example candidate protocols that can be considered for reuse or
>   leverage. 
> NEW:
>   This section expands on how CDNI interfaces can reuse and leverage
>   existing protocols before describing each CDNI interface individually
>   and highlighting example candidate protocols that could considered for
>   reuse or leveraging to implement the CDNI interfaces.  
> 
> 
> 3) Section 5 is currently title "Gap Analysis of relevant Standardisation and Research Activities" but following the agreement at the last IETF to move the generic descriptions of other activities into an appendix Section 5 no longer references any research activities so I propose changing the title to" Gap Analysis of relevant Standardisation activities".
> 
> 4) After the general introduction in Section 5 there are only sections that outline other research activities for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the other CDNI interfaces (Control, Logging, Request Routing).
> 
> The reason for the lack of text is IMO because there is no current or past standardisation activity addressing those areas but the document currently does not mention that and therefore gives the impression of being incomplete.
> 
> I therefore propose making the following change to the last sentence in Section 5:
> 
> OLD:
>   The following sections will summarize the existing work of the
>   standard bodies above against the CDNI problem space.
> NEW:
>   The following sections will summarize the existing work of the
>   standard bodies above against the CDNI problem space. Section 5.1
>   summarises existing interfaces that could be leveraged for content
>   acquisition between CDNs and Section 5.2 summarises existing metadata 
>   specifications that may be applicable to CDNI. To date there is no
>   existing standardisation activities in the areas of the remaining
>   CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI Logging).
> 
> 5) I also propose using the following text for the third bullet in Section 5 unless someone can suggest more appropriate text to summarise in a sentence or two any CDN metadata related work in other standards bodies.
> 
> OLD:
>   o  <TODO: Add a sentence on ITU>
> NEW:
>   o  CableLabs, SNIA and ITU have defined (or are working on)
>      definitions for content related metadata definitions and specification
>      for its distribution. However, they do not include metadata specific
>      to the distribution of content within a CDN or between interconnected
>      CDNs.
> 
> 6) Section 10.1 lists a number of "normative references", if we adopt the proposed changes above it will end up containing "normative" references to:
>   - draft-ietf-cdni-use-cases
>   - draft-bertrand-cdni-experiements
>   - draft-jenkins-cdni-names
>   - RFC2119
> 
> After reading through the text of the Problem Statement again, I am not convinced that the Problem Statement references any of those documents normatively as the 3 CDNI related drafts are referenced in a context where they are for further information and the Problem Statement does not make use of any of the capitalised terms defined in RFC2119.
> 
> Therefore, unless anyone objects I will move the references for the three CDNI related drafts to the "Informative References" section and remove the reference for RFC2119.
> 
> 
> Thanks
> Ben
> 
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni