From flefauch@cisco.com Mon Jun 3 07:56:15 2013 Return-Path: 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 58FB921F999E for ; Mon, 3 Jun 2013 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 vb4tfm18Nfzz for ; Mon, 3 Jun 2013 07:56:10 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1721F8E37 for ; Mon, 3 Jun 2013 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1836; q=dns/txt; s=iport; t=1370271370; x=1371480970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vsus7aXauWMmd3EihZDiapn6jZU4fXNrckKmNaB/cjA=; b=Nk1IGu8AXUyQ0UoZxKkdivnilzgXMCVLBqsNY1oszB3Gi/GXDHMn/0tF aOePAQQ86gWW1+WVr+0zjRHxwFS1wQpWtqzZkAKyf2zjPlmBP4xZu5xss VLdG/5w6FSZLdNCDt//LyTRMF3Nn5VS5PkwTPbG/GA5qe6vanwiXatUOt U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANStrFGtJV2c/2dsb2JhbABZgwkwvn+BARZ0giMBAQEDAQEBAWsLBQsCAQgiJCcLJQIEDgUIE4dsBgy7ZY50AjEHgndhA5hnkBeDD4FoBzg X-IronPort-AV: E=Sophos;i="4.87,793,1363132800"; d="scan'208";a="218092877" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jun 2013 14:56:10 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r53EuALM022557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 14:56:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 3 Jun 2013 09:56:10 -0500 From: "Francois Le Faucheur (flefauch)" To: David Mandelberg Thread-Topic: [CDNi] non-repudiation questions Thread-Index: AQHOXVok6cteIjcwN06LPDHgP/SjfpkkbhOA Date: Mon, 3 Jun 2013 14:56:09 +0000 Message-ID: References: <203799ab055aceac432998afe6bca638@mail.mandelberg.org> In-Reply-To: <203799ab055aceac432998afe6bca638@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] non-repudiation questions 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 14:56:15 -0000 Hi David, On 30 May 2013, at 19:28, David Mandelberg wrote: > Hi, >=20 > What are the goals of non-repudiation of logging data? I've listed two > possibilities below. Are those right? Is there anything else that people > want non-repudiation to do for them? >=20 > * Audits: If a uCDN detects a problem that's supported by logging > information, the dCDN can't claim that they never supplied that logging > information or that the information was modified in transit. > * Billing: Once a uCDN receives a log file, the dCDN can't claim that > there are additional records that are missing from that file. (But they c= an > still add those records to a future log file.) I think what the Non-Repudiation-Signature will bring is a mechanism for th= e uCDN to prove that a Logging File is exactly as was transmitted by the dC= DN (with no more information, no less information, no different information= ). I think we should explain that generic benefit of the Non-Repudiation me= chanism. Then we can give practical examples of how that may be used (e.g. = your "Audit" benefit above, your "Logging" benefit above, but also other "L= ogging" benefits like the dCDN cannot claim that it did not send a particul= ar log line with "cheated" information like excessive amount of bytes,=85) = but I don't think we need to try be exhaustive in the list of example usage= s. Francois >=20 > Also, how would dCDNs be willing to protect their private keys? If dCDNs > don't want to use hardware security modules, I'd recommend a solution tha= t > uses ephemeral keys. >=20 > --=20 > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From david@mandelberg.org Tue Jun 4 15:13:45 2013 Return-Path: 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 8C33721F999F for ; Tue, 4 Jun 2013 15:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 QHPVqplFWsGC for ; Tue, 4 Jun 2013 15:13:41 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 2626721F9995 for ; Tue, 4 Jun 2013 15:13:26 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta04.westchester.pa.mail.comcast.net with comcast id kDB31l00217dt5G54NDSrj; Tue, 04 Jun 2013 22:13:26 +0000 Received: from uriel.mandelberg.org ([IPv6:2001:4830:11a7:2:216:3eff:fe0e:b38c]) by omta13.westchester.pa.mail.comcast.net with comcast id kNDP1l0121djk4J3ZNDRDB; Tue, 04 Jun 2013 22:13:26 +0000 Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id 22E241C6117 for ; Tue, 4 Jun 2013 18:21:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_162f193914144a6551001a5c24f69018" Date: Tue, 04 Jun 2013 18:21:04 -0400 From: David Mandelberg To: Message-ID: <9a43c4896f34ca72acf5bf98745af6bd@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: RoundCube Webmail/0.3.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370384006; bh=JNt8507maShc+J2m4BuDCUpaQWEpe3DVA31Raoj2gSc=; h=Received:Received:Received:MIME-Version:Content-Type:Date:From:To: Subject:Message-ID; b=i1nrmGNAfW3moLEejoaPWfApciADuk+9Gm6F6TVi6A1I1QqUyp/SfBEYcTYdB54cn 3/MqtlTinxbG8WuxgC/8tNnV0luHPMe7SXC8IEOBqkZi9SCCf4Y8jIQ8OZFdoRVtTd eizdYulFrXhf58gVzyvrwn+oB+wKpsEMa3EewQbiHPygp3iub7S4y1k1Md45XKYKYY bf86HNbvlT5Xd3s5/lm2tPDwlWXAaWnB91EJSEtnkPpPB5IER1yPUVOgW3wbmQ4M1n 3p0begA0AR7pSMlRnmvBp6u2s2DwivyLT1iCIjo+OcNP8MZ1QG9DFyhKFhSnbrGdor XVs2AZ75Xsqng== Subject: [CDNi] non-repudiation text 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 22:13:45 -0000 --=_162f193914144a6551001a5c24f69018 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi, I've attached a first draft of some text for non-repudiation. It has two open issues that I know about: 1. I'd like to provide a sensible default for the maximum lifespan of ephemeral keys, but I'm not sure what is reasonable in this context. On the CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does anybody have input about the security of 1 hour/day/month? 2. The text I wrote is not compatible with Integrity-Hash. I could update it to work with Integrity-Hash, but I think it might be easier to just say "Integrity-Hash and non-repudiation MUST NOT be used in the same log file" since non-repudiation provides for integrity anyway. Thoughts? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ --=_162f193914144a6551001a5c24f69018 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=us-ascii; charset=UTF-8; name=draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt Content-Disposition: attachment; filename=draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt Mi4zLiBOb24tUmVwdWRpYXRpb24KCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgbm9uLXJlcHVk aWF0aW9uIHdpdGggcHJvb2Ygb2Ygb3JpZ2luIGZvciBsb2dnaW5nIGluZm9ybWF0aW9uLiBUaGUg dGVybSAibm9uLXJlcHVkaWF0aW9uIHdpdGggcHJvb2Ygb2Ygb3JpZ2luIiBpcyBkZWZpbmVkIGlu IFtSRkM0OTQ5XS4gRm9yIGJyZXZpdHksIHRoZSB0ZXJtICJub24tcmVwdWRpYXRpb24iIHdpbGwg YmUgdXNlZCB0byBtZWFuICJub24tcmVwdWRpYXRpb24gd2l0aCBwcm9vZiBvZiBvcmlnaW4iIGlu IHRoaXMgZG9jdW1lbnQuIEltcGxlbWVudGF0aW9ucyBvZiB0aGUgQ0ROSSBMb2dnaW5nIEludGVy ZmFjZSBTSE9VTEQgc3VwcG9ydCBub24tcmVwdWRpYXRpb24uIEhvd2V2ZXIsIGltcGxlbWVudGF0 aW9ucyB0aGF0IHN1cHBvcnQgbm9uLXJlcHVkaWF0aW9uIFNIT1VMRCBOT1QgbWFuZGF0ZSB0aGUg dXNlIG9mIG5vbi1yZXB1ZGlhdGlvbi4gSW4gdGhlIENETkkgTG9nZ2luZyBJbnRlcmZhY2UsIG5v bi1yZXB1ZGlhdGlvbiBjYW4gYmUgdXNlZCB0bzoKICAgCiAgIDEuIHByb3RlY3QgdGhlIGF1dGhl bnRpY2l0eSBvZiBsb2dnaW5nIGluZm9ybWF0aW9uIGZyb20gbW9ua2V5LWluLXRoZS1taWRkbGUg YXR0YWNrcy4KICAgMi4gcHJvdGVjdCBhIHVDRE4gcmVjZWl2aW5nIGxvZ2dpbmcgaW5mb3JtYXRp b24gZnJvbSBhIGNoZWF0aW5nIGRDRE4uCiAgIDMuIGRpc3N1YWRlIGRDRE5zIGZyb20gY2hlYXRp bmcgdUNETnMuCgogICBGb3IgZXhhbXBsZSwgYSBjaGVhdGluZyBkQ0ROIGNvdWxkIGNsYWltIHRv IGhhdmUgc2VydmVkIG1vcmUgdHJhZmZpYyB0aGFuIGl0IGFjdHVhbGx5IGRpZC4gV2hlbiB0aGUg dUNETiBjb25kdWN0cyBhbiBhdWRpdCBhbmQgZGlzY292ZXJzIHRoZSBmYWxzZSBjbGFpbSwgbm9u LXJlcHVkaWF0aW9uIHByZXZlbnRzIHRoZSBkQ0ROIGZyb20gY2xhaW1pbmcgdGhhdCB0aGUgaW5m b3JtYXRpb24gd2FzIG1vZGlmaWVkIGluIHRyYW5zaXQgKDEpIG9yIHRoYXQgdGhlIHVDRE4gZmFs c2lmaWVkIHRoZSBpbmZvcm1hdGlvbiAoMikuIEFkZGl0aW9uYWxseSwgdGhlIGRDRE4ncyBrbm93 bGVkZ2UgdGhhdCB0aGV5IGNvdWxkIGJlIGNhdWdodCBtYXkgZGlzc3VhZGUgdGhlbSBmcm9tIGNo ZWF0aW5nIGluIHRoZSBmaXJzdCBwbGFjZSAoMykuCgoyLjMuMS4gTm9uLVJlcHVkaWF0aW9uIFBy b2Nlc3MKCiAgIE5vbi1yZXB1ZGlhdGlvbiBpcyBwZXJmb3JtZWQgdXNpbmcgZXBoZW1lcmFsIGFz eW1tZXRyaWMga2V5cyBhbmQgZGlnaXRhbCBzaWduYXR1cmVzLiBUaGUgdXNlIG9mIGVwaGVtZXJh bCBrZXlzIG1pbmltaXplcyB0aGUgYnVyZGVuIG9uIHByaXZhdGUga2V5IGhvbGRlcnMgdG8gcHJv dGVjdCB0aGVpciBwcml2YXRlIGtleXMuIEFkZGl0aW9uYWx5LCB0aGUgbWV0aG9kIG9mIHN3aXRj aGluZyBmcm9tIG9uZSBlcGhlbWVyYWwga2V5IHRvIHRoZSBuZXh0IHByb3ZpZGVzIG5vbi1yZXB1 ZGlhdGlvbiBvZiB0aGUgImdhcHMiIGJldHdlZW4gbG9nIGZpbGVzLiBUaGF0IGlzLCBvbmNlIGEg ZENETiB0cmFuc21pdHMgdHdvIGxvZyBmaWxlcyBpbiBzZXF1ZW5jZSwgdGhlIGZhY3QgdGhhdCBu byB0aGlyZCBsb2cgZmlsZSBjYW1lIGJldHdlZW4gdGhvc2UgdHdvIGlzIGNyeXB0b2dyYXBoaWNh bGx5IGNsYWltZWQgYnkgdGhlIGRDRE4gYW5kIGNhbiBiZSB2ZXJpZmllZCBieSB0aGUgdUNETi4K ICAgCiAgIFRoZSByZXN0IG9mIHRoaXMgc2VjdGlvbiBwcm92aWRlcyBhbiBvdmVydmlldyBvZiB0 aGUgcHJvY2VzcyB1c2VkIHRvIHByb3ZpZGUgbm9uLXJlcHVkaWF0aW9uLiBUaGUgdGVybSAib3Jp Z2luYXRvciIgbWVhbnMgdGhlIGVudGl0eSAoZENETikgdGhhdCBpcyBzZW5kaW5nIGxvZyBmaWxl czsgInJlY2VpdmVyIiBtZWFucyB0aGUgZW50aXRpeSAodUNETikgcmVjZWl2aW5nIGxvZyBmaWxl cy4KCiAgIDEuIFRoZSBvcmlnaW5hdG9yIGdlbmVyYXRlcyBhbiBpbml0aWFsIGtleSBwYWlyLgoK ICAgMi4gVGhlIG9yaWdpbmF0b3IgdGFrZXMgdGhlIGhhc2ggb2YgdGhlIHB1YmxpYyBrZXkgYW5k IHByb3ZpZGVzIGl0IHRvIHRoZSByZWNlaXZlciB2aWEgYSBjaGFubmVsIHRoYXQgcHJvdGVjdHMg aW50ZWdyaXR5IGFuZCBhdXRoZW50aWNpdHkuIEZvciBleGFtcGxlLCB0aGUgaGFzaCBvZiB0aGUg cHVibGljIGtleSBjb3VsZCBiZSBleGNoYW5nZWQgaW4gcGVyc29uIHdoZW4gYSBjb250cmFjdCBp cyBzaWduZWQuIEhvd2V2ZXIsIHRoZSBleGFjdCBjaGFubmVsIHVzZWQgaXMgb3V0IG9mIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuIAoKICAgMy4gRm9yIGVhY2ggbG9nIGZpbGU6CgogICAgICAxLiBU aGUgb3JpZ2luYXRvciBnZW5lcmF0ZXMgYSBuZXcga2V5IHBhaXIuCgogICAgICAyLiBUaGUgb3Jp Z2luYXRvciBpbmNsdWRlcyB0aGUgaGFzaCBvZiB0aGUgbmV3IHB1YmxpYyBrZXkgKE5vbi1SZXB1 ZGlhdGlvbi1OZXh0LVB1YmxpYy1LZXktSGFzaCBpbiBTZWN0aW9uIDMuMSkgYW5kIHRoZSBlbnRp cmUgY3VycmVudCBwdWJsaWMga2V5IChOb24tUmVwdWRpYXRpb24tUHVibGljLUtleSkgaW4gdGhl IGxvZyBmaWxlLiBUaGUgb3JpZ2luYXRvciB0aGVuIHVzZXMgdGhlIGN1cnJlbnQgcHJpdmF0ZSBr ZXkgdG8gc2lnbiBib3RoIHRoZSBhdHRlc3RhdGlvbiBvZiB0aGUgbmV4dCBwdWJsaWMga2V5IChO b24tUmVwdWRpYXRpb24tQ2hhaW5pbmctU2lnbmF0dXJlKSBhbmQgdGhlIHJlc3Qgb2YgdGhlIGxv ZyBmaWxlIChOb24tUmVwdWRpYXRpb24tRGF0YS1TaWduYXR1cmUpCgogICAgICAzLiBUaGUgb3Jp Z2luYXRvciBzZWN1cmVseSBkZWxldGVzIHRoZSBjdXJyZW50IHByaXZhdGUga2V5LCB0aGVuIGNv bnNpZGVycyB0aGUgbmV3IGtleSBwYWlyIHRvIGJlIHRoZSBjdXJyZW50IGtleSBwYWlyLgoKICAg ICAgNC4gT24gcmVjZWlwdCBvZiB0aGUgbG9nIGZpbGUsIHRoZSByZWNlaXZlciB2ZXJpZmllcyB0 aGF0IHRoZSBwdWJsaWMga2V5IGluIHRoZSBsb2cgZmlsZSBtYXRjaGVzIHRoZSBoYXNoIGluIHRo ZSBwcmV2aW91cyBsb2cgZmlsZSAob3IgdGhlIGluaXRpYWwgaGFzaCBpZiB0aGlzIGlzIHRoZSBm aXJzdCBsb2cgZmlsZSkgYW5kIHRoYXQgdGhlIHNpZ25hdHVyZXMgYXJlIHZhbGlkLgoKICAgVGhl IHJlY2VpdmVyIE1VU1QgcmV0YWluIGVub3VnaCBpbmZvcm1hdGlvbiB0byBkZXRlY3QgcmV1c2Ug b2Ygc3VwcG9zZWRseSBlcGhlbWVyYWwga2V5cy4gVGhpcyBjYW4gYmUgZG9uZSBieSBzdG9yaW5n IGEgbGlzdCBvZiBwdWJsaWMga2V5IGhhc2hlcy4gSWYgYSBsb2cgZmlsZSBjb250YWlucyBhIE5v bi1SZXB1ZGlhdGlvbi1OZXh0LVB1YmxpYy1LZXktSGFzaCBvciBOb24tUmVwdWRpYXRpb24tUHVi bGljLUtleSB2YWx1ZSBjb3JyZXNwb25kaW5nIHRvIGEgcHVibGljIGtleSB0aGF0IGhhcyBhbHJl YWR5IGJlZW4gdXNlZCwgdGhlIHJlY2VpdmVyIE1VU1QgTk9UIHRydXN0IHRoZSBsb2cgZmlsZS4K CiAgIEJvdGggdGhlIG9yaWdpbmF0b3IgYW5kIHRoZSByZWNlaXZlciBTSE9VTEQgcmV0YWluIGVu b3VnaCBpbmZvcm1hdGlvbiB0byBzdXBwb3J0IGFmdGVyLXRoZS1mYWN0IG5vbi1yZXB1ZGlhdGlv biBvZiBhbnkgbG9nIGZpbGUuIFRoaXMgaW5jbHVkZXMgdGhlIGludGl0aWFsIHB1YmxpYyBrZXkg aGFzaCBmcm9tIHN0ZXAgMiBhbmQgY2VydGFpbiBsb2cgZmlsZSBkaXJlY3RpdmVzIGFzIHNwZWNp ZmllZCBpbiBTZWN0aW9uIDMuMSBmb3IgYWxsIGxvZyBmaWxlcyBnZW5lcmF0ZWQgb3IgcmVjZWl2 ZWQuIFRvIHNhdmUgc3RvcmFnZSBzcGFjZSwgYW4gZW50aXR5IE1BWSBleHRyYWN0IHRoZSBkaXJl Y3RpdmVzLXRvLXJldGFpbiBhbmQgc3RvcmUgdGhlbSBzZXBhcmF0ZWx5IGZyb20gdGhlIGxvZyBm aWxlcy4gV2hlbiBzdG9yaW5nIHRob3NlIGRpcmVjdGl2ZXMgc2VwYXJhdGVseSwgdGhlIG9yaWdp bmFsIG9yZGVyIG9mIHRoZSBsaW5lcyBhbmQgdGhlIG9yaWdpbmFsIGxpbmUgZW5kaW5ncyBNVVNU IGJlIHByZXNlcnZlZCBpbiBvcmRlciBmb3IgdGhlIHNpZ25hdHVyZXMgdG8gYmUgdmVyaWZpYWJs ZS4KCiAgIElmIHRoZSBvcmlnaW5hdG9yIGRpc2NvdmVycyB0aGF0IHRoZWlyIGN1cnJlbnQgcHJp dmF0ZSBrZXkgaGFzIGJlZW4gY29tcHJvbWlzZWQsIHRoZXkgTVVTVCBOT1QgdXNlIHRoZSBwcml2 YXRlIGtleSBhbmQgdGhleSBNVVNUIGluZm9ybSB0aGUgcmVjZWl2ZXIgdGhhdCB0aGUga2V5IGhh cyBiZWVuIGNvbXByb21pc2VkLiBUaGV5IE1BWSB0aGVuIHN0YXJ0IHRoZSBwcm9jZXNzIGFnYWlu IGZyb20gc3RlcCAxLiBJZiB0aGUgb3JpZ2luYXRvciBkaXNjb3ZlcnMgdGhhdCBhIHByZXZpb3Vz IHByaXZhdGUga2V5IHdhcyBjb21wcm9taXNlZCwgdGhleSBNVVNUIGRldGVybWluZSB3aGV0aGVy IHRoZSByZWNlaXZlciBzdGlsbCB0cnVzdHMgdGhhdCBrZXkuIElmIHRoZSByZWNlaXZlciBoYXMg bW92ZWQgb24gYW5kIG5vdyB0cnVzdHMgYSBuZXdlciAobm9uLWNvbXByb21pc2VkKSBrZXksIG5v IGZ1cnRoZXIgYWN0aW9uIGlzIG5lY2Vzc2FyeSBiZWNhdXNlIHRoZSByZWNlaXZlciB3aWxsIG9u bHkgdHJ1c3Qga2V5cyBzaWduZWQgYnkgdGhlIG5ld2VyIChub24tY29tcHJvbWlzZWQpIGtleS4g SWYgdGhlIHJlY2VpdmVyIHN0aWxsIHRydXN0cyB0aGUgY29tcHJvbWlzZWQga2V5LCB0aGVuIHRo ZSBvcmlnaW5hdG9yIE1VU1QgaW5mb3JtIHRoZSByZWNlaXZlciB0aGF0IHRoZSBrZXkgaGFzIGJl ZW4gY29tcHJvbWlzZWQgYW5kIHRoZXkgTUFZIHN0YXJ0IHRoZSBwcm9jZXNzIGFnYWluIGZyb20g dGhlIHN0YXJ0LiBIb3cgdGhlIG9yaWdpbmF0b3IgZGV0ZXJtaW5lcyB3aGljaCBrZXkgaXMgdHJ1 c3RlZCBieSB0aGUgcmVjZWl2ZXIgYW5kIGluZm9ybXMgdGhlIHJlY2VpdmVyIG9mIGEgY29tcHJv bWlzZSBhcmUgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgogICBUbyBtaW5pbWl6ZSB0 aGUgcmlzayBmcm9tIGEga2V5IGNvbXByb21pc2UsIHRoZSBlcGhlbWVyYWwga2V5cyBzaG91bGQg YmUgcm90YXRlZCBmcmVxdWVudGx5LiBUbyBhY2NvbXBsaXNoIHRoaXMsIHRoZSBvcmlnaW5hdG9y IGFuZCByZWNlaXZlciBTSE9VTEQgZGV0ZXJtaW5lIGEgbXV0dWFsbHkgYWdyZWVhYmxlIG1heGlt dW0ga2V5IGxpZmVzcGFuLiBbVE9ETzogcHJvdmlkZSBhIHNlbnNpYmxlIGRlZmF1bHQuXSBUaGVu LCBpZiBhIGtleSBpcyBhcHByb2FjaGluZyB0aGUgZW5kIG9mIGl0cyBsaWZldGltZSwgdGhlIG9y aWdpbmF0b3IgYW5kIHJlY2VpdmVyIE1VU1QgcGVyZm9ybSBzdGVwIDMgYWJvdmUuIElmIHRoZSBv cmlnaW5hdG9yIGRvZXMgbm90IGhhdmUgYW55IGxvZ2dpbmcgaW5mb3JtYXRpb24gcmVhZHksIHRo ZSBsb2cgZmlsZSB1c2VkIE1BWSBjb250YWluIHplcm8gTG9nZ2luZyBSZWNvcmRzLgoKMi4zLjIu IE5vbi1SZXB1ZGlhdGlvbiBBbGdvcml0aG1zCgogICBBIGtleSBwYWlyIHVzZWQgZm9yIG5vbi1y ZXB1ZGlhdGlvbiBNVVNUIGJlIFJTQSB3aXRoIGEgMjA0OC1iaXQgbW9kdWx1cyBhbmQgYSBwdWJs aWMgZXhwb25lbnQgKGUpIG9mIDY1LDUzNy4gUHVibGljIGtleXMgdHJhbnNtaXR0ZWQgYnkgdGhl IExvZ2dpbmcgSW50ZXJmYWNlIE1VU1QgYmUgZW5jb2RlZCBhcyB0aGUgQmFzZTY0IFtSRkM0NjQ4 XSBlbmNvZGluZyBvZiB0aGUgREVSIFtYLjY5MF0gZW5jb2Rpbmcgb2YgUlNBUHVibGljS2V5IFtS RkM0MDU1XS4gSGFzaGVzIG9mIHB1YmxpYyBrZXlzIE1VU1QgdXNlIHRoZSBERVIgZW5jb2Rpbmcg b2YgUlNBUHVibGljS2V5LgoKICAgQWxsIGhhc2hlcyB1c2VkIGZvciBub24tcmVwdWRpYXRpb24g TVVTVCBiZSBTSEEtMjU2IFtTSFNdLiBIYXNoZXMgdHJhbnNtaXR0ZWQgYnkgdGhlIExvZ2dpbmcg SW50ZXJmYWNlIE1VU1QgYmUgZW5jb2RlZCBhcyBoZXhhZGVjaW1hbC4KCiAgIFRoZSBzaWduYXR1 cmUgYWxnb3JpdGhtIHVzZWQgZm9yIG5vbi1yZXB1ZGlhdGlvbiBNVVNUIGJlIFJTQSBQdWJsaWMt S2V5IENyeXB0b2dyYXBoeSBTdGFuZGFyZHMgKFBLQ1MpICMxIFZlcnNpb24gMS41IGZyb20gU2Vj dGlvbiA1IG9mIFtSRkM0MDU1XSBjb21iaW5lZCB3aXRoIHRoZSBhYm92ZSBoYXNoIGFsZ29yaXRo bSwgUlNBIFBLQ1MjMSB2MS41IHdpdGggU0hBLTI1Ni4gU2lnbmF0dXJlcyB0cmFuc21pdHRlZCBi eSB0aGUgTG9nZ2luZyBJbnRlcmZhY2UgTVVTVCBiZSBlbmNvZGVkIGFzIEJhc2U2NC4KCjMuMS4g Q0ROSSBMb2dnaW5nIEZpbGUgRGlyZWN0aXZlcwoKW1RPRE86IGNoYW5nZSBJbnRlZ3JpdHktSGFz aCB0byBiZSBtdXR1YWxseSBleGNsdXNpdmUgd2l0aCBub24tcmVwdWRpYXRpb24sIG9yIHVwZGF0 ZSB0aGUgYmVsb3cgdGV4dCB0byB3b3JrIHdpdGggSW50ZWdyaXR5LUhhc2hdCgogICAqICBOb24t UmVwdWRpYXRpb24tSGFzaC1BbGdvcml0aG06CgogICAgICAqICBmb3JtYXQ6IDxzdHJpbmc+Cgog ICAgICAqICBzZW1hbnRpYzogVGhpcyBpcyB0aGUgaGFzaCBhbGdvcml0aG0gdXNlZCBmb3Igbm9u LXJlcHVkaWF0aW9uLiBJZiBwcmVzZW50LCBpdCBNVVNUIGJlIGV4YWN0bHkgInNoYTI1NiIuCgog ICAgICAqICBvY2N1cmVuY2U6IElmIG5vbi1yZXB1ZGlhdGlvbiBpcyBub3QgaW4gdXNlLCB0aGlz IE1VU1QgTk9UIGJlIHByZXNlbnQuIElmIG5vbi1yZXB1ZGlhdGlvbiBpcyBpbiB1c2UsIHRoaXMg TVVTVCBvY2N1ciBleGFjdGx5IG9uY2UgYW5kIE1VU1QgYmUgdGhlIHNlY29uZCBsaW5lIG9mIHRo ZSBDRE5JIExvZ2dpbmcgRmlsZS4KCiAgICAgICogIHJldGFpbm1lbnQ6IFRoaXMgZGlyZWN0aXZl IFNIT1VMRCBiZSByZXRhaW5lZCB0byBzdXBwb3J0IGFmdGVyLXRoZS1mYWN0IG5vbi1yZXB1ZGlh dGlvbi4KCiAgICogIE5vbi1SZXB1ZGlhdGlvbi1TaWduYXR1cmUtQWxnb3JpdGhtOgoKICAgICAg KiAgZm9ybWF0OiA8c3RyaW5nPgoKICAgICAgKiAgc2VtYW50aWM6IFRoaXMgaXMgdGhlIHNpZ25h dHVyZSBhbGdvcml0aG0gdXNlZCBmb3Igbm9uLXJlcHVkaWF0aW9uLiBJZiBwcmVzZW50LCBpdCBN VVNUIGJlIGV4YWN0bHkgInNoYTI1NndpdGhSU0FFbmNyeXB0aW9uIi4KCiAgICAgICogIG9jY3Vy ZW5jZTogSWYgbm9uLXJlcHVkaWF0aW9uIGlzIG5vdCBpbiB1c2UsIHRoaXMgTVVTVCBOT1QgYmUg cHJlc2VudC4gSWYgbm9uLXJlcHVkaWF0aW9uIGlzIGluIHVzZSwgdGhpcyBNVVNUIG9jY3VyIGV4 YWN0bHkgb25jZSBhbmQgTVVTVCBiZSB0aGUgdGhpcmQgbGluZSBvZiB0aGUgQ0ROSSBMb2dnaW5n IEZpbGUuCgogICAgICAqICByZXRhaW5tZW50OiBUaGlzIGRpcmVjdGl2ZSBTSE9VTEQgYmUgcmV0 YWluZWQgdG8gc3VwcG9ydCBhZnRlci10aGUtZmFjdCBub24tcmVwdWRpYXRpb24uCgogICAqICBO b24tUmVwdWRpYXRpb24tUHVibGljLUtleToKCiAgICAgICogIGZvcm1hdDogPHN0cmluZz4gKHNl ZSBTZWN0aW9uIDIuMy4yKQoKICAgICAgKiAgc2VtYW50aWM6IFRoaXMgZmllbGQgY29udGFpbnMg dGhlIHB1YmxpYyBrZXkgdXNlZCB0byBzaWduIHRoaXMgZmlsZS4gSWYgdGhpcyBpcyB0aGUgZmly c3QgbG9nIGZpbGUgaW4gYSBzZXF1ZW5jZSwgdGhlIGhhc2ggb2YgdGhpcyBwdWJsaWMga2V5IE1V U1QgYmUgZXF1YWwgdG8gdGhlIGhhc2ggZnJvbSBzdGVwIDIgb2YgU2VjdGlvbiAyLjMuMS4gT3Ro ZXJ3aXNlLCB0aGUgaGFzaCBvZiB0aGlzIHB1YmxpYyBrZXkgTVVTVCBiZSBlcXVhbCB0byB0aGUg dmFsdWUgaW4gTm9uLVJlcHVkaWF0aW9uLU5leHQtUHVibGljLUtleS1IYXNoIGluIHRoZSBwcmV2 aW91cyBsb2cgZmlsZSBpbiB0aGUgc2VxdWVuY2UuCgogICAgICAqICBvY2N1cmVuY2U6IElmIG5v bi1yZXB1ZGlhdGlvbiBpcyBub3QgaW4gdXNlLCB0aGlzIE1VU1QgTk9UIGJlIHByZXNlbnQuIElm IG5vbi1yZXB1ZGlhdGlvbiBpcyBpbiB1c2UsIHRoaXMgTVVTVCBvY2N1ciBleGFjdGx5IG9uY2Uu CgogICAgICAqICByZXRhaW5tZW50OiBUaGlzIGRpcmVjdGl2ZSBTSE9VTEQgYmUgcmV0YWluZWQg dG8gc3VwcG9ydCBhZnRlci10aGUtZmFjdCBub24tcmVwdWRpYXRpb24uCgogICAqICBOb24tUmVw dWRpYXRpb24tTmV4dC1QdWJsaWMtS2V5LUhhc2g6CgogICAgICAqICBmb3JtYXQ6IDxzdHJpbmc+ IChzZWUgU2VjdGlvbiAyLjMuMikKCiAgICAgICogIHNlbWFudGljOiBUaGlzIGZpZWxkIGNvbnRh aW5zIHRoZSBoYXNoIG9mIHRoZSBwdWJsaWMga2V5IHRoYXQgd2lsbCBiZSB1c2VkIHRvIHNpZ24g dGhlIG5leHQgbG9nIGZpbGUuIElmIHRoaXMgaXMgdGhlIGxhc3QgbG9nIGZpbGUgaW4gYSBzZXF1 ZW5jZSAoZS5nLiwgaWYgdGhlIGRDRE4gYW5kIHVDRE4gaGF2ZSB0ZXJtaW5hdGVkIHRoZWlyIGJ1 c2luZXNzIHJlbGF0aW9uc2hpcCBvciBkZWNpZGVkIHRvIHN0b3AgdXNpbmcgbm9uLXJlcHVkaWF0 aW9uKSwgdGhpcyBmaWVsZCBNVVNUIGJlIHNldCB0byB0aGUgemVyby1oYXNoLCAiMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMCIu CgogICAgICAqICBvY2N1cmVuY2U6IElmIG5vbi1yZXB1ZGlhdGlvbiBpcyBub3QgaW4gdXNlLCB0 aGlzIE1VU1QgTk9UIGJlIHByZXNlbnQuIElmIG5vbi1yZXB1ZGlhdGlvbiBpcyBpbiB1c2UsIHRo aXMgTVVTVCBvY2N1ciBleGFjdGx5IG9uY2UuCgogICAgICAqICByZXRhaW5tZW50OiBUaGlzIGRp cmVjdGl2ZSBTSE9VTEQgYmUgcmV0YWluZWQgdG8gc3VwcG9ydCBhZnRlci10aGUtZmFjdCBub24t cmVwdWRpYXRpb24uCgogICAqICBOb24tUmVwdWRpYXRpb24tQ2hhaW5pbmctU2lnbmF0dXJlOgoK ICAgICAgKiAgZm9ybWF0OiA8c3RyaW5nPgoKICAgICAgKiAgc2VtYW50aWM6IFRoaXMgZmllbGQg Y29udGFpbnMgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlIG9mIHRoZSBpbmZvcm1hdGlvbiBuZWVkZWQg dG8gdmVyaWZ5IHRoZSBjaGFpbiBmcm9tIHRoZSBwcmV2aW91cyBsb2cgZmlsZSBvciBpbml0aWFs IHB1YmxpYyBrZXkgaGFzaCB0byB0aGlzIGxvZyBmaWxlIGFuZCBmcm9tIHRoaXMgbG9nIGZpbGUg dG8gdGhlIG5leHQgbG9nIGZpbGUuIFRoaXMgc2lnbmF0dXJlIGNvdmVycyBvbmx5IGxpbmVzIGNv bnRhaW5pbmcgdGhlIE5vbi1SZXB1ZGlhdGlvbi1IYXNoLUFsZ29yaXRobSwgTm9uLVJlcHVkaWF0 aW9uLVNpZ25hdHVyZS1BbGdvcml0aG0sIE5vbi1SZXB1ZGlhdGlvbi1QdWJsaWMtS2V5LCBhbmQg Tm9uLVJlcHVkaWF0aW9uLU5leHQtUHVibGljLUtleS1IYXNoIGRpcmVjdGl2ZXMuIFRoZSBzaWdu YXR1cmUgTVVTVCBiZSB2ZXJpZmlhYmxlIHVzaW5nIHRoZSBwdWJsaWMga2V5IGluIE5vbi1SZXB1 ZGlhdGlvbi1QdWJsaWMtS2V5LgoKICAgICAgKiAgb2NjdXJyZW5jZTogSWYgbm9uLXJlcHVkaWF0 aW9uIGlzIG5vdCBpbiB1c2UsIHRoaXMgTVVTVCBOT1QgYmUgcHJlc2VudC4gSWYgbm9uLXJlcHVk aWF0aW9uIGlzIGluIHVzZSwgdGhpcyBNVVNUIG9jY3VyIGV4YWN0bHkgb25jZSBhbmQgTVVTVCBi ZSBvbmUgb2YgdGhlIGxhc3QgdHdvIGxpbmVzIG9mIHRoZSBDRE5JIExvZ2dpbmcgRmlsZS4KCiAg ICAgICogIHJldGFpbm1lbnQ6IFRoaXMgZGlyZWN0aXZlIFNIT1VMRCBiZSByZXRhaW5lZCB0byBz dXBwb3J0IGFmdGVyLXRoZS1mYWN0IG5vbi1yZXB1ZGlhdGlvbi4KCiAgICogIE5vbi1SZXB1ZGlh dGlvbi1EYXRhLVNpZ25hdHVyZToKCiAgICAgICogIGZvcm1hdDogPHN0cmluZz4KCiAgICAgICog IHNlbWFudGljOiBUaGlzIGZpZWxkIGNvbnRhaW5zIHRoZSBkaWdpdGFsIHNpZ25hdHVyZSBvZiB0 aGlzIGxvZyBmaWxlLiBUaGUgc2lnbmF0dXJlIGNvdmVycyBhbGwgZGF0YSBpbiB0aGlzIGxvZyBm aWxlLCBleGNlcHQgZm9yIGFueSBsaW5lcyBjb250YWluaW5nIHRoZSBOb24tUmVwdWRpYXRpb24t RGF0YS1TaWduYXR1cmUsIE5vbi1SZXB1ZGlhdGlvbi1DaGFpbmluZy1TaWduYXR1cmUsIE5vbi1S ZXB1ZGlhdGlvbi1OZXh0LVB1YmxpYy1LZXktSGFzaCwgb3IgVmVyaWZpZWQtT3JpZ2luIGRpcmVj dGl2ZXMsIGlmIHByZXNlbnQuIFRoZSBzaWduYXR1cmUgTVVTVCBiZSB2ZXJpZmlhYmxlIHVzaW5n IHRoZSBwdWJsaWMga2V5IGluIE5vbi1SZXB1ZGlhdGlvbi1QdWJsaWMtS2V5LgoKICAgICAgKiAg b2NjdXJyZW5jZTogSWYgbm9uLXJlcHVkaWF0aW9uIGlzIG5vdCBpbiB1c2UsIHRoaXMgTVVTVCBO T1QgYmUgcHJlc2VudC4gSWYgbm9uLXJlcHVkaWF0aW9uIGlzIGluIHVzZSwgdGhpcyBNVVNUIG9j Y3VyIGV4YWN0bHkgb25jZSBhbmQgTVVTVCBiZSBvbmUgb2YgdGhlIGxhc3QgdHdvIGxpbmVzIG9m IHRoZSBDRE5JIExvZ2dpbmcgRmlsZS4KCjcuMi4gTm9uIFJlcHVkaWF0aW9uCgogICBOb24tcmVw dWRpYXRpb24gd2l0aCBwcm9vZiBvZiBvcmlnaW4gb2YgbG9nZ2luZyBpbmZvcm1hdGlvbiBpcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiAyLjMgYW5kIFNlY3Rpb24gMy4xLiBUaGUgbm9uLXJlcHVkaWF0 aW9uIGNvdmVycyBib3RoIGluZGl2aWR1YWwgbG9nIGZpbGVzIGFuZCBzZXF1ZW5jZXMgb2YgbG9n IGZpbGVzLgoKICAgVGhlIG1lY2hhbmlzbSBmb3Igbm9uLXJlcHVkaWF0aW9uIGRlcGVuZHMgb24g dGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgaW5pdGlhbCBwdWJsaWMga2V5IGhhc2ggaW4gU3RlcCAy IG9mIFNlY3Rpb24gMi4zLjEuIFRoZXJlZm9yZSwgd2hlbiB1c2luZyBub24tcmVwdWRpYXRpb24g aXQgaXMgaW1wZXJhdGl2ZSB0byBhZGVxdWF0ZWx5IHByb3RlY3QgdGhlIGV4Y2hhbmdlIG9mIHRo ZSBpbml0aWFsIHB1YmxpYyBrZXkgaGFzaC4KCiAgIFRoZSBwcml2YXRlIGtleXMgdXNlZCBmb3Ig bm9uLXJlcHVkaWF0aW9uIE1VU1QgTk9UIGJlIHJldXNlZCBmb3IgYW55IHB1cnBvc2UuIFJldXNl IG9mIGEga2V5IGZvciBsb2cgZmlsZSBub24tcmVwdWRpYXRpb24gd291bGQgY29tcHJvbWlzZSB0 aGUgcHJvdGVjdGlvbiBvZiB0aGUgc2VxdWVuY2Ugb2YgbG9nIGZpbGVzLiBSZXVzZSBvZiBhIGtl eSB0byBwZXJmb3JtIGEgZGlnaXRhbCBzaWduYXR1cmUgZm9yIGFueSBvdGhlciBwdXJwb3NlIGNv dWxkIGNvbXByb21pc2UgdGhlIG5vbi1yZXB1ZGlhdGlvbiBvZiBsb2dnaW5nIGluZm9ybWF0aW9u IGlmIHRoZSBrZXkgaXMgdXNlZCB0byBzaWduIGFueXRoaW5nIHRoYXQgcGFyc2VzIGFzIGEgbG9n IGZpbGUuCgogICBTZWN0aW9uIDIuMy4xIGRlc2NyaWJlcyByZXRhaW5pbmcgaW5mb3JtYXRpb24g Zm9yIGFmdGVyLXRoZS1mYWN0IG5vbi1yZXB1ZGlhdGlvbi4gSWYgYSByZWNlaXZlciBkb2VzIG5v dCBwcm9wZXJseSByZXRhaW4gdGhlIGluZm9ybWF0aW9uLCB0aGV5IGFyZSBzdGlsbCBhYmxlIHRv IHZhbGlkYXRlIHRoZSBub24tcmVwdWRpYXRpb24gb2YgbG9nIGZpbGVzIGFzIHRoZXkgcmVjZWl2 ZSB0aGVtLCBwcmV2ZW50aW5nIG1vbmtleS1pbi10aGUtbWlkZGxlIGF0dGFja3MuIEhvd2V2ZXIs IHRoZXkgd291bGQgbm90IGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGJlIGFibGUgdG8gcHJv dmUgbm9uLXJlcHVkaWF0aW9uIHRvIHRoZSBvcmlnaW5hdG9yIG9yIHRvIGFueSB0aGlyZCBwYXJ0 aWVzLCBzbyB0aGV5IHdvdWxkIG5vdCBoYXZlIHN1ZmZpY2llbnQgcHJvdGVjdGlvbiBhZ2FpbnN0 IGEgY2hlYXRpbmcgb3JpZ2luYXRvci4KCiAgIFNlY3Rpb24gMi4zLjIgZGVzY3JpYmVzIHRoZSBh bGdvcml0aG1zIHVzZWQgZm9yIG5vbi1yZXB1ZGlhdGlvbi4gSWYgZXhwbG9pdGFibGUgdnVsbmVy YWJpbGl0aWVzIGluIGFueSBvZiB0aGVzZSBhbGdvcml0aG1zIGFyZSBsYXRlciBkaXNjb3ZlcmVk LCBhIHN1YnNlcXVlbnQgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIHNlbGVjdCBtb3JlIHNlY3VyZSBh bGdvcml0aG1zIGFuZCBkZXNjcmliZSBhIHRyYW5zaXRpb24gbWVjaGFuaXNtIGZyb20gdGhlIG9s ZCBhbGdvcml0aG1zIHRvIHRoZSBuZXcgb25lcy4gVGhlIE5vbi1SZXB1ZGlhdGlvbi1IYXNoLUFs Z29yaXRobSBhbmQgTm9uLVJlcHVkaWF0aW9uLVNpZ25hdHVyZS1BbGdvcml0aG0gZGlyZWN0aXZl cyBpbiBTZWN0aW9uIDMuMSBhcmUgcHJvdmlkZWQgaW4gdGhpcyBkb2N1bWVudCB0byBhaWQgdGhl IGh5cG90aGV0aWNhbCBzdWJzZXF1ZW50IGRvY3VtZW50IGluIHByb3ZpZGluZyBhIHRyYW5zaXRp b24gbWVjaGFuaXNtLgo= --=_162f193914144a6551001a5c24f69018-- From flefauch@cisco.com Wed Jun 5 06:45:44 2013 Return-Path: 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 A78D721F9A66 for ; Wed, 5 Jun 2013 06:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 LRc-i4cr9I0A for ; Wed, 5 Jun 2013 06:45:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F2FF621F9ACC for ; Wed, 5 Jun 2013 06:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15492; q=dns/txt; s=iport; t=1370439939; x=1371649539; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1MmX/It2Ywfm2rfDA35YXWsoKnEwGFmJxfRw8ovsbRU=; b=kguXMG1DMgbRgDU9W35C8HXkTWGQWFUsd/j+EPRUysn0KM4MPTeuxwRa piR0bBlzPVCUYJP2cWMv5B5eXwzbXgWjycpO+fxoTVYVyD6uOrFVFkxUX KcTkmMpf07xRTigsVdMu0fIo6BkIYzzENA9RDz35evtTQpYNUbnaKLwYL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFAJ8/r1GtJXG+/2dsb2JhbABQCYJFRDC2Z4hFfBZ0giQBAQQBAQEkRwsQAgEIIh0HJwsUEQIECgQFCIgFDL0AjXAKBXsxBwmCcWEDmGiQF4MPgWkBHgYZ X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208,217";a="219053430" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2013 13:45:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r55DjbbM015352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 13:45:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:45:37 -0500 From: "Francois Le Faucheur (flefauch)" To: David Mandelberg Thread-Topic: [CDNi] non-repudiation text Thread-Index: AQHOYXDJi/4+QLs/MUq7wI+m8xOuf5kndtiA Date: Wed, 5 Jun 2013 13:45:36 +0000 Message-ID: References: <9a43c4896f34ca72acf5bf98745af6bd@mail.mandelberg.org> In-Reply-To: <9a43c4896f34ca72acf5bf98745af6bd@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D646884xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] non-repudiation text 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:45:44 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D646884xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David and all, Below is the text I located in RFC4949 about non-repudiation. In case you h= ave not done it yet, can you check it out and see if we use the terminology= right? Thanks Francois $ non-repudiation service 1. (I) A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.) Tutorial: Two separate types of denial are possible -- an entity can deny that it sent a data object, or it can deny that it received a data object -- and, therefore, two separate types of non-repudiation service are possible. (See: non-repudiation with proof of origin, non-repudiation with proof of receipt.) 2. (D) "Assurance [that] the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data." [C4009] Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it bundles two security services -- non-repudiation with proof of origin, and non-repudiation with proof of receipt -- that can be provided independently of each other. Usage: IDOCs SHOULD distinguish between the technical aspects and the legal aspects of a non-repudiation service: - "Technical non-repudiation": Refers to the assurance a relying party has that if a public key is used to validate a digital signature, then that signature had to have been made by the corresponding private signature key. [SP32] - "Legal non-repudiation": Refers to how well possession or control of the private signature key can be established. [SP32] Tutorial: Non-repudiation service does not prevent an entity from repudiating a communication. Instead, the service provides evidence that can be stored and later presented to a third party to resolve disputes that arise if and when a communication is repudiated by one of the entities involved. Shirey Informational [Page 200] RFC 4949 Internet Security Glossary, Version 2 August 2007 Ford describes the six phases of a complete non-repudiation service and uses "critical action" to refer to the act of communication that is the subject of the service [For94, For97]: -------- -------- -------- -------- -------- . -------- Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: Request Generate Transfer Verify Retain . Resolve Service Evidence Evidence Evidence Evidence . Dispute -------- -------- -------- -------- -------- . -------- Service Critical Evidence Evidence Archive . Evidence Request =3D> Action =3D> Stored =3D> Is =3D> Evidence . Is Is Made Occurs For Later Tested In Case . Verified and Use | ^ Critical . ^ Evidence v | Action Is . | Is +-------------------+ Repudiated . | Generated |Verifiable Evidence|------> ... . ----+ +-------------------+ Phase / Explanation ------------------- 1. Request service: Before the critical action, the service requester asks, either implicitly or explicitly, to have evidence of the action be generated. 2. Generate evidence: When the critical action occurs, evidence is generated by a process involving the potential repudiator and possibly also a trusted third party. 3. Transfer evidence: The evidence is transferred to the requester or stored by a third party, for later use (if needed). 4. Verify evidence: The entity that holds the evidence tests it to be sure that it will suffice if a dispute arises. 5. Retain evidence: The evidence is retained for possible future retrieval and use. 6. Resolve dispute: In this phase, which occurs only if the critical action is repudiated, the evidence is retrieved from storage, presented, and verified to resolve the dispute. $ non-repudiation with proof of origin (I) A security service that provides the recipient of data with evidence that proves the origin of the data, and thus protects the recipient against an attempt by the originator to falsely deny sending the data. (See: non-repudiation service.) Tutorial: This service is a strong version of data origin authentication service. This service can not only verify the identity of a system entity that is the original source of received data; it can also provide proof of that identity to a third party. Shirey Informational [Page 201] RFC 4949 Internet Security Glossary, Version 2 August 2007 $ non-repudiation with proof of receipt (I) A security service that provides the originator of data with evidence that proves the data was received as addressed, and thus protects the originator against an attempt by the recipient to falsely deny receiving the data. (See: non-repudiation service.) $ non-volatile media (I) Storage media that, once written into, provide stable storage of information without an external power supply. (Compare: permanent storage, volatile media.) On 5 Jun 2013, at 00:21, David Mandelberg > wrote: Hi, I've attached a first draft of some text for non-repudiation. It has two open issues that I know about: 1. I'd like to provide a sensible default for the maximum lifespan of ephemeral keys, but I'm not sure what is reasonable in this context. On the CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does anybody have input about the security of 1 hour/day/month? 2. The text I wrote is not compatible with Integrity-Hash. I could update it to work with Integrity-Hash, but I think it might be easier to just say "Integrity-Hash and non-repudiation MUST NOT be used in the same log file" since non-repudiation provides for integrity anyway. Thoughts? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/_______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D646884xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0D2829E209F29C4A9F3AB2FCD0200275@emea.cisco.com> Content-Transfer-Encoding: quoted-printable David and all,

Below is the text I located in RFC4949 about non-repudiation. In case = you have not done it yet, can you check it out and see if we use the termin= ology right?

Thanks

Francois

 $ non-repudiation service
      1. (I) A security service that provide protection against false
      denial of involvement in an association (especially a
      communication association that transfers data). (See: repudiation,
      time stamp.)

      Tutorial: Two separate types of denial are possible -- an entity
      can deny that it sent a data object, or it can deny that it
      received a data object -- and, therefore, two separate types of
      non-repudiation service are possible. (See: non-repudiation with
      proof of origin, non-repudiation with proof of receipt.)

      2. (D) "Assurance [that] the sender of data is provided with pro=
of
      of delivery and the recipient is provided with proof of the
      sender's identity, so neither can later deny having processed the
      data." [C4009]

      Deprecated Definition: IDOCs SHOULD NOT use definition 2 because
      it bundles two security services -- non-repudiation with proof of
      origin, and non-repudiation with proof of receipt -- that can be
      provided independently of each other.

      Usage: IDOCs SHOULD distinguish between the technical aspects and
      the legal aspects of a non-repudiation service:
      -  "Technical non-repudiation": Refers to the assurance a r=
elying
         party has that if a public key is used to validate a digital
         signature, then that signature had to have been made by the
         corresponding private signature key. [SP32]
      -  "Legal non-repudiation": Refers to how well possession o=
r
         control of the private signature key can be established. [SP32]

      Tutorial: Non-repudiation service does not prevent an entity from
      repudiating a communication. Instead, the service provides
      evidence that can be stored and later presented to a third party
      to resolve disputes that arise if and when a communication is
      repudiated by one of the entities involved.

Shirey                       Informational                    [Page 20=
0]
RFC 4949       =
  Internet Security Glossary, Version 2       August 2007

      Ford describes the six phases of a complete non-repudiation
      service and uses "critical action" to refer to the act of
      communication that is the subject of the service [For94, For97]:

      --------   --------   --------   --------   --------   . --------
      Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:
      Request    Generate   Transfer   Verify     Retain     . Resolve
      Service    Evidence   Evidence   Evidence   Evidence   . Dispute
      --------   --------   --------   --------   --------   . --------

      Service    Critical   Evidence   Evidence   Archive    . Evidence
      Request =3D> Action  =3D> Stored  =3D> Is      =3D> Evide=
nce   . Is
      Is Made    Occurs     For Later  Tested     In Case    . Verified
                 and        Use |          ^      Critical   .    ^
                 Evidence       v          |      Action Is  .    |
                 Is         +-------------------+ Repudiated .    |
                 Generated  |Verifiable Evidence|------> ... . ----+
                            +-------------------+

      Phase / Explanation
      -------------------
      1. Request service: Before the critical action, the service
         requester asks, either implicitly or explicitly, to have
         evidence of the action be generated.
      2. Generate evidence: When the critical action occurs, evidence is
         generated by a process involving the potential repudiator and
         possibly also a trusted third party.
      3. Transfer evidence: The evidence is transferred to the requester
         or stored by a third party, for later use (if needed).
      4. Verify evidence: The entity that holds the evidence tests it to
         be sure that it will suffice if a dispute arises.
      5. Retain evidence: The evidence is retained for possible future
         retrieval and use.
      6. Resolve dispute: In this phase, which occurs only if the
         critical action is repudiated, the evidence is retrieved from
         storage, presented, and verified to resolve the dispute.

   $ non-repudiation with proof of origin
      (I) A security service that provides the recipient of data with
      evidence that proves the origin of the data, and thus protects the
      recipient against an attempt by the originator to falsely deny
      sending the data. (See: non-repudiation service.)

      Tutorial: This service is a strong version of data origin
      authentication service. This service can not only verify the
      identity of a system entity that is the original source of
      received data; it can also provide proof of that identity to a
      third party.

Shirey                       Informational                    [Page 20=
1]
RFC 4949       =
  Internet Security Glossary, Version 2       August 2007

   $ non-repudiation with proof of receipt
      (I) A security service that provides the originator of data with
      evidence that proves the data was received as addressed, and thus
      protects the originator against an attempt by the recipient to
      falsely deny receiving the data. (See: non-repudiation service.)

   $ non-volatile media
      (I) Storage media that, once written into, provide stable storage
      of information without an external power supply. (Compare:
      permanent storage, volatile media.)



On 5 Jun 2013, at 00:21, David Mandelberg <david@mandelberg.org> wrote:

Hi,

I've attached a first draft of some text for non-repudiation. It has two open issues that I know about:

1. I'd like to provide a sensible default for the maximum lifespan of
ephemeral keys, but I'm not sure what is reasonable in this context. On the=
CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does anybody have input about the security of 1 hour/day/month?

2. The text I wrote is not compatible with Integrity-Hash. I could update it to work with Integrity-Hash, but I think it might be easier to just say<= br> "Integrity-Hash and non-repudiation MUST NOT be used in the same log f= ile"
since non-repudiation provides for integrity anyway. Thoughts?

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/<draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt>_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D646884xmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Jun 5 06:48:00 2013 Return-Path: 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 3446F21F9AE2 for ; Wed, 5 Jun 2013 06:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 T4sBrSAL0jbQ for ; Wed, 5 Jun 2013 06:47:55 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1921F9AD1 for ; Wed, 5 Jun 2013 06:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11234; q=dns/txt; s=iport; t=1370440075; x=1371649675; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2ItvVaKXiIQiy8Pad79x9tBqhox37vdCkM6B9ASd1XY=; b=X7AsYXhPxily2Wpb9Ly9yiyG33E+O4ObfvGTy9welZ+RlH4j02Q6stN+ MCkAnP0ts53kVbs+WHsg3I3+SAjS4rZCHiy8ptGhIvTGk4oth8T80Ui8E +t6LCEvWFAI6us2OO82gtZaqNuTKAQDDCDAbQeZoIUkQiewmhMOTPKeN8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAPpAr1GtJV2c/2dsb2JhbAA/FwOCRUQwvyx8Fm0HgiQBAQICZgIhAgEcDgoEDAoyJAECAQMbiAUMMq8WjTmNaRt2IAEMCxEHgmJhA6h/gj9QgXE2 X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208,217";a="219086453" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 05 Jun 2013 13:47:42 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r55DlgLW003056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Jun 2013 13:47:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:47:42 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Logging - 2nd Informal Meeting in an hour and 15 minutes Thread-Index: AQHOYfNACXcPW3BjBESRhC6EGwMaBA== Date: Wed, 5 Jun 2013 13:47:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D6468D5xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] CDNI Logging - 2nd Informal Meeting in an hour and 15 minutes 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:48:00 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D6468D5xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Friendly reminder: * Wed 5 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, fo= r 90 minutes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 5, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 206 470 738 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213782&UID=3D4843= 18167&PW=3DNMmQzODVmZjJm&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:206 470 738 CCP:+14085256800x206470738# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_FC236DA6F2DA77449EF2D02DF4471A8D6468D5xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7E920F553736134B9D3C99F3F590E49D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Friendly reminder:

* W= ed 5 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, for 9= 0 minutes



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D


Topic: IETF CDNI Logging - Informal Meeting =
Date:= Wednesday, June 5, 2013 
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 206 470 738 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D225213782&UID=3D484318167&PW=3DNMmQzODVmZj= Jm&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:206 470 738 

CCP:+14085256800x206470738# 


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature = that allows audio and any documents and other materials exchanged or viewed= during the session to be recorded. By joining this session, you automatically consent to such recordings. If = you do not consent to the recording, discuss your concerns with the meeting= host prior to the start of the recording or do not join the session. Pleas= e note that any such recordings may be subject to discovery in the event of litigation. 

--_000_FC236DA6F2DA77449EF2D02DF4471A8D6468D5xmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Jun 5 06:51:58 2013 Return-Path: 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 2E6D221F9B4B for ; Wed, 5 Jun 2013 06:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 syn7XLaGdQgN for ; Wed, 5 Jun 2013 06:51:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F052121F9B47 for ; Wed, 5 Jun 2013 06:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18099; q=dns/txt; s=iport; t=1370440308; x=1371649908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LQ812iLp9OcyHbx243DjGQgTZxsu9Tyzy8OBckZdQ6w=; b=HGRYTxpFMpwCJJoZDIAXkanb1p4alJz2D9iV8MTm+nG7UJ42Dw+J0Wuu g3l9hjHmHo0ictgNFmeY825x6+nv+94dWvuPPhSS+shGXuLSWU1dmYq67 RqixZspGrl+PTQnfMcAjVmE7MP7LxULDnH+zuW00l618zMYgKIqDXe6ns M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAFADdBr1GtJV2Y/2dsb2JhbABQCYJFRDC2Z4hFfBZ0giQBAQQBAQEkRwsQAgEIIh0HJwsUEQIECgQFCIgFDL0BjXAKBXstBAcJgnFhA5hokBeDD4FpAR4GGQ X-IronPort-AV: E=Sophos;i="4.87,806,1363132800"; d="scan'208,217";a="218867517" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jun 2013 13:51:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r55DpkQa027598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Jun 2013 13:51:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 5 Jun 2013 08:51:46 -0500 From: "Francois Le Faucheur (flefauch)" To: David Mandelberg Thread-Topic: [CDNi] non-repudiation text Thread-Index: AQHOYXDJi/4+QLs/MUq7wI+m8xOuf5kndtiAgAABuAA= Date: Wed, 5 Jun 2013 13:51:46 +0000 Message-ID: References: <9a43c4896f34ca72acf5bf98745af6bd@mail.mandelberg.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D646957xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] non-repudiation text 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:51:58 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D646957xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable and this other excerpt from RFC4949 will probably help: " 2.4. Definition Type and Context Each entry is preceded by a character -- I, N, O, or D -- enclosed in parentheses, to indicate the type of definition (as is explained further in Section 3): - "I" for a RECOMMENDED term or definition of Internet origin. - "N" if RECOMMENDED but not of Internet origin. - "O" for a term or definition that is NOT recommended for use in IDOCs but is something that authors of Internet documents should know about. - "D" for a term or definition that is deprecated and SHOULD NOT be used in Internet documents. " On 5 Jun 2013, at 15:45, Francois Le Faucheur (flefauch) > wrote: David and all, Below is the text I located in RFC4949 about non-repudiation. In case you h= ave not done it yet, can you check it out and see if we use the terminology= right? Thanks Francois $ non-repudiation service 1. (I) A security service that provide protection against false denial of involvement in an association (especially a communication association that transfers data). (See: repudiation, time stamp.) Tutorial: Two separate types of denial are possible -- an entity can deny that it sent a data object, or it can deny that it received a data object -- and, therefore, two separate types of non-repudiation service are possible. (See: non-repudiation with proof of origin, non-repudiation with proof of receipt.) 2. (D) "Assurance [that] the sender of data is provided with proof of delivery and the recipient is provided with proof of the sender's identity, so neither can later deny having processed the data." [C4009] Deprecated Definition: IDOCs SHOULD NOT use definition 2 because it bundles two security services -- non-repudiation with proof of origin, and non-repudiation with proof of receipt -- that can be provided independently of each other. Usage: IDOCs SHOULD distinguish between the technical aspects and the legal aspects of a non-repudiation service: - "Technical non-repudiation": Refers to the assurance a relying party has that if a public key is used to validate a digital signature, then that signature had to have been made by the corresponding private signature key. [SP32] - "Legal non-repudiation": Refers to how well possession or control of the private signature key can be established. [SP32] Tutorial: Non-repudiation service does not prevent an entity from repudiating a communication. Instead, the service provides evidence that can be stored and later presented to a third party to resolve disputes that arise if and when a communication is repudiated by one of the entities involved. Shirey Informational [Page 200] RFC 4949 Internet Security Glossary, Version 2 August 2007 Ford describes the six phases of a complete non-repudiation service and uses "critical action" to refer to the act of communication that is the subject of the service [For94, For97]: -------- -------- -------- -------- -------- . -------- Phase 1: Phase 2: Phase 3: Phase 4: Phase 5: . Phase 6: Request Generate Transfer Verify Retain . Resolve Service Evidence Evidence Evidence Evidence . Dispute -------- -------- -------- -------- -------- . -------- Service Critical Evidence Evidence Archive . Evidence Request =3D> Action =3D> Stored =3D> Is =3D> Evidence . Is Is Made Occurs For Later Tested In Case . Verified and Use | ^ Critical . ^ Evidence v | Action Is . | Is +-------------------+ Repudiated . | Generated |Verifiable Evidence|------> ... . ----+ +-------------------+ Phase / Explanation ------------------- 1. Request service: Before the critical action, the service requester asks, either implicitly or explicitly, to have evidence of the action be generated. 2. Generate evidence: When the critical action occurs, evidence is generated by a process involving the potential repudiator and possibly also a trusted third party. 3. Transfer evidence: The evidence is transferred to the requester or stored by a third party, for later use (if needed). 4. Verify evidence: The entity that holds the evidence tests it to be sure that it will suffice if a dispute arises. 5. Retain evidence: The evidence is retained for possible future retrieval and use. 6. Resolve dispute: In this phase, which occurs only if the critical action is repudiated, the evidence is retrieved from storage, presented, and verified to resolve the dispute. $ non-repudiation with proof of origin (I) A security service that provides the recipient of data with evidence that proves the origin of the data, and thus protects the recipient against an attempt by the originator to falsely deny sending the data. (See: non-repudiation service.) Tutorial: This service is a strong version of data origin authentication service. This service can not only verify the identity of a system entity that is the original source of received data; it can also provide proof of that identity to a third party. Shirey Informational [Page 201] RFC 4949 Internet Security Glossary, Version 2 August 2007 $ non-repudiation with proof of receipt (I) A security service that provides the originator of data with evidence that proves the data was received as addressed, and thus protects the originator against an attempt by the recipient to falsely deny receiving the data. (See: non-repudiation service.) $ non-volatile media (I) Storage media that, once written into, provide stable storage of information without an external power supply. (Compare: permanent storage, volatile media.) On 5 Jun 2013, at 00:21, David Mandelberg > wrote: Hi, I've attached a first draft of some text for non-repudiation. It has two open issues that I know about: 1. I'd like to provide a sensible default for the maximum lifespan of ephemeral keys, but I'm not sure what is reasonable in this context. On the CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does anybody have input about the security of 1 hour/day/month? 2. The text I wrote is not compatible with Integrity-Hash. I could update it to work with Integrity-Hash, but I think it might be easier to just say "Integrity-Hash and non-repudiation MUST NOT be used in the same log file" since non-repudiation provides for integrity anyway. Thoughts? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/_______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D646957xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
and this other excerpt from RFC4949 will probably help:

"
2.4. Definition Type and Context

   Each entry is preceded by a character -- I, N, O, or D -- enclosed in
   parentheses, to indicate the type of definition (as is explained
   further in Section 3):
   -  "I" for a RECOMMENDED term or definition of Internet origin=
.
   -  "N" if RECOMMENDED but not of Internet origin.
   -  "O" for a term or definition that is NOT recommended for us=
e in
      IDOCs but is something that authors of Internet documents should
      know about.
   -  "D" for a term or definition that is deprecated and SHOULD =
NOT be
      used in Internet documents.
"


On 5 Jun 2013, at 15:45, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

David and all,

Below is the text I located in RFC4949 about non-repudiation. In case = you have not done it yet, can you check it out and see if we use the termin= ology right?

Thanks

Francois

 $ non-repudiation service
      1. (I) A security service that provide protection against false
      denial of involvement in an association (especially a
      communication association that transfers data). (See: repudiation,
      time stamp.)

      Tutorial: Two separate types of denial are possible -- an entity
      can deny that it sent a data object, or it can deny that it
      received a data object -- and, therefore, two separate types of
      non-repudiation service are possible. (See: non-repudiation with
      proof of origin, non-repudiation with proof of receipt.)

      2. (D) "Assurance [that] the sender of data is provided with pro=
of
      of delivery and the recipient is provided with proof of the
      sender's identity, so neither can later deny having processed the
      data." [C4009]

      Deprecated Definition: IDOCs SHOULD NOT use definition 2 because
      it bundles two security services -- non-repudiation with proof of
      origin, and non-repudiation with proof of receipt -- that can be
      provided independently of each other.

      Usage: IDOCs SHOULD distinguish between the technical aspects and
      the legal aspects of a non-repudiation service:
      -  "Technical non-repudiation": Refers to the assurance a r=
elying
         party has that if a public key is used to validate a digital
         signature, then that signature had to have been made by the
         corresponding private signature key. [SP32]
      -  "Legal non-repudiation": Refers to how well possession o=
r
         control of the private signature key can be established. [SP32]

      Tutorial: Non-repudiation service does not prevent an entity from
      repudiating a communication. Instead, the service provides
      evidence that can be stored and later presented to a third party
      to resolve disputes that arise if and when a communication is
      repudiated by one of the entities involved.

Shirey                       Informational                    [Page 20=
0]
RFC 4949       =
  Internet Security Glossary, Version 2       August 2007

      Ford describes the six phases of a complete non-repudiation
      service and uses "critical action" to refer to the act of
      communication that is the subject of the service [For94, For97]:

      --------   --------   --------   --------   --------   . --------
      Phase 1:   Phase 2:   Phase 3:   Phase 4:   Phase 5:   . Phase 6:
      Request    Generate   Transfer   Verify     Retain     . Resolve
      Service    Evidence   Evidence   Evidence   Evidence   . Dispute
      --------   --------   --------   --------   --------   . --------

      Service    Critical   Evidence   Evidence   Archive    . Evidence
      Request =3D> Action  =3D> Stored  =3D> Is      =3D> Evide=
nce   . Is
      Is Made    Occurs     For Later  Tested     In Case    . Verified
                 and        Use |          ^      Critical   .    ^
                 Evidence       v          |      Action Is  .    |
                 Is         +-------------------+ Repudiated .    |
                 Generated  |Verifiable Evidence|------> ... . ----+
                            +-------------------+

      Phase / Explanation
      -------------------
      1. Request service: Before the critical action, the service
         requester asks, either implicitly or explicitly, to have
         evidence of the action be generated.
      2. Generate evidence: When the critical action occurs, evidence is
         generated by a process involving the potential repudiator and
         possibly also a trusted third party.
      3. Transfer evidence: The evidence is transferred to the requester
         or stored by a third party, for later use (if needed).
      4. Verify evidence: The entity that holds the evidence tests it to
         be sure that it will suffice if a dispute arises.
      5. Retain evidence: The evidence is retained for possible future
         retrieval and use.
      6. Resolve dispute: In this phase, which occurs only if the
         critical action is repudiated, the evidence is retrieved from
         storage, presented, and verified to resolve the dispute.

   $ non-repudiation with proof of origin
      (I) A security service that provides the recipient of data with
      evidence that proves the origin of the data, and thus protects the
      recipient against an attempt by the originator to falsely deny
      sending the data. (See: non-repudiation service.)

      Tutorial: This service is a strong version of data origin
      authentication service. This service can not only verify the
      identity of a system entity that is the original source of
      received data; it can also provide proof of that identity to a
      third party.

Shirey                       Informational                    [Page 20=
1]
RFC 4949       =
  Internet Security Glossary, Version 2       August 2007

   $ non-repudiation with proof of receipt
      (I) A security service that provides the originator of data with
      evidence that proves the data was received as addressed, and thus
      protects the originator against an attempt by the recipient to
      falsely deny receiving the data. (See: non-repudiation service.)

   $ non-volatile media
      (I) Storage media that, once written into, provide stable storage
      of information without an external power supply. (Compare:
      permanent storage, volatile media.)



On 5 Jun 2013, at 00:21, David Mandelberg <david@mandelberg.org> wrote:

Hi,

I've attached a first draft of some text for non-repudiation. It has two open issues that I know about:

1. I'd like to provide a sensible default for the maximum lifespan of
ephemeral keys, but I'm not sure what is reasonable in this context. On the=
CDNI side, would 1 hour work? 1 day? 1 month? On the security side, does anybody have input about the security of 1 hour/day/month?

2. The text I wrote is not compatible with Integrity-Hash. I could update it to work with Integrity-Hash, but I think it might be easier to just say<= br> "Integrity-Hash and non-repudiation MUST NOT be used in the same log f= ile"
since non-repudiation provides for integrity anyway. Thoughts?

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/<draft-ietf-cdni-logging-03-non-repudiation-suggestions-00.txt>_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D646957xmbrcdx10ciscocom_-- From david@mandelberg.org Wed Jun 5 07:43:49 2013 Return-Path: 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 5A72A21F9B03 for ; Wed, 5 Jun 2013 07:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] 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 pLahKRJQWmwW for ; Wed, 5 Jun 2013 07:43:45 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 0E65921F9AFF for ; Wed, 5 Jun 2013 07:43:44 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id kczb1l0040SCNGk59ejk1S; Wed, 05 Jun 2013 14:43:44 +0000 Received: from uriel.mandelberg.org ([IPv6:2001:4830:11a7:2:216:3eff:fe0e:b38c]) by omta09.westchester.pa.mail.comcast.net with comcast id keji1l0021djk4J3Vejj3J; Wed, 05 Jun 2013 14:43:44 +0000 Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id A3C531C6117; Wed, 5 Jun 2013 10:51:28 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 05 Jun 2013 10:51:28 -0400 From: David Mandelberg To: "Francois Le Faucheur (flefauch)" In-Reply-To: References: <9a43c4896f34ca72acf5bf98745af6bd@mail.mandelberg.org> Message-ID: <193a70e8057207466620d814754a860a@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: RoundCube Webmail/0.3.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370443424; bh=MtvzOyeiK9/I8NyrBzSAy8KRcqTUpH23hpFwGNrElcU=; h=Received:Received:Received:MIME-Version:Content-Type:Date:From:To: Subject:Message-ID; b=hK4MUVCFOHWXobprpjfcjTWJxF6Te2lHdZftr3o5AJr37Zqep7WZbCsNUBeGjp934 z32ceLpvSsqTSfVV5uE0kW5zW/jYbZcuNJQJHgdK1RhJW4NekUiapYOPxE3eJ2ur7o 9GxAV2U4DW0IONrcI2Zyo3qnQO2ShGH/hKkkZ0YkkJLwTXZq/epMX2oEN/cMKMArxj oUiJGkNYToo5XiOrNxC0npivZLjumG1qTAM1ScZZOtq628a3sd9OoQs58yuaf7RwxC P6qm1YUY/G4/v48zQSpzBhX9JEhXafNkKyxRDcgC4xk9GkLTTOsc8LBUFiPL2HsagQ fAfKLvd0rfQbw== Cc: cdni@ietf.org Subject: Re: [CDNi] non-repudiation text 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 14:43:49 -0000 On Wed, 5 Jun 2013 13:45:36 +0000, "Francois Le Faucheur (flefauch)" wrote: > Below is the text I located in RFC4949 about non-repudiation. In case you > have not done it yet, can you check it out and see if we use the > terminology right? The only terminology I used from RFC4949 is non-repudiation with proof of origin: The term "non-repudiation with proof of origin" is defined in [RFC4949]. For brevity, the term "non-repudiation" will be used to mean "non-repudiation with proof of origin" in this document. Reading "non-repudiation service" now, I don't see anything that conflicts with the text I wrote. I didn't explicitly name the 6 phases, but I think they're all there. Should I update the text to explicitly map those phases to their use in CDNI Logging? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From flefauch@cisco.com Mon Jun 10 05:50:37 2013 Return-Path: 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 F084F21F84B4 for ; Mon, 10 Jun 2013 05:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HTZVh4Xr870f for ; Mon, 10 Jun 2013 05:50:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C885921F843F for ; Mon, 10 Jun 2013 05:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=290; q=dns/txt; s=iport; t=1370868627; x=1372078227; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=P9Au0zJauMBH3Vqw6s8adyOE+6cEWLIgTbiPlxdE7Nk=; b=dv2IAVHjZWJOtSRh4KwZIKxwdDNIPQaHD2wzh9yWJ8QHotI1YrCWyinS CeYMCAM8ZQBv2fPlKN6DNvHt6jgTCJ67IkN5lE6SvXQ2GEcA9xXESPjZg LVwyS2s8EERuZ6OtrhtgwdLKkZGzbMxbMSS0F7dP3ggT0/OkGgfYzIxmi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcFAJrKtVGtJV2d/2dsb2JhbABagwl5vkGBAxZtB4IlAQQ6PxIBKhRCJwQODYgFuQqPBzGDBmEDqQKDD4In X-IronPort-AV: E=Sophos;i="4.87,837,1363132800"; d="scan'208";a="220855132" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2013 12:50:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5ACoQfR031269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 12:50:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 07:50:26 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: draft-ietf-cdni-metadata and ccid/sid Thread-Index: AQHOZdkToSEjU27cQEWXOpEYaCFQ6A== Date: Mon, 10 Jun 2013 12:50:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <9613AF94CAA1F748A74779A234B4C7BA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] draft-ietf-cdni-metadata and ccid/sid 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 12:50:37 -0000 To cdni-metadata authors, In cdni-logging, we need to define logging fields to record the Content Col= lection ID (CCID) and Session ID (SID).=20 Is a format for these fields already specified in cdni-metadata?=20 If not, do you plan to do so in the next rev? Thanks Francois= From mcaulfie@cisco.com Mon Jun 10 13:18:02 2013 Return-Path: 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 78A9721F9A12 for ; Mon, 10 Jun 2013 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 J-Yp7vWSlp3b for ; Mon, 10 Jun 2013 13:17:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5D21E8093 for ; Mon, 10 Jun 2013 13:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=748; q=dns/txt; s=iport; t=1370895470; x=1372105070; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HySU1oAbge8k8zxjDu8eaexLwZgGV581oS/ZFkIyTIg=; b=I6JJ9kXuOshr4DGdJtRY0HfKb9PjoykAj62dBNEUHyhyOS4ahTcI4Ikd CelsavO6mOAkgDQLyeAmHhr0syDhI5LNVahRCl+XlV2pIf+YMZgFWF6xw 3D+9PoGkYR4ggbMxHzrHwymNFc45bTQMEf4ks+HJf+USn/6BwzrbnEoW/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FACoztlGtJXHA/2dsb2JhbABZgwl5gi28F4EFFnSCIwEBAQQ6PwwEAgEIEQQBAQsUEDIdCAIEAQ0FCIgFuW2PBzEHBoJ5YQOpAoMPgic X-IronPort-AV: E=Sophos;i="4.87,840,1363132800"; d="scan'208";a="220865671" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 10 Jun 2013 20:17:49 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5AKHn0k001699 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 20:17:49 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 15:17:48 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: draft-ietf-cdni-metadata and ccid/sid Thread-Index: AQHOZdkToSEjU27cQEWXOpEYaCFQ6JkvYzSA Date: Mon, 10 Jun 2013 20:17:48 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921041B10B@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-metadata and ccid/sid 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:18:02 -0000 Hello Francois, A format for these fields is not yet defined. Both will be included in the = next revision of the metadata draft. Regards, Matt -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Monday, June 10, 2013 8:50 AM To: draft-ietf-cdni-metadata@tools.ietf.org Cc: Francois Le Faucheur (flefauch); ; Roy Pete= rkofsky; cdni@ietf.org Subject: draft-ietf-cdni-metadata and ccid/sid To cdni-metadata authors, In cdni-logging, we need to define logging fields to record the Content Col= lection ID (CCID) and Session ID (SID).=20 Is a format for these fields already specified in cdni-metadata?=20 If not, do you plan to do so in the next rev? Thanks Francois From flefauch@cisco.com Tue Jun 11 06:41:20 2013 Return-Path: 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 A510321F9992 for ; Tue, 11 Jun 2013 06:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3zr78x4PV26V for ; Tue, 11 Jun 2013 06:41:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C49AF21F998D for ; Tue, 11 Jun 2013 06:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1370958075; x=1372167675; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LDITxo3GkKYT0rlIDq/Te/66dZU2aQqOWDoW/zZNTp8=; b=nByA/9tleagLJMlxt8UIiuiUr0t2bE7HlujC2U/UlmlcMQ/bO7xLteJe sCq2a7wbCRYFJqNFxswoU51OAioWTwTLLdg9T6DrV43y/VSUsNODxygPE 78UkMSLB4G83n9jILseachBIfXkFUpB5vNNWpc7JNlZuc2gsjR9PMBg4k s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIcot1GtJV2Y/2dsb2JhbABZgwkwSb5LfhZ0giMBAQEDAXkFBwQCAQgRBAEBCyQyHQgCBA4FCAGHfgYMukKOfwIxBwaCeWEDqQKDD4In X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="221201534" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jun 2013 13:40:58 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5BDevke027530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 13:40:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 08:40:57 -0500 From: "Francois Le Faucheur (flefauch)" To: "Matt Caulfield (mcaulfie)" Thread-Topic: draft-ietf-cdni-metadata and ccid/sid Thread-Index: AQHOZdkToSEjU27cQEWXOpEYaCFQ6JkvYzSAgAF3g4A= Date: Tue, 11 Jun 2013 13:40:56 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C921041B10B@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C921041B10B@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: <75E17859AA9EDE42915922E6AAD120F2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-metadata and ccid/sid 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:41:20 -0000 Matt and all, Just did a little more thinking on this, and it occurred to me that: * while both CCID and SID need to be conveyed inside CDNI Logging * only CCID probably needs to be conveyed in CDN Metadata Basically, the idea is that the CCID is indeed distributed by uCDN to dCDN = (as a property of the content), the Session-ID (when supported) is somethin= g that is generated locally, on a per session basis obviously, by the dCDN.= So the SID shoudl not be distributed through CDNI metadata. I checked back in http://www.ietf.org/id/draft-brandenburg-cdni-has-05.txt = and the wording seems consistent with what I describe above. " =85 a "Content Collection IDentifier (CCID)" field is distributed through the CDNI Metadata Interface and the same CCID value is associated through the CDNI Metadata interface with every chunk of the same Content Collection. =20 =85 When distributed, and CCID logging is requested from the dCDN, the dCDN Surrogates are to store the CCID value in the corresponding log entries. " " , if the downstream CDN happens to have sufficient HAS awareness to be able to generate a "Session IDentifier (Session-ID)", optionally including such Session-ID (in addition to the CCID) in the per-chunk log record would further facilitate optional summarization performed at step [f].=20 " Do we all agree that CCID needs to be distributed in cdni-metadata but SID = need not? If yes, then: 1) sorry for misleading you earlier in requesting definition of SID in the= cdni-metadata document. 2) please have next rev of cdni-metadata defines CCID and not SID 2) we'll have cdni-logging refer to cdni-metadata for CCID , and cdni-logg= ing refer to cdni-has for SID. Cheers Francois On 10 Jun 2013, at 22:17, Matt Caulfield (mcaulfie) wr= ote: > Hello Francois, >=20 > A format for these fields is not yet defined. Both will be included in th= e next revision of the metadata draft. >=20 > Regards, > Matt >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Monday, June 10, 2013 8:50 AM > To: draft-ietf-cdni-metadata@tools.ietf.org > Cc: Francois Le Faucheur (flefauch); ; Roy Pe= terkofsky; cdni@ietf.org > Subject: draft-ietf-cdni-metadata and ccid/sid >=20 > To cdni-metadata authors, >=20 > In cdni-logging, we need to define logging fields to record the Content C= ollection ID (CCID) and Session ID (SID).=20 > Is a format for these fields already specified in cdni-metadata?=20 > If not, do you plan to do so in the next rev? >=20 > Thanks >=20 > Francois From mcaulfie@cisco.com Tue Jun 11 06:44:03 2013 Return-Path: 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 511BC21F9005 for ; Tue, 11 Jun 2013 06:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 VomfspeLSXhJ for ; Tue, 11 Jun 2013 06:43:58 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 13A7B21F99C6 for ; Tue, 11 Jun 2013 06:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3274; q=dns/txt; s=iport; t=1370958238; x=1372167838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=02/LiVV6Msg9+rgA9xTplJiMB37ztx3LwwH+cBve4hc=; b=VnuPYY+bV/O6hwnPTRKQyaBFa5/XxFExV8hNfDujxBOuRw1TMHU8O7QD vwtTn7XRNqZ0VcVoMZiEhmFEmb2LLdWWMLT8HzgaVAx82MObM5db/4YNR 6S7m/msyhGT9ND9x6UNkimgrpd3axQewZ/Y7R6xdwSsrbM2c/gO1jy8yc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACgot1GtJV2b/2dsb2JhbABZgwkwSb5LfhZ0giMBAQEDATo/BQcEAgEIEQQBAQsUEDIdCAIEDgUIAYd+Bgy6QY8BMQcGgnlhA6kCgw+CJw X-IronPort-AV: E=Sophos;i="4.87,845,1363132800"; d="scan'208";a="221403492" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 11 Jun 2013 13:43:51 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5BDhpkU004932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 13:43:51 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.104]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 08:43:50 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: draft-ietf-cdni-metadata and ccid/sid Thread-Index: AQHOZdkToSEjU27cQEWXOpEYaCFQ6JkvYzSAgAF3g4D//6ymIA== Date: Tue, 11 Jun 2013 13:43:50 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921041B73B@xmb-aln-x03.cisco.com> References: <166EBB70C264A9479E459B01B1BA6C921041B10B@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-metadata and ccid/sid 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:44:03 -0000 Thanks for the clarification, Francois - that makes more sense (I was wonde= ring why SID was necessary). I agree with your statements below. The next revision of the metadata draft will include CCID but not SID (assu= ming no objections). -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, June 11, 2013 9:41 AM To: Matt Caulfield (mcaulfie) Cc: Francois Le Faucheur (flefauch); draft-ietf-cdni-metadata@tools.ietf.or= g; ; Roy Peterkofsky; cdni@ietf.org Subject: Re: draft-ietf-cdni-metadata and ccid/sid Matt and all, Just did a little more thinking on this, and it occurred to me that: * while both CCID and SID need to be conveyed inside CDNI Logging * only CCID probably needs to be conveyed in CDN Metadata Basically, the idea is that the CCID is indeed distributed by uCDN to dCDN = (as a property of the content), the Session-ID (when supported) is somethin= g that is generated locally, on a per session basis obviously, by the dCDN.= So the SID shoudl not be distributed through CDNI metadata. I checked back in http://www.ietf.org/id/draft-brandenburg-cdni-has-05.txt = and the wording seems consistent with what I describe above. " ... a "Content Collection IDentifier (CCID)" field is distributed through the CDNI Metadata Interface and the same CCID value is associated through the CDNI Metadata interface with every chunk of the same Content Collection. =20 ... When distributed, and CCID logging is requested from the dCDN, the dCDN Surrogates are to store the CCID value in the corresponding log entries. " " , if the downstream CDN happens to have sufficient HAS awareness to be able to generate a "Session IDentifier (Session-ID)", optionally including such Session-ID (in addition to the CCID) in the per-chunk log record would further facilitate optional summarization performed at step [f].=20 " Do we all agree that CCID needs to be distributed in cdni-metadata but SID = need not? If yes, then: 1) sorry for misleading you earlier in requesting definition of SID in the= cdni-metadata document. 2) please have next rev of cdni-metadata defines CCID and not SID 2) we'll have cdni-logging refer to cdni-metadata for CCID , and cdni-logg= ing refer to cdni-has for SID. Cheers Francois On 10 Jun 2013, at 22:17, Matt Caulfield (mcaulfie) wr= ote: > Hello Francois, >=20 > A format for these fields is not yet defined. Both will be included in th= e next revision of the metadata draft. >=20 > Regards, > Matt >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Monday, June 10, 2013 8:50 AM > To: draft-ietf-cdni-metadata@tools.ietf.org > Cc: Francois Le Faucheur (flefauch); ; Roy Pe= terkofsky; cdni@ietf.org > Subject: draft-ietf-cdni-metadata and ccid/sid >=20 > To cdni-metadata authors, >=20 > In cdni-logging, we need to define logging fields to record the Content C= ollection ID (CCID) and Session ID (SID).=20 > Is a format for these fields already specified in cdni-metadata?=20 > If not, do you plan to do so in the next rev? >=20 > Thanks >=20 > Francois From D.Malas@cablelabs.com Wed Jun 19 08:38:18 2013 Return-Path: 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 06DF621F9CC9 for ; Wed, 19 Jun 2013 08:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 ZEnGZ5v8HXJe for ; Wed, 19 Jun 2013 08:38:12 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBD21F9BAC for ; Wed, 19 Jun 2013 08:38:12 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r5JFc899003246; Wed, 19 Jun 2013 09:38:09 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 19 Jun 2013 09:38:08 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0123.003; Wed, 19 Jun 2013 09:38:08 -0600 From: Daryl Malas To: "Kent Leung (kleung)" , "Lee, Yiu" Thread-Topic: [CDNi] Chair review of Requirements draft Thread-Index: AQHOWL4ol8g/hXc8EEqlADDdC7rE15ka9ZGAgAEFMoCAA+VXAIAddGmA Date: Wed, 19 Jun 2013 15:38:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.4.10.159] Content-Type: multipart/alternative; boundary="_000_CDE72C7ACDEDdmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Cc: "cdni@ietf.org" Subject: Re: [CDNi] Chair review of Requirements draft 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 15:38:18 -0000 --_000_CDE72C7ACDEDdmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This looks fine to me. --Daryl From: "Kent Leung (kleung)" > Date: Friday, May 31, 2013 9:49 AM To: "Lee, Yiu" = >, Daryl Malas > Cc: "cdni@ietf.org" > Subject: RE: [CDNi] Chair review of Requirements draft Hi Yiu. This looks good to me. Kent From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: Tuesday, May 28, 2013 9:20 PM To: Kent Leung (kleung); Daryl Malas Cc: cdni@ietf.org Subject: Re: [CDNi] Chair review of Requirements draft Hi Kent and Darly, I want to make a slight change of the abstract to make it even more objecti= ve: "Content Delivery Networks (CDNs) are frequently used for content delivery.= As a result of significant growth in content delivered over IP networks, e= xisting CDN providers are scaling up their infrastructure. Many Network Ser= vice Providers and Enterprise Service Providers are also deploying their ow= n CDNs. To deliver contents from the Content Service Protect (CSP) to end u= sers, the contents may traverse across multiple CDNs. This creates a need f= or interconnecting (previously) standalone CDNs so that they can collective= ly act as a single delivery platform from the CSP to the end users. The goal of this memo is to outline the requirements for the CDNI working g= roup." What do you guys think? Thanks, Yiu From: "Kent Leung (kleung)" > Date: Tuesday, May 28, 2013 4:58 PM To: Daryl Malas >, "Yiu= L. LEE" > Cc: "cdni@ietf.org" > Subject: RE: [CDNi] Chair review of Requirements draft KL> Just want to clarify. Is this text correct for the Abstract section? =93Content Delivery Networks (CDNs) are frequently used for large-scale con= tent delivery. As a result of the significant growth in content delivered o= ver IP networks, existing CDN providers are scaling up their infrastructure= and many Network Service Providers and Enterprise Service Providers are de= ploying their own CDNs. Subject to the policy of the CSP, it is generally d= esirable that a given item of content can be delivered to an end user regar= dless of that end user's location or attachment network. This creates a ne= ed for interconnecting (previously) standalone CDNs so they can interoperat= e and collectively behave as a single delivery infrastructure. The Content = Distribution Network Interconnection (CDNI) working group has been chartere= d to develop an interoperable and scalable solution for such CDN interconne= ction. The goal of the present document is to outline the requirements for the sol= ution and interfaces to be specified by the CDNI working group.=94 --_000_CDE72C7ACDEDdmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <28A5328C298F2248B644DE121A1797B5@cablelabs.com> Content-Transfer-Encoding: quoted-printable
This looks fine to me.  --Daryl

From: "Kent Leung (kleung)&quo= t; <kleung@cisco.com>
Date: Friday, May 31, 2013 9:49 AM<= br> To: "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>, D= aryl Malas <d.malas@cablelabs.c= om>
Cc: "cdni@ietf.org" <cdni@i= etf.org>
Subject: RE: [CDNi] Chair review of= Requirements draft

Hi Yiu. This looks good to me.

 

Kent

 

From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]
Sent: Tuesday, May 28, 2013 9:20 PM
To: Kent Leung (kleung); Daryl Malas
Cc: cdni@ietf.org
Subject: Re: [CDNi] Chair review of Requirements draft

 

Hi Kent and Darly,

 

I want to make a slight change of the abstr= act to make it even more objective:

 

"Content Delivery Networks (CDNs) are = frequently used for content delivery. As a result of significant growth in = content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Pr= oviders and Enterprise Service Providers are also deploying their own CDNs.= To deliver contents from the Content Service Protect (CSP) to end users, t= he contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standa= lone CDNs so that they can collectively act as a single delivery platform f= rom the CSP to the end users.

 

The goal of this memo is to outline the req= uirements for the CDNI working group."

 

What do you guys think?

 

Thanks,

Yiu

 

From: "Kent Leung (kleung)" <kleung@cisco.com>
Date: Tuesday, May 28, 2013 4:58 PM
To: Daryl Malas <D.Malas= @cablelabs.com>, "Yiu L. LEE" <yiu_lee@cable.comcast.com>
Cc: "cdni@ietf.org" &= lt;cdni@ietf.org>
Subject: RE: [CDNi] Chair review of Requirements draft

 

KL> Just want to clarify. Is this text correct for the= Abstract section?

 

=93Content Delivery Networks (CDNs) are frequently used f= or large-scale content delivery. As a result of the significant growth in c= ontent delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service= Providers and Enterprise Service Providers are deploying their own CDNs. S= ubject to the policy of the CSP, it is generally desirable that a given ite= m of content can be delivered to an end user regardless of that end user's location or attachment network.&= nbsp; This creates a need for interconnecting (previously) standalone CDNs = so they can interoperate and collectively behave as a single delivery infra= structure. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an inte= roperable and scalable solution for such CDN interconnection.

 

The goal of the present document is to outline the requir= ements for the solution and interfaces to be specified by the CDNI working = group.=94

 --_000_CDE72C7ACDEDdmalascablelabscom_-- From internet-drafts@ietf.org Tue Jun 25 07:22:47 2013 Return-Path: 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 6BF3721F9D92; Tue, 25 Jun 2013 07:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 1rT-ElxmyeLK; Tue, 25 Jun 2013 07:22:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEE721F9D2F; Tue, 25 Jun 2013 07:22:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130625142246.12522.99912.idtracker@ietfa.amsl.com> Date: Tue, 25 Jun 2013 07:22:46 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-04.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:22:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Iuniana Oprescu Francois Le Faucheur Roy Peterkofsky Filename : draft-ietf-cdni-logging-04.txt Pages : 41 Date : 2013-06-25 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From flefauch@cisco.com Tue Jun 25 07:32:50 2013 Return-Path: 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 91B1C21E8063 for ; Tue, 25 Jun 2013 07:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 KIbDlzX1mHDR for ; Tue, 25 Jun 2013 07:32:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D294C21E80DC for ; Tue, 25 Jun 2013 07:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11304; q=dns/txt; s=iport; t=1372170765; x=1373380365; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kWDj+1Qw1Tw/6/NjS++I67t/lvSeoEGDghXRmPOr25E=; b=AUxSfTfiGrefUONXGisjPqeQZv3iJejYTs8VRB/4Cuq3iSESpdxPPck1 ESfF3R6DV7C8QEiVCA8WKnpWuO8QnA1RsP7PsxK6/9k+OhSvD2ZQrOnxW DpUM+WeX2bAs2Byu8WsY4jQ4AJzwCyLZGfONXaufwGyvbM7r3d0Hwp6bG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoFANKoyVGtJV2Y/2dsb2JhbABAFwOCRUQxQwa/OYECFnSCJAEBAgIBAQFjAgYbAgEcDgoEDAMHJwsUEAECAQMTCAGIBQcFM61DjTqOAxt2DxEBCwEKAREHgmphA6kHgkBQgXE3 X-IronPort-AV: E=Sophos;i="4.87,937,1363132800"; d="scan'208,217";a="227211041" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2013 14:32:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PEWibG016214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Jun 2013 14:32:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 09:32:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNi] CDNI Logging - Series of Informal Meetings Thread-Index: AQHOSinCyYxSJinUj0azs1JHewNx8Jj34h8QgABXo4CATudvAA== Date: Tue, 25 Jun 2013 14:32:43 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D6775DBxmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:32:50 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D6775DBxmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D6775DBxmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <38BC0BD6F07747428DCB8E42A1516059@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meetin= g. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Ti= me, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last in= formal meeting's discussions. The key changes over -03 are:
* rewr= ite of all formats/rules aspects
* adde= d creation of three IANA registries to prepare for extensibility of CDNI Lo= gging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt<= br>
Diff from previous version:
h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04

Talk to you tomorrow

Francois




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging = - Informal Meeting 
Date: Wednesday, June 26, 2013&= nbsp;
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/= ciscosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&= amp;RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D6775DBxmbrcdx10ciscocom_-- From ray.vanbrandenburg@tno.nl Wed Jun 26 02:27:52 2013 Return-Path: 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 541E411E81A8 for ; Wed, 26 Jun 2013 02:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 o7iknYiT7jlw for ; Wed, 26 Jun 2013 02:27:47 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id F0FC721F9AE5 for ; Wed, 26 Jun 2013 02:27:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,943,1363129200"; d="scan'208,217";a="1734106" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 26 Jun 2013 11:27:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Wed, 26 Jun 2013 11:27:45 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: CDNi] CDNI Logging - Series of Informal Meetings Thread-Index: AQHOSinCyYxSJinUj0azs1JHewNx8Jj34h8QgABXo4CATudvAIAA5MtQ Date: Wed, 26 Jun 2013 09:27:44 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F3987BCEXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 09:27:52 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F3987BCEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Francois, all, I've just read through the latest iteration: my compliments, the document h= as improved significantly. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify 'Standards Action' as the method= for extending the registries. I was wondering what the reasoning behind th= is was? To me it seems unnecessarily strict, as well as being somewhat cont= radictory with the Editor's note included in the same section. We would ba= sically rule out any informational or experimental RFC, as well as propriet= ary logging fields or standardization efforts by other bodies. I would expe= ct some CDN vendors to want to do logging of additional fields. I would the= refore propose we go for 'Specification Required' or 'Expert Review'. Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581F3987BCEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Francoi= s, all,

 = ;

I’ve= just read through the latest iteration: my compliments, the document has i= mproved significantly.

 = ;

(Unfortuna= tely, I have not been able to join the CDNI Logging calls, and will not be = able to do so today as well. So the following point may have been discussed during the calls.)

 = ;

I noticed = that the IANA registries specify ‘Standards Action’ as the meth= od for extending the registries. I was wondering what the reasoning behind this was? To me it seems unnecessarily strict, as well as being somewhat c= ontradictory with the Editor’s note included in the same section. &nb= sp;We would basically rule out any informational or experimental RFC, as we= ll as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do log= ging of additional fields. I would therefore propose we go for ‘Speci= fication Required’ or ‘Expert Review’.

 = ;

Best regar= ds,

 = ;

Ray

 = ;

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

 

Hello,

 

Just a friendly reminder about tommorow's informal C= DNI Logging meeting. 

* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 C= entral European Time, for 90 minute

Webex details included below.

 

We just posted a new rev of cdni-logging that reflec= ts some of last informal meeting's discussions. The key changes over -03 ar= e:

* rewrite of all formats/rules aspects

* added creation of three IANA registries to prepare= for extensibility of CDNI Logging


A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt<= br>
Diff from previous version:
h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04=

 

Talk to you tomorrow

 

Francois

 

 




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/cis= cosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&= ;RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F3987BCEXCMBX03tsntnon_-- From flefauch@cisco.com Wed Jun 26 07:47:40 2013 Return-Path: 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 A0B1E11E811A for ; Wed, 26 Jun 2013 07:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 cpMHj6aqFpP5 for ; Wed, 26 Jun 2013 07:47:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F165621F9057 for ; Wed, 26 Jun 2013 07:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12196; q=dns/txt; s=iport; t=1372258056; x=1373467656; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2tNaLw7JAWP1lI45JlK/iejowZzTemv+FhDjrN/Vzd4=; b=HrULhsCgMAKsgVtaW3LlFZg5rZaFWl1a0w+Z4MCylfJeK4LuPFOUNi7i LEBI4H8B/iSEYH20+bFqfkX00ISBH42pOOB0znQEbZYDQvqdI9H6G3cFl H27bb3s2EJck2Mx7mftJhy1b+3Gt4NZMBzSE2zE2BUCEGIbZ7vM4qCq7M Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAEX+ylGtJXG8/2dsb2JhbABAFwOCRUQxQwa+e4EAFnSCJAEBAgIBAQFjAgYbAgEcDgoEDAMHJwsUEAECAQMTCAGIBQcFM6x0jTmOCRt2DxEBCwEKAREHgmphA6kKgVhpUIFxNw X-IronPort-AV: E=Sophos;i="4.87,944,1363132800"; d="scan'208,217";a="227483289" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2013 14:47:33 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5QElXP9022544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Jun 2013 14:47:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 09:47:32 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: (friendly reminder: meeting starting in 15 minutes) CDNI Logging - Series of Informal Meetings Thread-Index: AQHOcnwWmoa05WSq+EqPtK6koOlOrw== Date: Wed, 26 Jun 2013 14:47:32 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D67BFBFxmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] (friendly reminder: meeting starting in 15 minutes) CDNI Logging - Series of Informal Meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:47:40 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D67BFBFxmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 25 Jun 2013, at 16:32, Francois Le Faucheur (flefauch) > wrote: Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D67BFBFxmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <114B8AACA6A76543AF44C20EB28C9AF4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 25 Jun 2013, at 16:32, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meetin= g. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Ti= me, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last in= formal meeting's discussions. The key changes over -03 are:
* rewr= ite of all formats/rules aspects
* adde= d creation of three IANA registries to prepare for extensibility of CDNI Lo= gging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt<= br>
Diff from previous version:
h= ttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04

Talk to you tomorrow

Francois




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging = - Informal Meeting 
Date: Wednesday, June 26, 2013&= nbsp;
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/= ciscosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&= amp;RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--_000_FC236DA6F2DA77449EF2D02DF4471A8D67BFBFxmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Jun 26 07:58:21 2013 Return-Path: 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 495E621E8092 for ; Wed, 26 Jun 2013 07:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 GfPUgA4U7YXG for ; Wed, 26 Jun 2013 07:58:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB221F9A72 for ; Wed, 26 Jun 2013 07:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27561; q=dns/txt; s=iport; t=1372258696; x=1373468296; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0A4w3pl1y62LAn/2hjh/Ms3OXZkiE78dth82LH8bsCc=; b=CnsBcRlu9RybNMxe7nON/0oX0cWFRP/Kma7nW048n/n9ovZZ12+SqCtj +Wdj+aaJOOZ1OQtdjI0T2e1hS3PdJlqVV+lPWuafOFZ8Cp/bzAjhNjvPV uRDRKkTbphX1iMjoJxjR8fTqJg6ft0C/mIWmMjrsZB9vq525yL3TenrOA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANQAy1GtJXHA/2dsb2JhbABAFwOCRUQxQwa+e4EAFnSCIwEBAQICAQEBYwIDAwsQAgEIEQMBAQELCgQIBAMHJwsUCQcBAgEDDgUIAYgFBwUzrG+NNo4JEAtvBw8RAQsBBAYBBgsHgmphA6kKgTSBDVCBcTc X-IronPort-AV: E=Sophos;i="4.87,944,1363132800"; d="scan'208,217";a="227672654" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jun 2013 14:58:15 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5QEwEIM000985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 14:58:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 09:58:14 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: CDNi] CDNI Logging - Series of Informal Meetings Thread-Index: AQHOSinCyYxSJinUj0azs1JHewNx8Jj34h8QgABXo4CATudvAIAA5MtQgAC0qgA= Date: Wed, 26 Jun 2013 14:58:13 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D67C050xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 14:58:21 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D67C050xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FC236DA6F2DA77449EF2D02DF4471A8D67C050xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 wrote:

Hi Francois, all,
 
I=92ve just read through the latest iterat= ion: my compliments, the document has improved significantly.

Appreciated.

 
(Unfortunately, I have not been able to jo= in the CDNI Logging calls, and will not be able to do so today as well. So = the following point may have been discussed during the calls.) 
I noticed that the IANA registries specify= =91Standards Action=92 as the method for extending the registries. I was w= ondering what the reasoning behind this was?

It is just that at teh time of writing, it was clear that some al= location had to go through standards track (eg the WG defines a new type of= CDNI Logging record for Request Routing which requires a new Record-Type a= nd say a couple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for t= he rest (hence teh Editor's note).

To me it seems unnecessarily strict, as we= ll as being somewhat contradictory with the Editor=92s note included in the= same section.  We would basically rule out any informational or experimental RFC, as well as proprietary logging = fields or standardization efforts by other bodies. I would expect some CDN = vendors to want to do logging of additional fields. I would therefore propo= se we go for =91Specification Required=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly so= mehow vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IE= TF involvement) to allow vendors to experiment with extensions (eg Private/= experimental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois


 
Best regards,
 
Ray
 
 
Hello,
 
Just a friendly reminder about tommorow's informal CDNI Logging meeting.&nb= sp;
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute
Webex details included below.
 
We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.o= rg/internet-drafts/draft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-cdni-logging-04
 
Talk to you tomorrow
 
Francois
 
 



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic:= IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013&= nbsp;
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D= 484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_re= strictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 
_____________________________________________=
___________________________________________________________________________=
_
 
Ce message et ses pieces jointes peuvent cont=
enir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans a=
utorisation. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
France Telecom - Orange decline toute respons=
abilite si ce message a ete altere, deforme ou falsifie. Merci.<=
/span>
 
This message and its attachments may contain =
confidential or privileged information that may be protected by law;
they should not be distributed, used or copie=
d without authorisation.
If you have received this email in error, ple=
ase notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Or=
ange is not liable for messages that have been modified, changed or falsifi=
ed.
Thank you.
 
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i
 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer


--_000_FC236DA6F2DA77449EF2D02DF4471A8D67C050xmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Jun 26 10:39:58 2013 Return-Path: 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 47A6411E8110 for ; Wed, 26 Jun 2013 10:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 i7lXUB7ZWhGj for ; Wed, 26 Jun 2013 10:39:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 83CC011E80F5 for ; Wed, 26 Jun 2013 10:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33128; q=dns/txt; s=iport; t=1372268377; x=1373477977; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GQDwjm3mzAl6qrh6vrV0uicVwYbrCwQ7Bok1YmlTxnk=; b=Ip7E/8/Uw4QzwTXlEjKwnyC/tBvZ0RcB2qagHydSoCtyeqmkWEhay/yy edoquhYn1v1Phlyk4eAfvYkU+ju6u+UDWD2HCMEJIntcNqYImHc66k50L YHIb+V3DEIMj3bthsqV8w+kNPCa5gpyt7EnjLYG9NRupgovNzEDlv32RF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANomy1GtJXHA/2dsb2JhbABBFwOCRUQxQwa+fYEDFnSCIwEBAQICAQEBYwIDAwsQAgEZAwEBAQsKBAgBAwMHJwsUCQcBAgEDDgUIAYgFBwUzrB6NM44JEAtvBw8RAQsBBAYBBgsHgmphA6kKgTSBDVCBcTc X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208,217";a="224804268" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 26 Jun 2013 17:39:36 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5QHdaG1022936 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 17:39:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 12:39:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyg== Date: Wed, 26 Jun 2013 17:39:35 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D67DB47xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:39:58 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D67DB47xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FC236DA6F2DA77449EF2D02DF4471A8D67DB47xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <31B2D1AEBAA75A4BBAACAFE4F32C0A4D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There= was convergence on adding both a "private use" and a "speci= fication required" namespaces. As an example, below is what I drafted = for the first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Lo=
gging Directive Names Registry

   The IANA is requested to create a new registry, CDNI Logging
   Directive Names.

   The initial contents of the CDNI Logging File Directives registry
   comprise the names of the directives specified in Section 3.3 of the
   present document, and are as follows:

    +------------------------------+-----------+
    + Directive name               + Reference |
    +------------------------------+-----------+
    + Version                      + RFC xxxx  |
    + UUID                         + RFC xxxx  |
    + Claimed-Origin               + RFC xxxx  |
    + Verified-Origin              + RFC xxxx  |
    + Record-Type                  + RFC xxxx  |
    + Fields                       + RFC xxxx  |
    + Integrity-Hash               + RFC xxxx  |
    +------------------------------+-----------+

                                 Figure 4

   [Instructions to IANA: Replace "RFC xxxx" above by the RFC num=
ber of
   the present document]

   Within the registry:

   o  the subset of the namespace starting with "x" "-"=
 is set aside for
      "Private Use" as specified in [RFC5226].  To minimize confl=
icts in
      the names used, the name MUST be structured as : "x" "=
-" "vendor-
      ID" "-" "vendor-specific-cdni-logging-directive-n=
ame" where the
      "vendor-ID" identifies the vendor and the "vendor-spec=
ific- cdni-
      logging-directive-name" identifies the actual vendor-specific
      directive.  For example, a vendor specific directive name could
      look like "x-vendor1-interesting_directive1".

   o  the subset of the namespace starting with "r" "-"=
 is to be
      allocated by IANA according to the "Specification Required"=
 policy
      specified in [RFC5226].

   o  the rest of the namespace is to be allocated by IANA according to
      the "Standards Action" policy specified in [RFC5226].





On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" = <flefauch@cisco.com>
 wrote:

Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 wrote:

Hi Francois, all,
 
I=92ve just read through the latest iterat= ion: my compliments, the document has improved significantly.

Appreciated.

 
(Unfortunately, I have not been able to jo= in the CDNI Logging calls, and will not be able to do so today as well. So = the following point may have been discussed during the calls.) 
I noticed that the IANA registries specify= =91Standards Action=92 as the method for extending the registries. I was w= ondering what the reasoning behind this was?

It is just that at teh time of writing, it was clear that some al= location had to go through standards track (eg the WG defines a new type of= CDNI Logging record for Request Routing which requires a new Record-Type a= nd say a couple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for t= he rest (hence teh Editor's note).

To me it seems unnecessarily strict, as we= ll as being somewhat contradictory with the Editor=92s note included in the= same section.  We would basically rule out any informational or experimental RFC, as well as proprietary logging = fields or standardization efforts by other bodies. I would expect some CDN = vendors to want to do logging of additional fields. I would therefore propo= se we go for =91Specification Required=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly so= mehow vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IE= TF involvement) to allow vendors to experiment with extensions (eg Private/= experimental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois


 
Best regards,
 
Ray
 
 
Hello,
 
Just a friendly reminder about tommorow's informal CDNI Logging meeting.&nb= sp;
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute
Webex details included below.
 
We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.o= rg/internet-drafts/draft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-cdni-logging-04
 
Talk to you tomorrow
 
Francois
 
 



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic:= IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013&= nbsp;
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D= 484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_re= strictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 
_____________________________________________=
___________________________________________________________________________=
_
 
Ce message et ses pieces jointes peuvent cont=
enir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans a=
utorisation. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les p=
ieces jointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
France Telecom - Orange decline toute respons=
abilite si ce message a ete altere, deforme ou falsifie. Merci.<=
/span>
 
This message and its attachments may contain =
confidential or privileged information that may be protected by law;
they should not be distributed, used or copie=
d without authorisation.
If you have received this email in error, ple=
ase notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Or=
ange is not liable for messages that have been modified, changed or falsifi=
ed.
Thank you.
 
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i
 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer



--_000_FC236DA6F2DA77449EF2D02DF4471A8D67DB47xmbrcdx10ciscocom_-- From internet-drafts@ietf.org Wed Jun 26 14:09:27 2013 Return-Path: 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 12DED21F9B18; Wed, 26 Jun 2013 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 w+J+QjM+amcE; Wed, 26 Jun 2013 14:09:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EC621F9B11; Wed, 26 Jun 2013 14:08:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626210841.856.94944.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 14:08:41 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-08.txt 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 21:09:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-08.txt Pages : 24 Date : 2013-06-26 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Protect (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ray.vanbrandenburg@tno.nl Thu Jun 27 00:12:51 2013 Return-Path: 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 048D721F9C34 for ; Thu, 27 Jun 2013 00:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 tSw0vWhBDdpL for ; Thu, 27 Jun 2013 00:12:46 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7446721F9BC3 for ; Thu, 27 Jun 2013 00:12:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,950,1363129200"; d="scan'208,217";a="10487521" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 27 Jun 2013 09:12:43 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Thu, 27 Jun 2013 09:12:43 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: CDNI Logging - IANA section Thread-Index: AQHOcpQiYElU0rGXcEi92CQXnyNSh5lJI1fg Date: Thu, 27 Jun 2013 07:12:43 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F39A76DEXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 07:12:51 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39A76DEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Seems like a good solution. One small note: for the Field Name Registry, you currently use various pref= ixes (e.g. 'c-', 's-', 'u-') as abbreviations. It might be good to refrain = from that in the new version, since now you're also using prefixes to indic= ate namespaces (e.g. 'r' and 'x'). Cheers, Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: woensdag 26 juni 2013 19:40 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org Subject: CDNI Logging - IANA section Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I've just read through the latest iteration: my compliments, the document h= as improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify 'Standards Action' as the method= for extending the registries. I was wondering what the reasoning behind th= is was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor's note included in the same section. We would basically = rule out any informational or experimental RFC, as well as proprietary logg= ing fields or standardization efforts by other bodies. I would expect some = CDN vendors to want to do logging of additional fields. I would therefore p= ropose we go for 'Specification Required' or 'Expert Review'. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39A76DEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 <= /p>

Seems like a good solutio= n.

 <= /p>

One small = note: for the Field Name Registry, you currently use various prefixes (e.g.= ‘c-’, ‘s-’, ‘u-’) as abbreviations. It= might be good to refrain from that in the new version, since now you’re also using prefixes t= o indicate namespaces (e.g. ‘r’ and ‘x’).

 = ;

Cheers,

 = ;

Ray

 = ;

From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisc= o.com]
Sent: woensdag 26 juni 2013 19:40
To: Brandenburg, R. (Ray) van
Cc: cdni@ietf.org
Subject: CDNI Logging - IANA section

 

Hi Ray,

 

We discussed the IANA allocation policy at the infor= mal meeting. There was convergence on adding both a "private use"= and a "specification required" namespaces. As an example, below = is what I drafted for the first IANA registry. Let us know if you have comments.

 

Cheers

 

Francois

 

6.1.  CDNI L=
ogging Directive Names Registry
 
   The IANA is requested to create a new registry, CDNI Logg=
ing
   Directive Names.
 
   The initial contents of the CDNI Logging File Directives =
registry
   comprise the names of the directives specified in Section=
 3.3 of the
   present document, and are as follows:
 
    +------------------------------+-----------=
+
    + Directive name     &=
nbsp;         + Reference |
    +------------------------------+-----------=
+
    + Version      &n=
bsp;            =
;   + RFC xxxx  |
    + UUID       =
;            &n=
bsp;     + RFC xxxx  |
    + Claimed-Origin     &=
nbsp;         + RFC xxxx  =
|
    + Verified-Origin     =
         + RFC xxxx  |
    + Record-Type     &nbs=
p;            + =
RFC xxxx  |
    + Fields      &nb=
sp;            =
    + RFC xxxx  |
    + Integrity-Hash     &=
nbsp;         + RFC xxxx  =
|
    +------------------------------+-----------=
+
 
           &nbs=
p;            &=
nbsp;        Figure 4
 
   [Instructions to IANA: Replace "RFC xxxx" above=
 by the RFC number of
   the present document]
 
   Within the registry:
 
   o  the subset of the namespace starting with "x=
" "-" is set aside for
      "Private Use" as specified in=
 [RFC5226].  To minimize conflicts in
      the names used, the name MUST be struct=
ured as : "x" "-" "vendor-
      ID" "-" "vendor-spe=
cific-cdni-logging-directive-name" where the
      "vendor-ID" identifies the ve=
ndor and the "vendor-specific- cdni-
      logging-directive-name" identifies=
 the actual vendor-specific
      directive.  For example, a vendor =
specific directive name could
      look like "x-vendor1-interesting_d=
irective1".
 
   o  the subset of the namespace =
starting with "r" "-" is to be
      allocated b=
y IANA according to the "Specification Required" policy
      specified in [RFC5226].

 


   o  the rest of the namespace is to be allocated by I=
ANA according to


      the "Standards Action" policy=
 specified in [RFC5226].




 

 

 

 

 

On 26 Jun 2013, at 16:58, "Francois Le Faucheur= (flefauch)" <flefauch@cisco.= com>

 wrote:



Hello Ray,

 

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray= ) van" <ray.vanbranden= burg@tno.nl>

 wrote:



Hi Francoi= s, all,

 

I’ve= just read through the latest iteration: my compliments, the document has i= mproved significantly.

 

Appreciated.



 

(Unfortuna= tely, I have not been able to join the CDNI Logging calls, and will not be = able to do so today as well. So the following point may have been discussed during the calls.) <= /span>

I noticed = that the IANA registries specify ‘Standards Action’ as the meth= od for extending the registries. I was wondering what the reasoning behind this was?

 

It is just that at teh time of writing, it was clear= that some allocation had to go through standards track (eg the WG def= ines a new type of CDNI Logging record for Request Routing which requires a= new Record-Type and say a couple new CDNI Logging fields) and it needed a bit more thinking about how much flexibili= ty we need for the rest (hence teh Editor's note).

 

To me it s= eems unnecessarily strict, as well as being somewhat contradictory with the= Editor’s note included in the same section.  We would basically rule out any informational or experimental RFC, as well as proprietary log= ging fields or standardization efforts by other bodies. I would expect some= CDN vendors to want to do logging of additional fields. I would therefore = propose we go for ‘Specification Required’ or ‘Expert Review’.

 

I agree flexibility needs to be added. 

I am happy to allow something which requires an open= spec (possibly somehow vetted by the IETF) (e.g. Specification Required or= Expert Review).

I think we should also have a very light-weight proc= ess (ie without IETF involvement) to allow vendors to experiment with exten= sions (eg Private/experimental use).

I'll try collect more input at today's informal meet= ing.

 

Thanks

 

Francois

 



 

Best regar= ds,

 

Ray=

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois L= e Faucheur (flefauch)
Sent: dinsdag 25 j= uni 2013 16:33
To: cdni@ietf.org Subject: [CDNi] CD= Ni] CDNI Logging - Series of Informal Meetings

 

Hello,

 

Just a friendly reminder about tommorow's informal C= DNI Logging meeting. 

* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 C= entral European Time, for 90 minute

Webex details included below.

 

We just posted a new rev of cdni-logging that reflec= ts some of last informal meeting's discussions. The key changes over -03 ar= e:

* rewrite of all formats/rules aspects

* added creation of three IANA registries to prepare= for extensibility of CDNI Logging

 

Talk to you tomorrow

 

Francois

 

 





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/cis= cosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&= ;RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:208 330 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation. = 

____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org=
https://www.ietf.org/mailman/listinfo/cdni

 

This e-mail and its contents are subject to the DISCLAIME= R at http://www.tno.nl/em= aildisclaimer

 

 

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F39A76DEXCMBX03tsntnon_-- From ben@niven-jenkins.co.uk Thu Jun 27 01:35:26 2013 Return-Path: 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 95BB821F9C72 for ; Thu, 27 Jun 2013 01:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.603 X-Spam-Level: X-Spam-Status: No, score=-100.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, MIME_QP_LONG_LINE=1.396, 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 UqxKqG6PqJfj for ; Thu, 27 Jun 2013 01:35:22 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 136AA21F9C66 for ; Thu, 27 Jun 2013 01:35:21 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail12.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Us7fj-00029l-GR; Thu, 27 Jun 2013 09:35:20 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 27 Jun 2013 09:35:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 08:35:26 -0000 Francois, I haven't considered the proposal in detail but proposing an x- prefix = reminded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember = whether it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: > Hi Ray, >=20 > We discussed the IANA allocation policy at the informal meeting. There = was convergence on adding both a "private use" and a "specification = required" namespaces. As an example, below is what I drafted for the = first IANA registry. Let us know if you have comments. >=20 > Cheers >=20 > Francois >=20 > 6.1. CDNI Logging Directive Names Registry >=20 > The IANA is requested to create a new registry, CDNI Logging > Directive Names. >=20 > The initial contents of the CDNI Logging File Directives registry > comprise the names of the directives specified in Section 3.3 of = the > present document, and are as follows: >=20 > +------------------------------+-----------+ > + Directive name + Reference | > +------------------------------+-----------+ > + Version + RFC xxxx | > + UUID + RFC xxxx | > + Claimed-Origin + RFC xxxx | > + Verified-Origin + RFC xxxx | > + Record-Type + RFC xxxx | > + Fields + RFC xxxx | > + Integrity-Hash + RFC xxxx | > +------------------------------+-----------+ >=20 > Figure 4 >=20 > [Instructions to IANA: Replace "RFC xxxx" above by the RFC number = of > the present document] >=20 > Within the registry: >=20 > o the subset of the namespace starting with "x" "-" is set aside = for > "Private Use" as specified in [RFC5226]. To minimize conflicts = in > the names used, the name MUST be structured as : "x" "-" = "vendor- > ID" "-" "vendor-specific-cdni-logging-directive-name" where the > "vendor-ID" identifies the vendor and the "vendor-specific- = cdni- > logging-directive-name" identifies the actual vendor-specific > directive. For example, a vendor specific directive name could > look like "x-vendor1-interesting_directive1". >=20 > o the subset of the namespace starting with "r" "-" is to be > allocated by IANA according to the "Specification Required" = policy > specified in [RFC5226]. >=20 > o the rest of the namespace is to be allocated by IANA according = to > the "Standards Action" policy specified in [RFC5226]. >=20 >=20 >=20 >=20 >=20 >=20 > On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" = > wrote: >=20 >> Hello Ray, >>=20 >> On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" = >> wrote: >>=20 >>> Hi Francois, all, >>> =20 >>> I=92ve just read through the latest iteration: my compliments, the = document has improved significantly. >>=20 >> Appreciated. >>=20 >>> =20 >>> (Unfortunately, I have not been able to join the CDNI Logging calls, = and will not be able to do so today as well. So the following point may = have been discussed during the calls.)=20 >>> I noticed that the IANA registries specify =91Standards Action=92 as = the method for extending the registries. I was wondering what the = reasoning behind this was? >>=20 >> It is just that at teh time of writing, it was clear that some = allocation had to go through standards track (eg the WG defines a new = type of CDNI Logging record for Request Routing which requires a new = Record-Type and say a couple new CDNI Logging fields) and it needed a = bit more thinking about how much flexibility we need for the rest (hence = teh Editor's note). >>=20 >>> To me it seems unnecessarily strict, as well as being somewhat = contradictory with the Editor=92s note included in the same section. We = would basically rule out any informational or experimental RFC, as well = as proprietary logging fields or standardization efforts by other = bodies. I would expect some CDN vendors to want to do logging of = additional fields. I would therefore propose we go for =91Specification = Required=92 or =91Expert Review=92. >>=20 >> I agree flexibility needs to be added.=20 >> I am happy to allow something which requires an open spec (possibly = somehow vetted by the IETF) (e.g. Specification Required or Expert = Review). >> I think we should also have a very light-weight process (ie without = IETF involvement) to allow vendors to experiment with extensions (eg = Private/experimental use). >> I'll try collect more input at today's informal meeting. >>=20 >> Thanks >>=20 >> Francois >>=20 >>=20 >>> =20 >>> Best regards, >>> =20 >>> Ray >>> =20 >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur (flefauch) >>> Sent: dinsdag 25 juni 2013 16:33 >>> To: cdni@ietf.org >>> Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings >>> =20 >>> Hello, >>> =20 >>> Just a friendly reminder about tommorow's informal CDNI Logging = meeting.=20 >>> * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute >>> Webex details included below. >>> =20 >>> We just posted a new rev of cdni-logging that reflects some of last = informal meeting's discussions. The key changes over -03 are: >>> * rewrite of all formats/rules aspects >>> * added creation of three IANA registries to prepare for = extensibility of CDNI Logging >>>=20 >>> A new version (-04) has been submitted for draft-ietf-cdni-logging: >>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt >>>=20 >>> Diff from previous version: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 >>> =20 >>> Talk to you tomorrow >>> =20 >>> Francois >>> =20 >>> =20 >>>=20 >>>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Topic: IETF CDNI Logging - Informal Meeting=20 >>> Date: Wednesday, June 26, 2013=20 >>> Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)=20 >>> Meeting Number: 208 330 914=20 >>> Password: cdni=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the meeting online(Now from mobile devices!)=20 >>> -------------------------------------------------------=20 >>> 1. Go to = https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D484318167&PW= =3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D=20 >>> 2. If requested, enter your name and email address.=20 >>> 3. If a password is required, enter the meeting password: cdni=20 >>> 4. Click "Join".=20 >>> 5. If the meeting includes a teleconference, follow the instructions = that appear on your screen.=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the audio conference only=20 >>> -------------------------------------------------------=20 >>> To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 >>> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >>> Call-in toll number (US/Canada): +1-408-525-6800=20 >>> Toll-free dialing restrictions: = http://www.webex.com/pdf/tollfree_restrictions.pdf=20 >>>=20 >>> Access code:208 330 914=20 >>>=20 >>> CCP:+14085256800x208330914#=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the session to be recorded. By joining this session, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the session. Please note that any such = recordings may be subject to discovery in the event of litigation.=20 >>> = __________________________________________________________________________= _______________________________________________ >>> =20 >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >>> =20 >>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. >>> Thank you. >>> =20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> =20 >>> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >>>=20 >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From iuniana.oprescu@orange.com Thu Jun 27 02:00:02 2013 Return-Path: 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 94CDF21F9CA1 for ; Thu, 27 Jun 2013 02:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, UNPARSEABLE_RELAY=0.001] 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 IY7BTmPgEv6x for ; Thu, 27 Jun 2013 01:59:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D379A21F9C8B for ; Thu, 27 Jun 2013 01:59:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 36C3122D3C9; Thu, 27 Jun 2013 10:59:56 +0200 (CEST) Received: from PMEXCH21.intranet-paris.francetelecom.fr (unknown [10.100.76.20]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1A94A35C04E; Thu, 27 Jun 2013 10:59:56 +0200 (CEST) Received: from PMEXCB1D.intranet-paris.francetelecom.fr ([10.100.76.7]) by PMEXCH21.intranet-paris.francetelecom.fr ([10.100.76.20]) with mapi; Thu, 27 Jun 2013 10:59:55 +0200 From: To: "Brandenburg, R. (Ray) van" , "Francois Le Faucheur (flefauch)" Date: Thu, 27 Jun 2013 10:59:54 +0200 Thread-Topic: CDNI Logging - IANA section Thread-Index: AQHOcpQiYElU0rGXcEi92CQXnyNSh5lJI1fggAAgm1A= Message-ID: <8547_1372323596_51CBFF0C_8547_2071_1_8F0D2F5E4AAB7249BC7339A3E944DEDD2226F0F817@PMEXCB1D.intranet-paris.francetelecom.fr> References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: multipart/alternative; boundary="_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2226F0F817PMEXCB1Dintra_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.27.62425 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:00:02 -0000 --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2226F0F817PMEXCB1Dintra_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Heya, We could use x. and r. instead of x- and r-, that would eliminate possible = misunderstandings... -- iuniana ________________________________ De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Bra= ndenburg, R. (Ray) van Envoy=E9 : jeudi 27 juin 2013 09:13 =C0 : Francois Le Faucheur (flefauch) Cc : cdni@ietf.org Objet : Re: [CDNi] CDNI Logging - IANA section Hi Francois, Seems like a good solution. One small note: for the Field Name Registry, you currently use various pref= ixes (e.g. 'c-', 's-', 'u-') as abbreviations. It might be good to refrain = from that in the new version, since now you're also using prefixes to indic= ate namespaces (e.g. 'r' and 'x'). Cheers, Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: woensdag 26 juni 2013 19:40 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org Subject: CDNI Logging - IANA section Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I've just read through the latest iteration: my compliments, the document h= as improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify 'Standards Action' as the method= for extending the registries. I was wondering what the reasoning behind th= is was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor's note included in the same section. We would basically = rule out any informational or experimental RFC, as well as proprietary logg= ing fields or standardization efforts by other bodies. I would expect some = CDN vendors to want to do logging of additional fields. I would therefore p= ropose we go for 'Specification Required' or 'Expert Review'. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2226F0F817PMEXCB1Dintra_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Heya,
 
We could use x. and r. instead of x- and r-, that = would=20 eliminate possible misunderstandings...
 
-- iuniana

De : cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] De la part de Brandenburg, R. (Ray)= =20 van
Envoy=E9 : jeudi 27 juin 2013 09:13
=C0 :=20 Francois Le Faucheur (flefauch)
Cc :=20 cdni@ietf.org
Objet : Re: [CDNi] CDNI Logging - IANA=20 section

Hi=20 Francois,

 

Seems=20 like a good solution.

 

One=20 small note: for the Field Name Registry, you currently use various prefix= es=20 (e.g. =91c-=92, =91s-=92, =91u-=92) as abbreviations. It might be good to= refrain from=20 that in the new version, since now you=92re also using prefixes to indica= te=20 namespaces (e.g. =91r=92 and =91x=92).

 

Cheers,

 

Ray

 

From:

 

Cheers

 

Francois

 

6.1.  CDNI Logging Directi=
ve Names Registry
 
 &n=
bsp; The IANA is requested to create a new registry, CDNI Logging
   Directive Names.
 <=
/o:p>
   The initial contents of the CDNI Logging File =
Directives registry
   comprise the names of=
 the directives specified in Section 3.3 of the
 =
  present document, and are as follows:
&nbs=
p;
    +------------------------------+-----=
------+
    + Directive name  =
;             +=
 Reference |
    +---------------------=
---------+-----------+
    + Version&nb=
sp;            =
         + RFC xxxx  |
    + UUID      =
            &nb=
sp;      + RFC xxxx  |
&=
nbsp;   + Claimed-Origin       =
;        + RFC xxxx  |
    + Verified-Origin     =
         + RFC xxxx  |
    + Record-Type     =
;             +=
 RFC xxxx  |
    + Fields &nb=
sp;            =
         + RFC xxxx  |
    + Integrity-Hash    &n=
bsp;          + RFC xxxx =
 |
    +------------------------------+=
-----------+
 
  &=
nbsp;           &nbs=
p;            &=
nbsp;     Figure 4
 
   [Instructions to IANA: Replace "RFC xxxx" above b=
y the RFC number of
   the present document]=

 
   Within the r=
egistry:
 
   o&nb=
sp; the subset of the namespace starting with "x" "-" is set aside for=

      "Private Use" as specified =
in [RFC5226].  To minimize conflicts in
 &nb=
sp;    the names used, the name MUST be structured as : "x" =
"-" "vendor-
      ID" "-" "v=
endor-specific-cdni-logging-directive-name" where the
=
      "vendor-ID" identifies the vendor and the "v=
endor-specific- cdni-
      l=
ogging-directive-name" identifies the actual vendor-specific
      directive.  For example, a vendo=
r specific directive name could
   &nbs=
p;  look like "x-vendor1-interesting_directive1".
 
   o  the su=
bset of the namespace starting with "r" "-" is to be
      allocated by=
 IANA according to the "Specification Required" policy
      specified in [RFC5226].
 
   o  the rest of the namespac=
e is to be allocated by IANA according to
  =
    the "Standards Action" policy specified in [RFC5226].

 

 

 

 

 

On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)"=20 <flefauch@cisco.com><= /P>

 wrote:



Hello Ray,

 

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van= "=20 <ray.vanbrandenburg@tno.nl&g= t;

 wrote:



Hi=20 Francois, all,

 

I=92ve=20 just read through the latest iteration: my compliments, the document has= =20 improved significantly.

 

Appreciated.



 

(Unfortunately,=20 I have not been able to join the CDNI Logging calls, and will not be able= to=20 do so today as well. So the following point may have been discussed durin= g the=20 calls.) 

I=20 noticed that the IANA registries specify =91Standards Action=92 as the = method=20 for extending the registries. I was wondering what the reasoning behind= this=20 was?

 

It is just that at teh time of writing, it was clear= that=20 some allocation had to go through standards track (eg the WG defines= a=20 new type of CDNI Logging record for Request Routing which requires a new= =20 Record-Type and say a couple new CDNI Logging fields) and it needed a bit= more=20 thinking about how much flexibility we need for the rest (hence teh Edito= r's=20 note).

 

To=20 me it seems unnecessarily strict, as well as being somewhat contradicto= ry=20 with the Editor=92s note included in the same section.  We would= =20 basically rule out any informational or experimental RFC, as well as=20 proprietary logging fields or standardization efforts by other bodies. = I=20 would expect some CDN vendors to want to do logging of additional field= s. I=20 would therefore propose we go for =91Specification Required=92 or =91Ex= pert=20 Review=92.

 

I agree flexibility needs to be=20 added. 

I am happy to allow something which requires an open= spec=20 (possibly somehow vetted by the IETF) (e.g. Specification Required or Exp= ert=20 Review).

I think we should also have a very light-weight proc= ess (ie=20 without IETF involvement) to allow vendors to experiment with extensions = (eg=20 Private/experimental use).

I'll try collect more input at today's informal=20 meeting.

 

Thanks

 

Francois

 



 

Best=20 regards,

 

Ray

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur=20 (flefauch)
Sent: dinsdag 25 juni 2013=20 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Se= ries of=20 Informal Meetings

 

Hello,

 

Just a friendly reminder about tommorow's informal C= DNI=20 Logging meeting. 

* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00= Central=20 European Time, for 90 minute

Webex details included below.

 

We just posted a new rev of cdni-logging that reflec= ts some=20 of last informal meeting's discussions. The key changes over -03=20 are:

* rewrite of all formats/rules=20 aspects

* added creation of three IANA registries to prepare= for=20 extensibility of CDNI Logging


A new version (-04) has been submitted for=20 draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cd= ni-logging-04.txt

Diff=20 from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdn= i-logging-04

 

Talk to you tomorrow

 

Francois

 

 





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI= Logging=20 - Informal Meeting 
Date: Wed= nesday,=20 June 26, 2013 
Time: 5:00 pm, Europe Summer Time (Pa= ris,=20 GMT+02:00) 
Meeting Number: 208 330 914 
Password:=20 cdni 

-----------------------------------------------------= -- 
To=20 join the meeting online(Now from mobile=20 devices!) 
----------------------------------------------------= --- 
1.=20 Go to https://cis= co.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DN= NzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 
2. If= =20 requested, enter your name and email address. 
3. If a password= is=20 required, enter the meeting password: cdni 
4. Click=20 "Join". 
5. If the meeting includes a teleconference, follow th= e=20 instructions that appear on your=20 screen. 

--------------------------------------------------= ----- 
To=20 join the audio conference=20 only 
-------------------------------------------------------&n= bsp;
To=20 receive a call back, provide your phone number when you join the meetin= g, or=20 call the number below and enter the access code. 
Call-in toll-= free=20 number (US/Canada): +1-866-432-9903 
Call-in toll number=20 (US/Canada): +1-408-525-6800 
Toll-free dialing=20 restrictions: http://www.= webex.com/pdf/tollfree_restrictions.pdf 

Ac= cess=20 code:208 330=20 914 

CCP:+14085256800x208330914# 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This= WebEx=20 service includes a feature that allows audio and any documents and othe= r=20 materials exchanged or viewed during the session to be recorded. By joi= ning=20 this session, you automatically consent to such recordings. If you do n= ot=20 consent to the recording, discuss your concerns with the meeting host p= rior=20 to the start of the recording or do not join the session. Please note t= hat=20 any such recordings may be subject to discovery in the event of=20 litigation. 

__________________________________________________________________________=
_______________________________________________
 
Ce mess=
age et ses pieces jointes peuvent contenir des informations confidentielles=
 ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous ave=
z recu ce message par erreur, veuillez le signaler
<= PRE>a l'expediteur et le detruire ainsi que les pieces join= tes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute res=
ponsabilite si ce message a ete altere, deforme ou falsifie. Merci.<=
o:p>
 
This message and its attachments may contain confidential or p=
rivileged information that may be protected by law;
= 
they should not be distributed, used or copied without=
 authorisation.
If you have rec=
eived this email in error, please notify the sender and delete this message=
 and its attachments.
As emails=
 may be altered, France Telecom - Orange is not liable for messages that ha=
ve been modified, changed or falsified.
Thank you.

 

_______________________________________________
C= DNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni=

 

--_000_8F0D2F5E4AAB7249BC7339A3E944DEDD2226F0F817PMEXCB1Dintra_-- From flefauch@cisco.com Thu Jun 27 02:06:36 2013 Return-Path: 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 E119221F9113 for ; Thu, 27 Jun 2013 02:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 LFukxLD5ViJY for ; Thu, 27 Jun 2013 02:06:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D704621F90EF for ; Thu, 27 Jun 2013 02:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10580; q=dns/txt; s=iport; t=1372323992; x=1373533592; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/Mw1BbUYpabgMDmKZzvfAuw8HBpWOIfhE5bqEln+0jQ=; b=PERyjo7f9da45w36WZTcA/YFriKasYawdJBbY8g0hSxC5T7kU+At9GEm wj71DTPfbWQBGaGpMOFS+tD7HUs1ZbnFZaqb4E06RRPKFtaj1pNY70BYX HthbBOB3ppPf+I9uWSgAfEBcL7K3jboOJwslEHcPor6sf4Je8+4bEhezl E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAGH/y1GtJXG+/2dsb2JhbABBFwODCTFDBr8DfRZ0giMBAQECAQEBAQFjAgMDCwULAgEIEQMBAQEBCgoEDAMHJwsUCQcBAgEDAQ0FCAGHfwYHBTOsWI0kjhMQC3QCIQsFBwYLB4JqYQOYbpAcgkFQgXE3 X-IronPort-AV: E=Sophos;i="4.87,950,1363132800"; d="scan'208";a="228059100" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jun 2013 09:06:30 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5R96UgR023507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 09:06:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 04:06:29 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben , "Brandenburg, R. (Ray) van" , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgA= Date: Thu, 27 Jun 2013 09:06:28 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 09:06:37 -0000 I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins wrote: > Francois, >=20 > I haven't considered the proposal in detail but proposing an x- prefix re= minded me of this draft >=20 > http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful >=20 > At one point it was being discussed in appsarea WG but I can't remember w= hether it ended up going anywhere. >=20 > Ben >=20 > On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: >=20 >> Hi Ray, >>=20 >> We discussed the IANA allocation policy at the informal meeting. There w= as convergence on adding both a "private use" and a "specification required= " namespaces. As an example, below is what I drafted for the first IANA reg= istry. Let us know if you have comments. >>=20 >> Cheers >>=20 >> Francois >>=20 >> 6.1. CDNI Logging Directive Names Registry >>=20 >> The IANA is requested to create a new registry, CDNI Logging >> Directive Names. >>=20 >> The initial contents of the CDNI Logging File Directives registry >> comprise the names of the directives specified in Section 3.3 of the >> present document, and are as follows: >>=20 >> +------------------------------+-----------+ >> + Directive name + Reference | >> +------------------------------+-----------+ >> + Version + RFC xxxx | >> + UUID + RFC xxxx | >> + Claimed-Origin + RFC xxxx | >> + Verified-Origin + RFC xxxx | >> + Record-Type + RFC xxxx | >> + Fields + RFC xxxx | >> + Integrity-Hash + RFC xxxx | >> +------------------------------+-----------+ >>=20 >> Figure 4 >>=20 >> [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of >> the present document] >>=20 >> Within the registry: >>=20 >> o the subset of the namespace starting with "x" "-" is set aside for >> "Private Use" as specified in [RFC5226]. To minimize conflicts in >> the names used, the name MUST be structured as : "x" "-" "vendor- >> ID" "-" "vendor-specific-cdni-logging-directive-name" where the >> "vendor-ID" identifies the vendor and the "vendor-specific- cdni- >> logging-directive-name" identifies the actual vendor-specific >> directive. For example, a vendor specific directive name could >> look like "x-vendor1-interesting_directive1". >>=20 >> o the subset of the namespace starting with "r" "-" is to be >> allocated by IANA according to the "Specification Required" policy >> specified in [RFC5226]. >>=20 >> o the rest of the namespace is to be allocated by IANA according to >> the "Standards Action" policy specified in [RFC5226]. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" >> wrote: >>=20 >>> Hello Ray, >>>=20 >>> On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" >>> wrote: >>>=20 >>>> Hi Francois, all, >>>>=20 >>>> I=92ve just read through the latest iteration: my compliments, the doc= ument has improved significantly. >>>=20 >>> Appreciated. >>>=20 >>>>=20 >>>> (Unfortunately, I have not been able to join the CDNI Logging calls, a= nd will not be able to do so today as well. So the following point may have= been discussed during the calls.)=20 >>>> I noticed that the IANA registries specify =91Standards Action=92 as t= he method for extending the registries. I was wondering what the reasoning = behind this was? >>>=20 >>> It is just that at teh time of writing, it was clear that some allocati= on had to go through standards track (eg the WG defines a new type of CDNI = Logging record for Request Routing which requires a new Record-Type and say= a couple new CDNI Logging fields) and it needed a bit more thinking about = how much flexibility we need for the rest (hence teh Editor's note). >>>=20 >>>> To me it seems unnecessarily strict, as well as being somewhat contrad= ictory with the Editor=92s note included in the same section. We would bas= ically rule out any informational or experimental RFC, as well as proprieta= ry logging fields or standardization efforts by other bodies. I would expec= t some CDN vendors to want to do logging of additional fields. I would ther= efore propose we go for =91Specification Required=92 or =91Expert Review=92= . >>>=20 >>> I agree flexibility needs to be added.=20 >>> I am happy to allow something which requires an open spec (possibly som= ehow vetted by the IETF) (e.g. Specification Required or Expert Review). >>> I think we should also have a very light-weight process (ie without IET= F involvement) to allow vendors to experiment with extensions (eg Private/e= xperimental use). >>> I'll try collect more input at today's informal meeting. >>>=20 >>> Thanks >>>=20 >>> Francois >>>=20 >>>=20 >>>>=20 >>>> Best regards, >>>>=20 >>>> Ray >>>>=20 >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f Francois Le Faucheur (flefauch) >>>> Sent: dinsdag 25 juni 2013 16:33 >>>> To: cdni@ietf.org >>>> Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings >>>>=20 >>>> Hello, >>>>=20 >>>> Just a friendly reminder about tommorow's informal CDNI Logging meetin= g.=20 >>>> * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Ti= me, for 90 minute >>>> Webex details included below. >>>>=20 >>>> We just posted a new rev of cdni-logging that reflects some of last in= formal meeting's discussions. The key changes over -03 are: >>>> * rewrite of all formats/rules aspects >>>> * added creation of three IANA registries to prepare for extensibility= of CDNI Logging >>>>=20 >>>> A new version (-04) has been submitted for draft-ietf-cdni-logging: >>>> http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt >>>>=20 >>>> Diff from previous version: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 >>>>=20 >>>> Talk to you tomorrow >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Topic: IETF CDNI Logging - Informal Meeting=20 >>>> Date: Wednesday, June 26, 2013=20 >>>> Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)=20 >>>> Meeting Number: 208 330 914=20 >>>> Password: cdni=20 >>>>=20 >>>> -------------------------------------------------------=20 >>>> To join the meeting online(Now from mobile devices!)=20 >>>> -------------------------------------------------------=20 >>>> 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID= =3D484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D=20 >>>> 2. If requested, enter your name and email address.=20 >>>> 3. If a password is required, enter the meeting password: cdni=20 >>>> 4. Click "Join".=20 >>>> 5. If the meeting includes a teleconference, follow the instructions t= hat appear on your screen.=20 >>>>=20 >>>> -------------------------------------------------------=20 >>>> To join the audio conference only=20 >>>> -------------------------------------------------------=20 >>>> To receive a call back, provide your phone number when you join the me= eting, or call the number below and enter the access code.=20 >>>> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >>>> Call-in toll number (US/Canada): +1-408-525-6800=20 >>>> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_rest= rictions.pdf=20 >>>>=20 >>>> Access code:208 330 914=20 >>>>=20 >>>> CCP:+14085256800x208330914#=20 >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows au= dio and any documents and other materials exchanged or viewed during the se= ssion to be recorded. By joining this session, you automatically consent to= such recordings. If you do not consent to the recording, discuss your conc= erns with the meeting host prior to the start of the recording or do not jo= in the session. Please note that any such recordings may be subject to disc= overy in the event of litigation.=20 >>>> ______________________________________________________________________= ___________________________________________________ >>>>=20 >>>> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez= recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messag= es electroniques etant susceptibles d'alteration, >>>> France Telecom - Orange decline toute responsabilite si ce message a e= te altere, deforme ou falsifie. Merci. >>>>=20 >>>> This message and its attachments may contain confidential or privilege= d information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and= delete this message and its attachments. >>>> As emails may be altered, France Telecom - Orange is not liable for me= ssages that have been modified, changed or falsified. >>>> Thank you. >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>> This e-mail and its contents are subject to the DISCLAIMER at http://w= ww.tno.nl/emaildisclaimer >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Thu Jun 27 05:56:35 2013 Return-Path: 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 89C7521F9957 for ; Thu, 27 Jun 2013 05:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 X-4+C7EKuSVB for ; Thu, 27 Jun 2013 05:56:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 96A0021F9935 for ; Thu, 27 Jun 2013 05:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29245; q=dns/txt; s=iport; t=1372337789; x=1373547389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=D5080mxSmI76ThXOnqmHWFmzoSJg7gFukqv9DL6pWK8=; b=WzJwaRwLiqypBESsjC74ZlaBkkP6kR55fp42qKzzgzB+AjhhTPQSHOGt QolS0m92TfuTyhWzJxoFxNXNE9aOG7oHKENXZB6swuXhmF5OxufP1NJGy 0K+o8QFETkiRokH06csPtX+FR6EVqW9bgqskrPi9k0kpC1BF43P7tfNm2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAME1zFGtJV2c/2dsb2JhbABBFwOCRUQxQwa2TIg8fBZ0giMBAQEBAQIBAQEXTAIDAwsQAgEIEQMBAQELCgQIBAMHJwsUCQcBAgEDAQ0FCAGIBQcFM6x0jR+OExALbwcPEQELBQcGCweCamMDmG6QHIJBUIFxNw X-IronPort-AV: E=Sophos;i="4.87,952,1363132800"; d="scan'208,217";a="228107748" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jun 2013 12:56:28 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5RCuSok004752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 12:56:28 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 07:56:28 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben , "Brandenburg, R. (Ray) van" , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AA== Date: Thu, 27 Jun 2013 12:56:27 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D67F77Dxmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 12:56:35 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D67F77Dxmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D67F77Dxmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Folks,

Peter confirmed this document went through and is now RFC 6648.

I believe the rationale explained in RFC 6648 applies to our situation= and we should follow its recommendations (quoted at the end of ths message= ).

Therefore I propose (in all the registries) to:
* remo= ve the seggregated "x-" namespace 
* remo= ve the seggregated "r-" namespace 
* r= equire IANA registration of all standards-track parameters according to the= "Standards Action" policy
* requ= ire IANA registration of all non-private and non standards-track parameters= according to the "Specification Required" policy

This will leave the following options for people to experiment with un= -standardised parameters:
* use = an unallocated name for private use without having to document anything. Pr= ovided the name is created reasonably smartly this can be done with very lo= w chances of collision, but does not strictly protect against collision, which is OK because this is for privat= e use.
* docu= ment the usage sufficiently well and obtain a unique name. This strict= ly protect against collision, and allows interoperability with other implem= entation of that same spec. If the parameter specification becomes a standard, the parameter name can remain the same.<= /div>
* docu= ment a usage and parameters and progress it through the whole standards tra= ck process.

Let me know if you have comments against that plan.

Cheers

Francois

PS: Ben, thanks for bringing up xdash-considered-harmful.


"
4.  Recommendations for Protocol Designers

   Designers of new application protocols that allow extensions using
   parameters:

   1.  SHOULD establish registries with potentially unlimited value-
       spaces, defining both permanent and provisional registries if
       appropriate.

   2.  SHOULD define simple, clear registration procedures.

   3.  SHOULD mandate registration of all non-private parameters,
       independent of the form of the parameter names.

   4.  SHOULD NOT prohibit parameters with an "X-" prefix or simi=
lar
       constructs from being registered.

   5.  MUST NOT stipulate that a parameter with an "X-" prefix or
       similar constructs needs to be understood as unstandardized.

   6.  MUST NOT stipulate that a parameter without an "X-" prefix=
 or
       similar constructs needs to be understood as standardized.

"

On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

I've reached out to Peter and try get more backgr= ound around -xdash-considered-harmful. If I got the main idea of the docume= nt right, one possible alternative approach could be to get rid of the segg= regated namespaces for "Private Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and t= hen provides a stable name if the "experiment" becomes a "st= andard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
wrote:

Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful<= /a>

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:

Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" <f= lefauch@cisco.com>
wrote:

Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <ray.van= brandenburg@tno.nl>
wrote:

Hi Francois, all,

I=92ve just read through the latest iteration: my compliments, the document= has improved significantly.

Appreciated.


(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.)
I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was?

It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).

To me it seems unnecessarily strict, as well as b= eing somewhat contradictory with the Editor=92s note included in the same s= ection.  We would basically rule out any informational or experimental= RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendor= s to want to do logging of additional fields. I would therefore propose we = go for =91Specification Required=92 or =91Expert Review=92.

I agree flexibility needs to be added.
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois



Best regards,

Ray

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting
Date: Wednesday, June 26, 2013
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 208 330 914
Password: cdni

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D= 484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: cdni
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf

Access code:208 330 914

CCP:+14085256800x208330914#

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer



_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni



--_000_FC236DA6F2DA77449EF2D02DF4471A8D67F77Dxmbrcdx10ciscocom_-- From ray.vanbrandenburg@tno.nl Thu Jun 27 06:51:33 2013 Return-Path: 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 E4FD421F9993 for ; Thu, 27 Jun 2013 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 qKzRxzLwVnnp for ; Thu, 27 Jun 2013 06:51:25 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 96BC621F9E63 for ; Thu, 27 Jun 2013 06:51:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,952,1363129200"; d="scan'208,217";a="10520194" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 27 Jun 2013 15:50:52 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.03.0123.003; Thu, 27 Jun 2013 15:50:52 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" , Niven-Jenkins Ben , "iuniana.oprescu@orange.com" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQiYElU0rGXcEi92CQXnyNSh5lJG86AgAAIuQCAAEBCgIAAL2cg Date: Thu, 27 Jun 2013 13:50:52 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B899EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:51:33 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B899EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I'm not sure I understand how your propo= sal below would work in practice. How would we distinguish between the two = if we don't use namespace prefix? And if it is all part of the same namespa= ce, then what's the point of making the distinction and why not just requir= e 'Specification Required' for everything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I've just read through the latest iteration: my compliments, the document h= as improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify 'Standards Action' as the method= for extending the registries. I was wondering what the reasoning behind th= is was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor's note included in the same section. We would basically = rule out any informational or experimental RFC, as well as proprietary logg= ing fields or standardization efforts by other bodies. I would expect some = CDN vendors to want to do logging of additional fields. I would therefore p= ropose we go for 'Specification Required' or 'Expert Review'. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B899EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 <= /p>

In general= I agree with the proposal of having only two tracks: standards-track and e= verything else. However, I’m not sure I understand how your proposal below would work in practice. How would we distinguish between th= e two if we don’t use namespace prefix? And if it is all part of the = same namespace, then what’s the point of making the distinction and w= hy not just require ‘Specification Required’ for everything?

 = ;

Ray

 = ;

 = ;

From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisc= o.com]
Sent: donderdag 27 juni 2013 14:56
To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@or= ange.com
Cc: cdni@ietf.org
Subject: Re: [CDNi] CDNI Logging - IANA section

 

Folks,

 

Peter confirmed this document went through and is no= w RFC 6648.

 

I believe the rationale explained in RFC 6648 applie= s to our situation and we should follow its recommendations (quoted at the = end of ths message).

 

Therefore I propose (in all the registries) to:=

* remove the seggregated "x-" namespace&nb= sp;

* remove the seggregated "r-" namespace&nb= sp;

* require IANA registration of all standards-track p= arameters according to the "Standards Action" policy

* require IANA registration of all non-private and n= on standards-track parameters according to the "Specification Required= " policy

 

This will leave the following options for people to = experiment with un-standardised parameters:

* use an unallocated name for private use without ha= ving to document anything. Provided the name is created reasonably smartly = this can be done with very low chances of collision, but does not strictly = protect against collision, which is OK because this is for private use.

* document the usage sufficiently well and obtain a = unique name. This strictly protect against collision, and allows inter= operability with other implementation of that same spec. If the parameter s= pecification becomes a standard, the parameter name can remain the same.

* document a usage and parameters and progress it th= rough the whole standards track process.

 

Let me know if you have comments against that plan.<= o:p>

 

Cheers

 

Francois

 

PS: Ben, thanks for bringing up xdash-considere= d-harmful.

 

 

"

4.  Recommendations =
for Protocol Designers
 
   Designers of new application=
 protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish re=
gistries with potentially unlimited value-
       spac=
es, defining both permanent and provisional registries if
       appr=
opriate.
 
   2.  SHOULD define simpl=
e, clear registration procedures.
 
   3.  SHOULD mandate regi=
stration of all non-private parameters,
       inde=
pendent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit=
 parameters with an "X-" prefix or similar
       cons=
tructs from being registered.
 
   5.  MUST NOT stipulate =
that a parameter with an "X-" prefix or
       simi=
lar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate =
that a parameter without an "X-" prefix or
       simi=
lar constructs needs to be understood as standardized.

 

"

 



I've reached out to Peter and try get more backgroun= d around -xdash-considered-harmful. If I got the main idea of the document = right, one possible alternative approach could be to get rid of the seggreg= ated namespaces for "Private Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and t= hen provides a stable name if the "experiment" becomes a "st= andard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
wrote:


Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful<= /a>

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:


Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>
wrote:


Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.vanbr= andenburg@tno.nl>
wrote:


Hi Francois, all,

I’ve just read through the latest iteration: my compliments, the docu= ment has improved significantly.


Appreciated.



(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.)
I noticed that the IANA registries specify ‘Standards Action’ a= s the method for extending the registries. I was wondering what the reasoni= ng behind this was?


It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).


To me it seems unnecessarily strict, as well as bein= g somewhat contradictory with the Editor’s note included in the same = section.  We would basically rule out any informational or experimenta= l RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendor= s to want to do logging of additional fields. I would therefore propose we = go for ‘Specification Required’ or ‘Expert Review’.=


I agree flexibility needs to be added.
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois




Best regards,

Ray

From: = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.o= rg] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.= org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-i= etf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cd= ni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting
Date: Wednesday, June 26, 2013
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00)
Meeting Number: 208 330 914
Password: cdni

-------------------------------------------------------
To join the meeting online(Now from mobile devices!)
-------------------------------------------------------
1. Go to <= span lang=3D"EN-US">https://cisco.webex.com/ciscosales/j.php?ED=3D225213802= &UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: cdni
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9= 903
Call-in toll number (US/Canada): +1-408-525-6800
Toll-free dialing restrictions: http://www.webex.com/pdf/to= llfree_restrictions.pdf

Access code:208 330 914

CCP:+14085256800x208330914#

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such recording= s. If you do not consent to the recording, discuss your concerns with the m= eeting host prior to the start of the recording or do not join the session.= Please note that any such recordings may be subject to discovery in the event of litigation.
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org<= /span>
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno= .nl/emaildisclaimer

 


_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

 

 

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B899EXCMBX03tsntnon_-- From flefauch@cisco.com Thu Jun 27 06:55:51 2013 Return-Path: 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 3B71721F9E85 for ; Thu, 27 Jun 2013 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 yNgQwSxuVxqA for ; Thu, 27 Jun 2013 06:55:46 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1321F9E7C for ; Thu, 27 Jun 2013 06:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49541; q=dns/txt; s=iport; t=1372341346; x=1373550946; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=r950bGNW9CcW8+xQ6CAWbKn5Mi8jIc6jTHvgoAASYV4=; b=Msm2XqfuJPbop1sXaD/tZLx4p8y2d7nyP5pLKBYpn2n0+PD+FADzBvoF L+p6armixUlTSBlgjotWD1Lj27E2K+BjrGYVwhsmXChCfRPXyuGJTAo3R 1v0INuW++NLZXG82EuGEl2TPxrbOvsSV16JcJWjwQpL/YB8SZ5l8hYKef M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAEpDzFGtJXG//2dsb2JhbABBFwOCRUQxQwa2TYg8fhZ0giMBAQEBAQIBAQEXTAIDAwsQAgEIEQMBAQELCgQIAQMDBycLFAkHAQIBAw4FCAGIBQcFM6x/jR+OExALbwcPEQELAQQGAQYDCAeCamMDmG6KeYUjgkFQgXE3 X-IronPort-AV: E=Sophos;i="4.87,952,1363132800"; d="scan'208,217";a="227940360" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2013 13:55:45 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5RDtieH009583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 13:55:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 08:55:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTIA= Date: Thu, 27 Jun 2013 13:55:43 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D67FC02xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 13:55:51 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D67FC02xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I=92m not sure I understand how your pro= posal below would work in practice. How would we distinguish between the tw= o if we don=92t use namespace prefix? You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentation" = to "standards" without having to change the parameter name. Please have alo= ok at RFC 6648. Let me restate: We basically say: * here is a registry * some names will be allocated through "Standards Action" * some names can be allocated through "Specification Required" That's it. Francois And if it is all part of the same namespace, then what=92s the point of mak= ing the distinction and why not just require =91Specification Required=92 f= or everything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D67FC02xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <920ED198E7133D4DB490297F4F072063@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 wrote:

Hi Francois,
 
In general I agree with the proposal of ha= ving only two tracks: standards-track and everything else. However, I=92m n= ot sure I understand how your proposal below would work in practice. How would we distinguish between the two if = we don=92t use namespace prefix?

You don't distinguish between the two. A parameter name is a parameter= name. That is exactly the point. This allows transition from "experim= entation" to "standards" without having to change the parame= ter name. Please have alook at RFC 6648.

Let me restate:
We basically say:
* here= is a registry
* some= names will be allocated through "Standards Action"
* some= names can be allocated through "Specification Required"
That's it.

Francois

And if it is all part of the same namespac= e, then what=92s the point of making the distinction and why not just requi= re =91Specification Required=92 for everything?
 
Ray
 
 
From:&nbs= p;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 14:56
To: Niven-Jenkins = Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.com
Cc: cdni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
Folks,
 
Peter confirmed this document went through and is now RFC 6648.
 
I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message).
 
Therefore I propose (in all the registries) to:
* remove the seggregated "x-" namespace 
* remove the seggregated "r-" namespace 
* require IANA registration of all standards-track parameters according to = the "Standards Action" policy
* require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy
 
This will leave the following options for people to experiment with un-stan= dardised parameters:
* use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use.
* document the usage sufficiently well and obtain a unique name. This = strictly protect against collision, and allows interoperability with other = implementation of that same spec. If the parameter specification becomes a = standard, the parameter name can remain the same.
* document a usage and parameters and progress it through the whole standar= ds track process.
 
Let me know if you have comments against that plan.
 
Cheers
 
Francois
 
PS: Ben, thanks for bringing up xdash-considered-harmful.
 
 
"
4.  Recommendations for Protocol Designer=
s
 
   Designers of new application =
protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish reg=
istries with potentially unlimited value-
       space=
s, defining both permanent and provisional registries if
       appro=
priate.
 
   2.  SHOULD define simple=
, clear registration procedures.
 
   3.  SHOULD mandate regis=
tration of all non-private parameters,
       indep=
endent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit =
parameters with an "X-" prefix or similar
       const=
ructs from being registered.
 
   5.  MUST NOT stipulate t=
hat a parameter with an "X-" prefix or
       simil=
ar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate t=
hat a parameter without an "X-" prefix or
       simil=
ar constructs needs to be understood as standardized.
 
"
 
On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:


I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for &qu= ot;Private Use" and "Specification Required" and instead require IANA allocaton with an "Expert Review" polic= y (so it is kept light-weight, and then provides a stable name if the "= ;experiment" becomes a "standard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@n= iven-jenkins.co.uk>
wrote:


Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ie= tf.org/html/draft-saintandre-xdash-considered-harmful

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:


Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.c= om>
wrote:


Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.vanbrandenburg@tno.nl>
wrote:


Hi Francois, all,

I=92ve just read through the latest iteration: my compliments, the document= has improved significantly.

Appreciated.



(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) 
I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was?

It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).


To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section.  We would bas= ically rule out any informational or experimental RFC, as well as proprieta= ry logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of = additional fields. I would therefore propose we go for =91Specification Req= uired=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois




Best regards,

Ray

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. = The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.t= xt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04<= /a>

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 <= /span>
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/= ciscosales/j.php?ED=3D225213802&UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&= amp;RT=3DMiMyMw%3D%3D 
2. If requested, e= nter your name and email address.&nbs= p;
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 
------------------------------------------------------- 
To join the audio conference only&nbs= p;
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9= 903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: = http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:208 330 914 <= br>
CCP:+14085256800x208330914# =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. B= y joining this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation. 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.i= etf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i
 
 


--_000_FC236DA6F2DA77449EF2D02DF4471A8D67FC02xmbrcdx10ciscocom_-- From ray.vanbrandenburg@tno.nl Thu Jun 27 07:17:00 2013 Return-Path: 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 E016D21F9DBD for ; Thu, 27 Jun 2013 07:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 Bm5lPYeS8c78 for ; Thu, 27 Jun 2013 07:16:53 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7C94621F9DAB for ; Thu, 27 Jun 2013 07:16:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,952,1363129200"; d="scan'208,217";a="1754389" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 27 Jun 2013 16:16:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Thu, 27 Jun 2013 16:16:45 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQiYElU0rGXcEi92CQXnyNSh5lJG86AgAAIuQCAAEBCgIAAL2cg///hKICAACYIQA== Date: Thu, 27 Jun 2013 14:16:43 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B998EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 14:17:01 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B998EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Let me rephrase myself: what I don't understand is how a single registry ca= n have two enforcing policies. If you have a registry with two policies, on= e of which is stricter than the other, than isn't the de facto policy the l= ess-strict one (in this case specification required)? The way I understand = it, a registry with 'Specification Required' doesn't rule out any fields be= ing registered through a standards-track RFC, does it? So what's the point = of also slapping a 'Standards Action'-policy on it? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 15:56 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@ora= nge.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I'm not sure I understand how your propo= sal below would work in practice. How would we distinguish between the two = if we don't use namespace prefix? You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentation" = to "standards" without having to change the parameter name. Please have alo= ok at RFC 6648. Let me restate: We basically say: * here is a registry * some names will be allocated through "Standards Action" * some names can be allocated through "Specification Required" That's it. Francois And if it is all part of the same namespace, then what's the point of makin= g the distinction and why not just require 'Specification Required' for eve= rything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I've just read through the latest iteration: my compliments, the document h= as improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify 'Standards Action' as the method= for extending the registries. I was wondering what the reasoning behind th= is was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor's note included in the same section. We would basically = rule out any informational or experimental RFC, as well as proprietary logg= ing fields or standardization efforts by other bodies. I would expect some = CDN vendors to want to do logging of additional fields. I would therefore p= ropose we go for 'Specification Required' or 'Expert Review'. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B998EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Francois,

 <= /p>

Let me rep= hrase myself: what I don’t understand is how a single registry can ha= ve two enforcing policies. If you have a registry with two policies, one of which is stricter than the other, than isn’t the de facto pol= icy the less-strict one (in this case specification required)? The way I un= derstand it, a registry with ‘Specification Required’ doesnR= 17;t rule out any fields being registered through a standards-track RFC, does it? So what’s the point of also slapping a ‘Standard= s Action’-policy on it?

 = ;

Ray

 = ;

From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisc= o.com]
Sent: donderdag 27 juni 2013 15:56
To: Brandenburg, R. (Ray) van
Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.opre= scu@orange.com; cdni@ietf.org
Subject: Re: [CDNi] CDNI Logging - IANA section

 

 

On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray= ) van" <ray.vanbranden= burg@tno.nl>

 wrote:



Hi Francois,<= /o:p>

 <= /p>

In general= I agree with the proposal of having only two tracks: standards-track and e= verything else. However, I’m not sure I understand how your proposal below would work in practice. How would we distinguish between th= e two if we don’t use namespace prefix?

 

You don't distinguish between the two. A parameter n= ame is a parameter name. That is exactly the point. This allows transition = from "experimentation" to "standards" without having to= change the parameter name. Please have alook at RFC 6648.

 

Let me restate:

We basically say:

* here is a registry

* some names will be allocated through "Standar= ds Action"

* some names can be allocated through "Specific= ation Required"

That's it.

 

Francois



And if it = is all part of the same namespace, then what’s the point of making th= e distinction and why not just require ‘Specification Required’ for everything?

 

Ray=

 

 

From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco= .com] 
Sent: donderdag 27= juni 2013 14:56
To: Niven-Jenkins = Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.com
Cc: cdni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section

 

Folks,

 

Peter confirmed this document went through and is no= w RFC 6648.

 

I believe the rationale explained in RFC 6648 applie= s to our situation and we should follow its recommendations (quoted at the = end of ths message).

 

Therefore I propose (in all the registries) to:=

* remove the seggregated "x-" namespace&nb= sp;

* remove the seggregated "r-" namespace&nb= sp;

* require IANA registration of all standards-track p= arameters according to the "Standards Action" policy

* require IANA registration of all non-private and n= on standards-track parameters according to the "Specification Required= " policy

 

This will leave the following options for people to = experiment with un-standardised parameters:

* use an unallocated name for private use without ha= ving to document anything. Provided the name is created reasonably smartly = this can be done with very low chances of collision, but does not strictly = protect against collision, which is OK because this is for private use.

* document the usage sufficiently well and obtain a = unique name. This strictly protect against collision, and allows inter= operability with other implementation of that same spec. If the parameter s= pecification becomes a standard, the parameter name can remain the same.

* document a usage and parameters and progress it th= rough the whole standards track process.

 

Let me know if you have comments against that plan.<= o:p>

 

Cheers

 

Francois

 

PS: Ben, thanks for bringing up xdash-considere= d-harmful.

 

 

"

4.  Recommendations =
for Protocol Designers
 
   Designers of new application=
 protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish re=
gistries with potentially unlimited value-
       spac=
es, defining both permanent and provisional registries if
       appr=
opriate.
 
   2.  SHOULD define simpl=
e, clear registration procedures.
 
   3.  SHOULD mandate regi=
stration of all non-private parameters,
       inde=
pendent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit=
 parameters with an "X-" prefix or similar
       cons=
tructs from being registered.
 
   5.  MUST NOT stipulate =
that a parameter with an "X-" prefix or
       simi=
lar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate =
that a parameter without an "X-" prefix or
       simi=
lar constructs needs to be understood as standardized.

 

"

 

On 27 Jun 2013, at 11:06, Francois Le Faucheur (flef= auch) <flefauch@cisco.com> wrote:




I've reached out to Peter and try get more backgroun= d around -xdash-considered-harmful. If I got the main idea of the document = right, one possible alternative approach could be to get rid of the seggreg= ated namespaces for "Private Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and t= hen provides a stable name if the "experiment" becomes a "st= andard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk= >
wrote:



Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintan= dre-xdash-considered-harmful

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:



Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com= >
wrote:



Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.vanbrandenburg@tno.nl>=
wrote:



Hi Francois, all,

I’ve just read through the latest iteration: my compliments, the docu= ment has improved significantly.


Appreciated.




(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) 
I noticed that the IANA registries specify ‘Standards Action’ a= s the method for extending the registries. I was wondering what the reasoni= ng behind this was?


It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).



To me it seems unnecessarily strict, as well as bein= g somewhat contradictory with the Editor’s note included in the same = section.  We would basically rule out any informational or experimenta= l RFC, as well as proprietary logging fields or standardization efforts by other bodies. I would expect some CDN vendor= s to want to do logging of additional fields. I would therefore propose we = go for ‘Specification Required’ or ‘Expert Review’.=


I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois





Best regards,

Ray

From: cd= ni-bounces@ietf.org [ma= ilto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.or= g
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. = The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/= internet-drafts/draft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-cdni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 <= /span>
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802= &UID=3D484318167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 
2. If requested, e= nter your name and email address.&nbs= p;
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 
------------------------------------------------------- 
To join the audio conference only&nbs= p;
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9= 903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: = http://www.webex.com/pdf/toll= free_restrictions.pdf 

Access code:208 330 914 <= br>
CCP:+14085256800x208330914# =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. B= y joining this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation. 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.n= l/emaildisclaimer

 


_______________________________________________
CDNi mailing list
CDNi@ietf.org=
https://www.ietf.org/mailman/listinfo/cdni

 

 

 

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F39B998EXCMBX03tsntnon_-- From flefauch@cisco.com Thu Jun 27 09:05:35 2013 Return-Path: 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 93A6821F9E66 for ; Thu, 27 Jun 2013 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 jJsxWn76IHO6 for ; Thu, 27 Jun 2013 09:05:31 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 218A221F9DA6 for ; Thu, 27 Jun 2013 09:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59458; q=dns/txt; s=iport; t=1372349128; x=1373558728; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZES4v3Ky6rHzeHcpFuNsOc+ktB7rSS7GI8+QgY7zzV0=; b=jMtqTdzbr/CH8I6EJD6uyrZBvxIryzE62KiRSRrG54C4hh7UF999XAgK 81gfOOE9LCT3DAXZOUd8ceKjVjhV8Ykf6cv2nqEYUTB/BD/uLw63dvSiU v4h0MolNx8xMlv8v7Y5tn39MTx0jUqsbS1h65VjIlYizzKbS8CoinAjqu c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAKBhzFGtJV2b/2dsb2JhbABBFwOCRUQxQwa2T4g8gQAWdIIjAQEBAQECAQEBF0wCAwMLEAIBCBEDAQEBCwoECAEDAwcnCxQJBwECAQMOBQgBiAUHBTOtRo0ZjhMQC28HDxEBCwEEBgEGAwgHgmpjA5huinmFI4JBUIFxNw X-IronPort-AV: E=Sophos;i="4.87,953,1363132800"; d="scan'208,217";a="228288039" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jun 2013 16:05:24 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5RG5O0P032579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Jun 2013 16:05:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 11:05:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTICAAAXtgIAAHlkA Date: Thu, 27 Jun 2013 16:05:22 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D680374xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 16:05:35 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D680374xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ray, On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, Let me rephrase myself: what I don=92t understand is how a single registry = can have two enforcing policies. If you have a registry with two policies, = one of which is stricter than the other, than isn=92t the de facto policy t= he less-strict one (in this case specification required)? The thing is that "Specification Required" required is not simply a less-st= rict "subset" of "Standards Action". For example, there is a specific process for "Specification Required" which= involves sending a request to IANA which will then designate an Expert res= ponsible for performing the review and reporting to IANA. We don't need suc= h a process if a functionality + parameters are progressed in the standards= track (ie IANA will be called at publicaton time and the WG + IESG is effe= ctively of doing the expert review). So my take is we need to say that some names will be allocated according to= "Standards Action" and some names will be allocated according to "Specific= ation Required". Francois PS: Looping in Peter in case he provide additional guidance. The way I understand it, a registry with =91Specification Required=92 doesn= =92t rule out any fields being registered through a standards-track RFC, do= es it? So what=92s the point of also slapping a =91Standards Action=92-poli= cy on it? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 15:56 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@ora= nge.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I=92m not sure I understand how your pro= posal below would work in practice. How would we distinguish between the tw= o if we don=92t use namespace prefix? You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentation" = to "standards" without having to change the parameter name. Please have alo= ok at RFC 6648. Let me restate: We basically say: * here is a registry * some names will be allocated through "Standards Action" * some names can be allocated through "Specification Required" That's it. Francois And if it is all part of the same namespace, then what=92s the point of mak= ing the distinction and why not just require =91Specification Required=92 f= or everything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D680374xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4AB249A09D09FA42945936EDF09C81B1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ray,

On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ; wrote:

Hi Francois,
 
Let me rephrase myself: what I don=92t und= erstand is how a single registry can have two enforcing policies. If you ha= ve a registry with two policies, one of which is stricter than the other, than isn=92t the de facto policy the les= s-strict one (in this case specification required)?

The thing is that "Specification Required" required is not s= imply a less-strict "subset" of "Standards Action".
For example, there is a specific process for "Specification Requi= red" which involves sending a request to IANA which will then designat= e an Expert responsible for performing the review and reporting to IANA. We= don't need such a process if a functionality + parameters are progressed in the standards track (ie IANA will be ca= lled at publicaton time and the WG + IESG is effectively of doing the e= xpert review). 

So my take is we need to say that some names will be allocated accordi= ng to "Standards Action" and some names will be allocated accordi= ng to "Specification Required".

Francois

PS: Looping in Peter in case he provide additional guidance.

The way I understand it, a registry with = =91Specification Required=92 doesn=92t rule out any fields being registered= through a standards-track RFC, does it? So what=92s the point of also slapping a =91Standards Action=92-policy on it?=
 
Ray
 
From:&nbs= p;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 15:56
To: Brandenburg, R= . (Ray) van
Cc: Francois Le Fa= ucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@orange.com; cdni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
 
On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
 wrote:


Hi Francois,
 
In general I agree with the proposal of ha= ving only two tracks: standards-track and everything else. However, I=92m n= ot sure I understand how your proposal below would work in practice. How would we distinguish between the two if = we don=92t use namespace prefix?
 
You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentat= ion" to "standards" without having to change the parameter n= ame. Please have alook at RFC 6648.
 
Let me restate:
We basically say:
* here is a registry
* some names will be allocated through "Standards Action"
* some names can be allocated through "Specification Required"
That's it.
 
Francois


And if it is all part of the same namespac= e, then what=92s the point of making the distinction and why not just requi= re =91Specification Required=92 for everything?
 
Ray
 
 
From:&nb= sp;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 14:56
To: Niven-Jenkins = Ben; Brandenburg, R. (Ray) van; = iuniana.oprescu@orange.com
Cc: cd= ni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
Folks,
 
Peter confirmed this document went through and is now RFC 6648.
 
I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message).
 
Therefore I propose (in all the registries) to:
* remove the seggregated "x-" namespace 
* remove the seggregated "r-" namespace 
* require IANA registration of all standards-track parameters according to = the "Standards Action" policy
* require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy
 
This will leave the following options for people to experiment with un-stan= dardised parameters:
* use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use.
* document the usage sufficiently well and obtain a unique name. This = strictly protect against collision, and allows interoperability with other = implementation of that same spec. If the parameter specification becomes a = standard, the parameter name can remain the same.
* document a usage and parameters and progress it through the whole standar= ds track process.
 
Let me know if you have comments against that plan.
 
Cheers
 
Francois
 
PS: Ben, thanks for bringing up xdash-considered-harmful.
 
 
"
4.  Recommendations for Protocol Designer=
s
 
   Designers of new application =
protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish reg=
istries with potentially unlimited value-
       space=
s, defining both permanent and provisional registries if
       appro=
priate.
 
   2.  SHOULD define simple=
, clear registration procedures.
 
   3.  SHOULD mandate regis=
tration of all non-private parameters,
       indep=
endent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit =
parameters with an "X-" prefix or similar
       const=
ructs from being registered.
 
   5.  MUST NOT stipulate t=
hat a parameter with an "X-" prefix or
       simil=
ar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate t=
hat a parameter without an "X-" prefix or
       simil=
ar constructs needs to be understood as standardized.
 
"
 
On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote= :



I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for &qu= ot;Private Use" and "Specification Required" and instead require IANA allocaton with an "Expert Review" polic= y (so it is kept light-weight, and then provides a stable name if the "= ;experiment" becomes a "standard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
wrote:



Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-consider= ed-harmful

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:



Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>
wrote:



Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.= vanbrandenburg@tno.nl>
wrote:



Hi Francois, all,

I=92ve just read through the latest iteration: my compliments, the document= has improved significantly.

Appreciated.




(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) 
I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was?

It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).



To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section.  We would bas= ically rule out any informational or experimental RFC, as well as proprieta= ry logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of = additional fields. I would therefore propose we go for =91Specification Req= uired=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois





Best regards,

Ray

From: cdni-bounces@ietf.or= g&nbs= p;[mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. = The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/dr= aft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-cdni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 <= /span>
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to  
2. If requested, e= nter your name and email address.&nbs= p;
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 
------------------------------------------------------- 
To join the audio conference only&nbs= p;
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9= 903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: = http://www.webex.com/pdf/tollfree_restrictions.= pdf&n= bsp;

Access code:208 330 914 <= br>
CCP:+14085256800x208330914# =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. B= y joining this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation. 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf= .org
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer<= /span>

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://w= ww.ietf.org/mailman/listinfo/cdni
 
 


--_000_FC236DA6F2DA77449EF2D02DF4471A8D680374xmbrcdx10ciscocom_-- From ray.vanbrandenburg@tno.nl Thu Jun 27 14:24:57 2013 Return-Path: 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 41B6B21F9BAF for ; Thu, 27 Jun 2013 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.097 X-Spam-Level: X-Spam-Status: No, score=0.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6] 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 vc1dRcyrMGiZ for ; Thu, 27 Jun 2013 14:24:52 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id C69BE11E8120 for ; Thu, 27 Jun 2013 14:24:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,954,1363129200"; d="scan'208,217";a="10537714" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 27 Jun 2013 23:24:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.03.0123.003; Thu, 27 Jun 2013 23:24:45 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQiYElU0rGXcEi92CQXnyNSh5lJG86AgAAIuQCAAEBCgIAAL2cg///hKICAACYIQP///jEAgAB6w1s= Date: Thu, 27 Jun 2013 21:24:45 +0000 Message-ID: <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1933AB615B1A4B709CC2F3F98E7BF56Atnonl_" MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 21:24:57 -0000 --_000_1933AB615B1A4B709CC2F3F98E7BF56Atnonl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" > wrote: Hi Ray, On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, Let me rephrase myself: what I don=92t understand is how a single registry = can have two enforcing policies. If you have a registry with two policies, = one of which is stricter than the other, than isn=92t the de facto policy t= he less-strict one (in this case specification required)? The thing is that "Specification Required" required is not simply a less-st= rict "subset" of "Standards Action". For example, there is a specific process for "Specification Required" which= involves sending a request to IANA which will then designate an Expert res= ponsible for performing the review and reporting to IANA. We don't need suc= h a process if a functionality + parameters are progressed in the standards= track (ie IANA will be called at publicaton time and the WG + IESG is effe= ctively of doing the expert review). RFC5226 includes the following sentence under 'Specification Required': "For RFC publication, the normal RFC review process is expected to provide = the necessary review for interoperability, though the Designated Expert may= be a particularly well-qualified person to perform such a review." Doesn't this solve the issue you raise? Ray So my take is we need to say that some names will be allocated according to= "Standards Action" and some names will be allocated according to "Specific= ation Required". Francois PS: Looping in Peter in case he provide additional guidance. The way I understand it, a registry with =91Specification Required=92 doesn= =92t rule out any fields being registered through a standards-track RFC, do= es it? So what=92s the point of also slapping a =91Standards Action=92-poli= cy on it? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 15:56 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@ora= nge.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I=92m not sure I understand how your pro= posal below would work in practice. How would we distinguish between the tw= o if we don=92t use namespace prefix? You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentation" = to "standards" without having to change the parameter name. Please have alo= ok at RFC 6648. Let me restate: We basically say: * here is a registry * some names will be allocated through "Standards Action" * some names can be allocated through "Specification Required" That's it. Francois And if it is all part of the same namespace, then what=92s the point of mak= ing the distinction and why not just require =91Specification Required=92 f= or everything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_1933AB615B1A4B709CC2F3F98E7BF56Atnonl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On 27 jun. 2013, at 18:05, = "Francois Le Faucheur (flefauch)" <flefauch@cisco.com> wrote:

Hi Ray,

On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ; wrote:

Hi Francois,
 
Let me rephrase myself: what I don=92t und= erstand is how a single registry can have two enforcing policies. If you ha= ve a registry with two policies, one of which is stricter than the other, than isn=92t the de facto policy the les= s-strict one (in this case specification required)?

The thing is that "Specification Required" required is not s= imply a less-strict "subset" of "Standards Action".
For example, there is a specific process for "Specification Requi= red" which involves sending a request to IANA which will then designat= e an Expert responsible for performing the review and reporting to IANA. We= don't need such a process if a functionality + parameters are progressed in the standards track (ie IANA will be ca= lled at publicaton time and the WG + IESG is effectively of doing the e= xpert review). 


RFC5226 includes the follow= ing sentence under 'Specification Required':

"For RFC publication, the normal RFC review process is expected to provide the necessary review = for interoperability, though the Designated Expert may be a particularly we= ll-qualified person to perform such a review."

Doesn't this solve the issu= e you raise?

Ray

So my take is we need to say that some names will be allocated accordi= ng to "Standards Action" and some names will be allocated accordi= ng to "Specification Required".

Francois

PS: Looping in Peter in case he provide additional guidance.

The way I understand it, a registry with = =91Specification Required=92 doesn=92t rule out any fields being registered= through a standards-track RFC, does it? So what=92s the point of also slapping a =91Standards Action=92-policy on it?=
 
Ray
 
From:&nbs= p;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 15:56
To: Brandenburg, R= . (Ray) van
Cc: Francois Le Fa= ucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@orange.com; cdni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
 
On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
 wrote:


Hi Francois,
 
In general I agree with the proposal of ha= ving only two tracks: standards-track and everything else. However, I=92m n= ot sure I understand how your proposal below would work in practice. How would we distinguish between the two if = we don=92t use namespace prefix?
 
You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentat= ion" to "standards" without having to change the parameter n= ame. Please have alook at RFC 6648.
 
Let me restate:
We basically say:
* here is a registry
* some names will be allocated through "Standards Action"
* some names can be allocated through "Specification Required"
That's it.
 
Francois


And if it is all part of the same namespac= e, then what=92s the point of making the distinction and why not just requi= re =91Specification Required=92 for everything?
 
Ray
 
 
From:&nb= sp;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 14:56
To: Niven-Jenkins = Ben; Brandenburg, R. (Ray) van; = iuniana.oprescu@orange.com
Cc: cd= ni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
Folks,
 
Peter confirmed this document went through and is now RFC 6648.
 
I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message).
 
Therefore I propose (in all the registries) to:
* remove the seggregated "x-" namespace 
* remove the seggregated "r-" namespace 
* require IANA registration of all standards-track parameters according to = the "Standards Action" policy
* require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy
 
This will leave the following options for people to experiment with un-stan= dardised parameters:
* use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use.
* document the usage sufficiently well and obtain a unique name. This = strictly protect against collision, and allows interoperability with other = implementation of that same spec. If the parameter specification becomes a = standard, the parameter name can remain the same.
* document a usage and parameters and progress it through the whole standar= ds track process.
 
Let me know if you have comments against that plan.
 
Cheers
 
Francois
 
PS: Ben, thanks for bringing up xdash-considered-harmful.
 
 
"
4.  Recommendations for Protocol Designer=
s
 
   Designers of new application =
protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish reg=
istries with potentially unlimited value-
       space=
s, defining both permanent and provisional registries if
       appro=
priate.
 
   2.  SHOULD define simple=
, clear registration procedures.
 
   3.  SHOULD mandate regis=
tration of all non-private parameters,
       indep=
endent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit =
parameters with an "X-" prefix or similar
       const=
ructs from being registered.
 
   5.  MUST NOT stipulate t=
hat a parameter with an "X-" prefix or
       simil=
ar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate t=
hat a parameter without an "X-" prefix or
       simil=
ar constructs needs to be understood as standardized.
 
"
 
On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote= :



I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for &qu= ot;Private Use" and "Specification Required" and instead require IANA allocaton with an "Expert Review" polic= y (so it is kept light-weight, and then provides a stable name if the "= ;experiment" becomes a "standard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
wrote:



Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-consider= ed-harmful

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:



Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>
wrote:



Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.= vanbrandenburg@tno.nl>
wrote:



Hi Francois, all,

I=92ve just read through the latest iteration: my compliments, the document= has improved significantly.

Appreciated.




(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) 
I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was?

It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).



To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section.  We would bas= ically rule out any informational or experimental RFC, as well as proprieta= ry logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of = additional fields. I would therefore propose we go for =91Specification Req= uired=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois





Best regards,

Ray

From: cdni-bounces@ietf.or= g&nbs= p;[mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. = The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/dr= aft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-cdni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 <= /span>
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to  
2. If requested, e= nter your name and email address.&nbs= p;
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 
------------------------------------------------------- 
To join the audio conference only&nbs= p;
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9= 903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: = http://www.webex.com/pdf/tollfree_restrictions.= pdf&n= bsp;

Access code:208 330 914 <= br>
CCP:+14085256800x208330914# =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. B= y joining this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation. 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf= .org
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer<= /span>

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://w= ww.ietf.org/mailman/listinfo/cdni
 
 


--_000_1933AB615B1A4B709CC2F3F98E7BF56Atnonl_-- From psaintan@cisco.com Thu Jun 27 17:04:09 2013 Return-Path: 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 63DCA11E8153 for ; Thu, 27 Jun 2013 17:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Top+rBjlPwQF for ; Thu, 27 Jun 2013 17:04:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A905911E815F for ; Thu, 27 Jun 2013 17:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4622; q=dns/txt; s=iport; t=1372377843; x=1373587443; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=0yQCj9t/EqStto7pW08JxkSO0NtRYuWPoSEmaNjCjQE=; b=LEYOgCzXdw5bMmQ5HcXj6tWoWXhrckn/wtgfjPHUMLJspxCwdX1xRcVy nP2xuvSCyDdUaOIjOopvbfwQG7nuNIM2FCpCys5KLwCiQ/g7Ji/FwVQT2 jfPr0PX6TT9JDd9b5beujPj4cLt8elN/EumuszmvjrS0VlTdv4rb4AML9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFANzRzFGtJXHB/2dsb2JhbABbgwl6vwyBAhZ0giMBAQEBAgFrDhACAQgRBAEBAQodBzIUCQgCBA4FCIgABrtJjyICMQeDAmMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,955,1363132800"; d="scan'208";a="225413662" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 00:04:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5S042Rc002035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 00:04:02 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.24]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 27 Jun 2013 19:04:01 -0500 From: "Peter Saint-Andre (psaintan)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTICAAAXtgIAAHlkAgABZPoCAACx+AA== Date: Fri, 28 Jun 2013 00:04:00 +0000 Message-ID: <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> In-Reply-To: <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.72.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0F65D1BCB7957A4F80E4DD0D019E1D75@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 28 Jun 2013 00:35:25 -0700 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 00:04:09 -0000 I wasn't subscribed to the list, but I am now, so no need to cc me on repli= es. On Jun 27, 2013, at 3:24 PM, "Brandenburg, R. (Ray) van" wrote: >=20 > On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" wrote: >=20 >> Hi Ray, >>=20 >> On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" wrote: >>=20 >>> Hi Francois, >>> =20 >>> Let me rephrase myself: what I don=92t understand is how a single regis= try can have two enforcing policies. If you have a registry with two polici= es, one of which is stricter than the other, than isn=92t the de facto poli= cy the less-strict one (in this case specification required)? >>=20 >> The thing is that "Specification Required" required is not simply a less= -strict "subset" of "Standards Action". >> For example, there is a specific process for "Specification Required" wh= ich involves sending a request to IANA which will then designate an Expert = responsible for performing the review and reporting to IANA. We don't need = such a process if a functionality + parameters are progressed in the standa= rds track (ie IANA will be called at publicaton time and the WG + IESG is e= ffectively of doing the expert review).=20 >>=20 >=20 > RFC5226 includes the following sentence under 'Specification Required': >=20 > "For RFC publication, the normal RFC review process is expected to provid= e the necessary review for interoperability, though the Designated Expert m= ay be a particularly well-qualified person to perform such a review." The "specification" in "Specification Required" is not necessarily an RFC -= - it could be a document produced by another SDO. However, "RFC Required" is a heavyweight requirement, because every time so= meone wants to add a new entry to the registry we need to spin up the whole= RFC process: I-D, document shepherd, WG or AD-sponsored, IETF Last Call (w= ith attendant reviews), IESG reviews, RFC Editor time, etc. Do we really need that in this case? Further comments below. >=20 > Doesn't this solve the issue you raise? >=20 > Ray >=20 >> So my take is we need to say that some names will be allocated according= to "Standards Action" and some names will be allocated according to "Speci= fication Required". Why do we need two separate processes? Please read RFC 6648. Or read it again. :-) In general there's no need to d= ifferentiate between "standard" parameters and "non-standard" parameters. I= s CDNI exceptional in this regard? >>=20 >> Francois >>=20 >> PS: Looping in Peter in case he provide additional guidance. >>=20 >>> The way I understand it, a registry with =91Specification Required=92 d= oesn=92t rule out any fields being registered through a standards-track RFC= , does it? So what=92s the point of also slapping a =91Standards Action=92-= policy on it? >>> =20 >>> Ray >>> =20 >>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 >>> Sent: donderdag 27 juni 2013 15:56 >>> To: Brandenburg, R. (Ray) van >>> Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu= @orange.com; cdni@ietf.org >>> Subject: Re: [CDNi] CDNI Logging - IANA section >>> =20 >>> =20 >>> On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" >>> wrote: >>>=20 >>>=20 >>> Hi Francois, >>> =20 >>> In general I agree with the proposal of having only two tracks: standar= ds-track and everything else. Here again I question why two tracks are needed. >>> However, I=92m not sure I understand how your proposal below would work= in practice. How would we distinguish between the two if we don=92t use na= mespace prefix? >>> =20 >>> You don't distinguish between the two. A parameter name is a parameter = name. That is exactly the point. This allows transition from "experimentati= on" to "standards" without having to change the parameter name. Please have= alook at RFC 6648. >>> =20 >>> Let me restate: >>> We basically say: >>> * here is a registry >>> * some names will be allocated through "Standards Action" >>> * some names can be allocated through "Specification Required" >>> That's it. >>> =20 >>> Francois >>>=20 >>>=20 >>> And if it is all part of the same namespace, then what=92s the point of= making the distinction and why not just require =91Specification Required= =92 for everything? That sounds reasonable to me. It just happens to be the case that some of t= hose specifications will be RFCs. Peter From ben@niven-jenkins.co.uk Fri Jun 28 00:44:51 2013 Return-Path: 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 0C34921F9943 for ; Fri, 28 Jun 2013 00:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 hOAPlPacZgGZ for ; Fri, 28 Jun 2013 00:44:39 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id DC5C621F9D21 for ; Fri, 28 Jun 2013 00:44:35 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UsTM9-0000qx-Fh; Fri, 28 Jun 2013 08:44:33 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> Date: Fri, 28 Jun 2013 08:44:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A @tno.nl> <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> To: "Peter Saint-Andre (psaintan)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:44:51 -0000 On 28 Jun 2013, at 01:04, Peter Saint-Andre (psaintan) wrote: >> On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" = wrote: >>> So my take is we need to say that some names will be allocated = according to "Standards Action" and some names will be allocated = according to "Specification Required". >=20 > Why do we need two separate processes? >=20 > Please read RFC 6648. Or read it again. :-) In general there's no need = to differentiate between "standard" parameters and "non-standard" = parameters. Is CDNI exceptional in this regard? Not IMO. The objective of registration is to avoid collisions as they = are bad for interop. So the bar for registration must be low enough to = not prevent people from registering. For registered values that get enough momentum (de facto or via some = kind of RFC/standardisation) to be widely deployed an RFC/standard that = describes them is useful to the community. But I don't think anyone needs to 'vet' the namespace registrations in = this instance unless we're really worried about people land = grabbing/squatting which seems unlikely given the size of the registry = space available (basically unlimited). Ben From flefauch@cisco.com Fri Jun 28 01:45:42 2013 Return-Path: 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 81C1421F9C64 for ; Fri, 28 Jun 2013 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 UfLhH1ScqfGG for ; Fri, 28 Jun 2013 01:45:32 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1C45E21F9D00 for ; Fri, 28 Jun 2013 01:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=62361; q=dns/txt; s=iport; t=1372409132; x=1373618732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=34F7TkEcGSEskkMKnLEHXWonEtUBpm+ttEKs+tONi8c=; b=FypDhksZei/WD7ZpmAVlwc8Z7KIXu9Ef5lxp9GFpfjxeNnZpP8Ifxd8N 77rKley+JUiU/tHcdt1evR7PflGs0zIUvEgBYtir2DNKmARvzdfNKnrSA yu6u90yaw7XD1um/DvvxOs4UJ70iJVUrYT9wj9XwFql4nsplib12zq49/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAPxLzVGtJXG8/2dsb2JhbABBFwOCRUQxQwa2Tog8gQUWdIIjAQEBAgIBAQEXTAIDAwsQAgEIEQMBAQELCgQIAQMDBycLFAkHAQIBAw4FCAGIBQcFM64IjSeOExALbwcPEQELAQQGAQYDCAeCamMDmG6QHIJBUIFxNw X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208,217";a="228507198" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jun 2013 08:45:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5S8jU4X003611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 08:45:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 03:45:30 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTICAAAXtgIAAHlkAgABZPoCAAL4vgA== Date: Fri, 28 Jun 2013 08:45:30 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> In-Reply-To: <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D681AE4xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:45:42 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D681AE4xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 27 Jun 2013, at 23:24, "Brandenburg, R. (Ray) van" > wrote: On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" > wrote: Hi Ray, On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, Let me rephrase myself: what I don=92t understand is how a single registry = can have two enforcing policies. If you have a registry with two policies, = one of which is stricter than the other, than isn=92t the de facto policy t= he less-strict one (in this case specification required)? The thing is that "Specification Required" required is not simply a less-st= rict "subset" of "Standards Action". For example, there is a specific process for "Specification Required" which= involves sending a request to IANA which will then designate an Expert res= ponsible for performing the review and reporting to IANA. We don't need suc= h a process if a functionality + parameters are progressed in the standards= track (ie IANA will be called at publicaton time and the WG + IESG is effe= ctively of doing the expert review). RFC5226 includes the following sentence under 'Specification Required': "For RFC publication, the normal RFC review process is expected to provide = the necessary review for interoperability, though the Designated Expert may= be a particularly well-qualified person to perform such a review." Doesn't this solve the issue you raise? It actually does solve the issue. So I agree "Specification Required" shoul= d work for both cases. Thanks Ray So my take is we need to say that some names will be allocated according to= "Standards Action" and some names will be allocated according to "Specific= ation Required". Francois PS: Looping in Peter in case he provide additional guidance. The way I understand it, a registry with =91Specification Required=92 doesn= =92t rule out any fields being registered through a standards-track RFC, do= es it? So what=92s the point of also slapping a =91Standards Action=92-poli= cy on it? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 15:56 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@ora= nge.com; cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, In general I agree with the proposal of having only two tracks: standards-t= rack and everything else. However, I=92m not sure I understand how your pro= posal below would work in practice. How would we distinguish between the tw= o if we don=92t use namespace prefix? You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentation" = to "standards" without having to change the parameter name. Please have alo= ok at RFC 6648. Let me restate: We basically say: * here is a registry * some names will be allocated through "Standards Action" * some names can be allocated through "Specification Required" That's it. Francois And if it is all part of the same namespace, then what=92s the point of mak= ing the distinction and why not just require =91Specification Required=92 f= or everything? Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 27 juni 2013 14:56 To: Niven-Jenkins Ben; Brandenburg, R. (Ray) van; iuniana.oprescu@orange.co= m Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Logging - IANA section Folks, Peter confirmed this document went through and is now RFC 6648. I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message). Therefore I propose (in all the registries) to: * remove the seggregated "x-" namespace * remove the seggregated "r-" namespace * require IANA registration of all standards-track parameters according to = the "Standards Action" policy * require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy This will leave the following options for people to experiment with un-stan= dardised parameters: * use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use. * document the usage sufficiently well and obtain a unique name. This stric= tly protect against collision, and allows interoperability with other imple= mentation of that same spec. If the parameter specification becomes a stand= ard, the parameter name can remain the same. * document a usage and parameters and progress it through the whole standar= ds track process. Let me know if you have comments against that plan. Cheers Francois PS: Ben, thanks for bringing up xdash-considered-harmful. " 4. Recommendations for Protocol Designers Designers of new application protocols that allow extensions using parameters: 1. SHOULD establish registries with potentially unlimited value- spaces, defining both permanent and provisional registries if appropriate. 2. SHOULD define simple, clear registration procedures. 3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names. 4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered. 5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized. 6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized. " On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) > wrote: I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for "Pr= ivate Use" and "Specification Required" and instead require IANA allocaton = with an "Expert Review" policy (so it is kept light-weight, and then provid= es a stable name if the "experiment" becomes a "standard"). Let's make a decision when we have more information. On 27 Jun 2013, at 10:35, Ben Niven-Jenkins > wrote: Francois, I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere. Ben On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote: Hi Ray, We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specification required" n= amespaces. As an example, below is what I drafted for the first IANA regist= ry. Let us know if you have comments. Cheers Francois 6.1. CDNI Logging Directive Names Registry The IANA is requested to create a new registry, CDNI Logging Directive Names. The initial contents of the CDNI Logging File Directives registry comprise the names of the directives specified in Section 3.3 of the present document, and are as follows: +------------------------------+-----------+ + Directive name + Reference | +------------------------------+-----------+ + Version + RFC xxxx | + UUID + RFC xxxx | + Claimed-Origin + RFC xxxx | + Verified-Origin + RFC xxxx | + Record-Type + RFC xxxx | + Fields + RFC xxxx | + Integrity-Hash + RFC xxxx | +------------------------------+-----------+ Figure 4 [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of the present document] Within the registry: o the subset of the namespace starting with "x" "-" is set aside for "Private Use" as specified in [RFC5226]. To minimize conflicts in the names used, the name MUST be structured as : "x" "-" "vendor- ID" "-" "vendor-specific-cdni-logging-directive-name" where the "vendor-ID" identifies the vendor and the "vendor-specific- cdni- logging-directive-name" identifies the actual vendor-specific directive. For example, a vendor specific directive name could look like "x-vendor1-interesting_directive1". o the subset of the namespace starting with "r" "-" is to be allocated by IANA according to the "Specification Required" policy specified in [RFC5226]. o the rest of the namespace is to be allocated by IANA according to the "Standards Action" policy specified in [RFC5226]. On 26 Jun 2013, at 16:58, "Francois Le Faucheur (flefauch)" > wrote: Hello Ray, On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, I=92ve just read through the latest iteration: my compliments, the document= has improved significantly. Appreciated. (Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was? It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how = much flexibility we need for the rest (hence teh Editor's note). To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section. We would basicall= y rule out any informational or experimental RFC, as well as proprietary lo= gging fields or standardization efforts by other bodies. I would expect som= e CDN vendors to want to do logging of additional fields. I would therefore= propose we go for =91Specification Required=92 or =91Expert Review=92. I agree flexibility needs to be added. I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review). I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use). I'll try collect more input at today's informal meeting. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch) Sent: dinsdag 25 juni 2013 16:33 To: cdni@ietf.org Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings Hello, Just a friendly reminder about tommorow's informal CDNI Logging meeting. * Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European Time, f= or 90 minute Webex details included below. We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. The key changes over -03 are: * rewrite of all formats/rules aspects * added creation of three IANA registries to prepare for extensibility of C= DNI Logging A new version (-04) has been submitted for draft-ietf-cdni-logging: http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-04.txt Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-04 Talk to you tomorrow Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: IETF CDNI Logging - Informal Meeting Date: Wednesday, June 26, 2013 Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 208 330 914 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D225213802&UID=3D4843= 18167&PW=3DNNzQ0ZmZmNjUz&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:208 330 914 CCP:+14085256800x208330914# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D681AE4xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <09E9CCF6D4A1F548BDE9EA2ACA014FE0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 27 Jun 2013, at 23:24, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ; wrote:


On 27 jun. 2013, at 18:05, = "Francois Le Faucheur (flefauch)" <flefauch@cisco.com> wrote:

Hi Ray,

On 27 Jun 2013, at 16:16, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ; wrote:

Hi Francois,
 
Let me rephrase myself: what I don=92t und= erstand is how a single registry can have two enforcing policies. If you ha= ve a registry with two policies, one of which is stricter than the other, than isn=92t the de facto policy the les= s-strict one (in this case specification required)?

The thing is that "Specification Required" required is not s= imply a less-strict "subset" of "Standards Action".
For example, there is a specific process for "Specification Requi= red" which involves sending a request to IANA which will then designat= e an Expert responsible for performing the review and reporting to IANA. We= don't need such a process if a functionality + parameters are progressed in the standards track (ie IANA will be ca= lled at publicaton time and the WG + IESG is effectively of doing the e= xpert review). 


RFC5226 includes the follow= ing sentence under 'Specification Required':

"For RFC publication, the normal RFC review process is expected to provide the necessary review = for interoperability, though the Designated Expert may be a particularly we= ll-qualified person to perform such a review."

Doesn't this solve the issu= e you raise?

It actually does solve the issue. So I agree "Specification Requi= red" should work for both cases. 

Thanks



Ray

So my take is we need to say that some names will be allocated accordi= ng to "Standards Action" and some names will be allocated accordi= ng to "Specification Required".

Francois

PS: Looping in Peter in case he provide additional guidance.

The way I understand it, a registry with = =91Specification Required=92 doesn=92t rule out any fields being registered= through a standards-track RFC, does it? So what=92s the point of also slapping a =91Standards Action=92-policy on it?=
 
Ray
 
From:&nbs= p;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 15:56
To: Brandenburg, R= . (Ray) van
Cc: Francois Le Fa= ucheur (flefauch); Niven-Jenkins Ben; iuniana.oprescu@orange.com; cdni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
 
On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>
 wrote:


Hi Francois,
 
In general I agree with the proposal of ha= ving only two tracks: standards-track and everything else. However, I=92m n= ot sure I understand how your proposal below would work in practice. How would we distinguish between the two if = we don=92t use namespace prefix?
 
You don't distinguish between the two. A parameter name is a parameter name= . That is exactly the point. This allows transition from "experimentat= ion" to "standards" without having to change the parameter n= ame. Please have alook at RFC 6648.
 
Let me restate:
We basically say:
* here is a registry
* some names will be allocated through "Standards Action"
* some names can be allocated through "Specification Required"
That's it.
 
Francois


And if it is all part of the same namespac= e, then what=92s the point of making the distinction and why not just requi= re =91Specification Required=92 for everything?
 
Ray
 
 
From:&nb= sp;Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] 
Sent: donderdag 27= juni 2013 14:56
To: Niven-Jenkins = Ben; Brandenburg, R. (Ray) van; = iuniana.oprescu@orange.com
Cc: cd= ni@ietf.org
Subject: Re: [CDNi= ] CDNI Logging - IANA section
 
Folks,
 
Peter confirmed this document went through and is now RFC 6648.
 
I believe the rationale explained in RFC 6648 applies to our situation and = we should follow its recommendations (quoted at the end of ths message).
 
Therefore I propose (in all the registries) to:
* remove the seggregated "x-" namespace 
* remove the seggregated "r-" namespace 
* require IANA registration of all standards-track parameters according to = the "Standards Action" policy
* require IANA registration of all non-private and non standards-track para= meters according to the "Specification Required" policy
 
This will leave the following options for people to experiment with un-stan= dardised parameters:
* use an unallocated name for private use without having to document anythi= ng. Provided the name is created reasonably smartly this can be done with v= ery low chances of collision, but does not strictly protect against collisi= on, which is OK because this is for private use.
* document the usage sufficiently well and obtain a unique name. This = strictly protect against collision, and allows interoperability with other = implementation of that same spec. If the parameter specification becomes a = standard, the parameter name can remain the same.
* document a usage and parameters and progress it through the whole standar= ds track process.
 
Let me know if you have comments against that plan.
 
Cheers
 
Francois
 
PS: Ben, thanks for bringing up xdash-considered-harmful.
 
 
"
4.  Recommendations for Protocol Designer=
s
 
   Designers of new application =
protocols that allow extensions using
   parameters:
 
   1.  SHOULD establish reg=
istries with potentially unlimited value-
       space=
s, defining both permanent and provisional registries if
       appro=
priate.
 
   2.  SHOULD define simple=
, clear registration procedures.
 
   3.  SHOULD mandate regis=
tration of all non-private parameters,
       indep=
endent of the form of the parameter names.
 
   4.  SHOULD NOT prohibit =
parameters with an "X-" prefix or similar
       const=
ructs from being registered.
 
   5.  MUST NOT stipulate t=
hat a parameter with an "X-" prefix or
       simil=
ar constructs needs to be understood as unstandardized.
 
   6.  MUST NOT stipulate t=
hat a parameter without an "X-" prefix or
       simil=
ar constructs needs to be understood as standardized.
 
"
 
On 27 Jun 2013, at 11:06, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote= :



I've reached out to Peter and try get more background around -xdash-conside= red-harmful. If I got the main idea of the document right, one possible alt= ernative approach could be to get rid of the seggregated namespaces for &qu= ot;Private Use" and "Specification Required" and instead require IANA allocaton with an "Expert Review" polic= y (so it is kept light-weight, and then provides a stable name if the "= ;experiment" becomes a "standard").
Let's make a decision when we have more information.



On 27 Jun 2013, at 10:35, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
wrote:



Francois,

I haven't considered the proposal in detail but proposing an x- prefix remi= nded me of this draft

http://tools.ietf.org/html/draft-saintandre-xdash-consider= ed-harmful

At one point it was being discussed in appsarea WG but I can't remember whe= ther it ended up going anywhere.

Ben

On 26 Jun 2013, at 18:39, Francois Le Faucheur (flefauch) wrote:



Hi Ray,

We discussed the IANA allocation policy at the informal meeting. There was = convergence on adding both a "private use" and a "specificat= ion required" namespaces. As an example, below is what I drafted for t= he first IANA registry. Let us know if you have comments.

Cheers

Francois

6.1.  CDNI Logging Directive Names Registry

 The IANA is requested to create a new registry, CDNI Logging
 Directive Names.

 The initial contents of the CDNI Logging File Directives registry
 comprise the names of the directives specified in Section 3.3 of the<= br>  present document, and are as follows:

  +------------------------------+-----------+
  + Directive name        =        + Reference |
  +------------------------------+-----------+
  + Version         &= nbsp;           &nbs= p;+ RFC xxxx  |
  + UUID         &nbs= p;            &= nbsp;  + RFC xxxx  |
  + Claimed-Origin        =        + RFC xxxx  |
  + Verified-Origin        = ;      + RFC xxxx  |
  + Record-Type        &nb= sp;         + RFC xxxx &nb= sp;|
  + Fields         &n= bsp;            = ; + RFC xxxx  |
  + Integrity-Hash        =        + RFC xxxx  |
  +------------------------------+-----------+

            &nb= sp;            =       Figure 4

 [Instructions to IANA: Replace "RFC xxxx" above by the RFC = number of
 the present document]

 Within the registry:

 o  the subset of the namespace starting with "x" "= ;-" is set aside for
    "Private Use" as specified in [RFC5226]. =  To minimize conflicts in
    the names used, the name MUST be structured as : &q= uot;x" "-" "vendor-
    ID" "-" "vendor-specific-cdni-l= ogging-directive-name" where the
    "vendor-ID" identifies the vendor and the= "vendor-specific- cdni-
    logging-directive-name" identifies the actual = vendor-specific
    directive.  For example, a vendor specific dir= ective name could
    look like "x-vendor1-interesting_directive1&qu= ot;.

 o  the subset of the namespace starting with "r" "= ;-" is to be
    allocated by IANA according to the "Specificat= ion Required" policy
    specified in [RFC5226].

 o  the rest of the namespace is to be allocated by IANA accordin= g to
    the "Standards Action" policy specified i= n [RFC5226].






On 26 Jun 2013, at 16:58, "Francois Le Faucheur (fle= fauch)" <flefauch@cisco.com>
wrote:



Hello Ray,

On 26 Jun 2013, at 11:27, "Brandenburg, R. (Ray) van" <= ray.= vanbrandenburg@tno.nl>
wrote:



Hi Francois, all,

I=92ve just read through the latest iteration: my compliments, the document= has improved significantly.

Appreciated.




(Unfortunately, I have not been able to join the CDNI Logging calls, and wi= ll not be able to do so today as well. So the following point may have been= discussed during the calls.) 
I noticed that the IANA registries specify =91Standards Action=92 as the me= thod for extending the registries. I was wondering what the reasoning behin= d this was?

It is just that at teh time of writing, it was clear that some allocation h= ad to go through standards track (eg the WG defines a new type of CDNI Logg= ing record for Request Routing which requires a new Record-Type and say a c= ouple new CDNI Logging fields) and it needed a bit more thinking about how much flexibility we need for the r= est (hence teh Editor's note).



To me it seems unnecessarily strict, as well as being somewhat contradictor= y with the Editor=92s note included in the same section.  We would bas= ically rule out any informational or experimental RFC, as well as proprieta= ry logging fields or standardization efforts by other bodies. I would expect some CDN vendors to want to do logging of = additional fields. I would therefore propose we go for =91Specification Req= uired=92 or =91Expert Review=92.

I agree flexibility needs to be added. 
I am happy to allow something which requires an open spec (possibly somehow= vetted by the IETF) (e.g. Specification Required or Expert Review).
I think we should also have a very light-weight process (ie without IETF in= volvement) to allow vendors to experiment with extensions (eg Private/exper= imental use).
I'll try collect more input at today's informal meeting.

Thanks

Francois





Best regards,

Ray

From: cdni-bounces@ietf.or= g&nbs= p;[mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 25 juni 2013 16:33
To: cdni@ietf.org
Subject: [CDNi] CDNi] CDNI Logging - Series of Informal Meetings

Hello,

Just a friendly reminder about tommorow's informal CDNI Logging meeting. 
* Wed 26 June 2013, at 08:0 Pacific Time =3D 17:00 Central European = Time, for 90 minute
Webex details included below.

We just posted a new rev of cdni-logging that reflects some of last informa= l meeting's discussions. = The key changes over -03 are:
* rewrite of all formats/rules aspects
* added creation of three IANA registries to prepare for extensibility of C= DNI Logging

A new version (-04) has been submitted for draft-ietf-cdni-logging:
http://www.ietf.org/internet-drafts/dr= aft-ietf-cdni-logging-04.txt

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-cdni-logging-04

Talk to you tomorrow

Francois





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Topic: IETF CDNI Logging - Informal Meeting 
Date: Wednesday, June 26, 2013 <= /span>
Time: 5:00 pm, Europe Summer Time (Paris, GMT+02:00) 
Meeting Number: 208 330 914 
Password: cdni 

------------------------------------------------------- 
To join the meeting online(Now from mobile devices!) 
------------------------------------------------------- 
1. Go to  
2. If requested, e= nter your name and email address.&nbs= p;
3. If a password is required, enter the meeting password: cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. 
------------------------------------------------------- 
To join the audio conference only&nbs= p;
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): +1-866-432-9= 903 
Call-in toll number (US/Canada): +1-408-525-6800 
Toll-free dialing restrictions: = http://www.webex.com/pdf/tollfree_restrictions.= pdf&n= bsp;

Access code:208 330 914 <= br>
CCP:+14085256800x208330914# =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. B= y joining this session, you automatically consent to such recordings. If you do not consent to the recording, discus= s your concerns with the meeting host prior to the start of the recording o= r do not join the session. Please note that any such recordings may be subj= ect to discovery in the event of litigation. 
___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified.
Thank you.

_______________________________________________
CDNi mailing list
CDNi@ietf= .org
https://www.ietf.org/mailman/listinfo/cdni

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer<= /span>

 

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://w= ww.ietf.org/mailman/listinfo/cdni
 
 



--_000_FC236DA6F2DA77449EF2D02DF4471A8D681AE4xmbrcdx10ciscocom_-- From flefauch@cisco.com Fri Jun 28 01:58:24 2013 Return-Path: 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 C479B21F8F15 for ; Fri, 28 Jun 2013 01:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pj7xO7VZ7de9 for ; Fri, 28 Jun 2013 01:58:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B4AD421F9EA2 for ; Fri, 28 Jun 2013 01:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3134; q=dns/txt; s=iport; t=1372409872; x=1373619472; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yx4y/MzhAQFS369Z9hgLgCNwJW3eCzAGGN1INK3LWY4=; b=flxIcQCuhLOYLY3GYEpP+3WpFi3NBlCCHeDPMEfXEXZ/dhuEH6YCh660 aU/6D22jauAyj3JspDEZnPnir51LAAEen3y2Ic3OvjwqedZe48DtmBTKE O5dNAqcUIist+yMBR+2gdqlPAe8e2ZEQN9W3Ua/ZPjA+9PcfeqeQRD1Kj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALJPzVGtJXG+/2dsb2JhbABbgmB6vwqBBYEJgiMBAQEDAWsOEAIBCBEEAQEBCh0HMhQJCAIEDgUIiAAGsxOPIgIxB4MCYwOpCoMRgig X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208";a="228595125" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jun 2013 08:57:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5S8vq3L025829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 08:57:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 03:57:51 -0500 From: "Francois Le Faucheur (flefauch)" To: "Peter Saint-Andre (psaintan)" Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTICAAAXtgIAAHlkAgABZPoCAACx+AIAAlScA Date: Fri, 28 Jun 2013 08:57:51 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> In-Reply-To: <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 08:58:24 -0000 On 28 Jun 2013, at 02:04, Peter Saint-Andre (psaintan) = wrote: >>=20 >>=20 >>> So my take is we need to say that some names will be allocated accordin= g to "Standards Action" and some names will be allocated according to "Spec= ification Required". >=20 > Why do we need two separate processes? We don't. My mistake came from a blurry recollections of the "Specification= Required" definition of RFC 5226. I did not think that it also covered the= case of regular RFC publication (ie I thought it would force some addition= al separate process activities such as designating an Expert). Ray clarifie= d that it does cover that case and will not create additional process. So I= think what we want is to use "Specification Required" for the wholesamespa= ce of these new registries. Francois >=20 > Please read RFC 6648. Or read it again. :-) In general there's no need to= differentiate between "standard" parameters and "non-standard" parameters.= Is CDNI exceptional in this regard? >=20 >>>=20 >>> Francois >>>=20 >>> PS: Looping in Peter in case he provide additional guidance. >>>=20 >>>> The way I understand it, a registry with =91Specification Required=92 = doesn=92t rule out any fields being registered through a standards-track RF= C, does it? So what=92s the point of also slapping a =91Standards Action=92= -policy on it? >>>>=20 >>>> Ray >>>>=20 >>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 >>>> Sent: donderdag 27 juni 2013 15:56 >>>> To: Brandenburg, R. (Ray) van >>>> Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; iuniana.opresc= u@orange.com; cdni@ietf.org >>>> Subject: Re: [CDNi] CDNI Logging - IANA section >>>>=20 >>>>=20 >>>> On 27 Jun 2013, at 15:50, "Brandenburg, R. (Ray) van" >>>> wrote: >>>>=20 >>>>=20 >>>> Hi Francois, >>>>=20 >>>> In general I agree with the proposal of having only two tracks: standa= rds-track and everything else. >=20 > Here again I question why two tracks are needed. >=20 >>>> However, I=92m not sure I understand how your proposal below would wor= k in practice. How would we distinguish between the two if we don=92t use n= amespace prefix? >>>>=20 >>>> You don't distinguish between the two. A parameter name is a parameter= name. That is exactly the point. This allows transition from "experimentat= ion" to "standards" without having to change the parameter name. Please hav= e alook at RFC 6648. >>>>=20 >>>> Let me restate: >>>> We basically say: >>>> * here is a registry >>>> * some names will be allocated through "Standards Action" >>>> * some names can be allocated through "Specification Required" >>>> That's it. >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>> And if it is all part of the same namespace, then what=92s the point o= f making the distinction and why not just require =91Specification Required= =92 for everything? >=20 > That sounds reasonable to me. It just happens to be the case that some of= those specifications will be RFCs. >=20 > Peter >=20 > >=20 From flefauch@cisco.com Fri Jun 28 02:03:52 2013 Return-Path: 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 382DF21F9E49 for ; Fri, 28 Jun 2013 02:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HTrDBDclbl7i for ; Fri, 28 Jun 2013 02:03:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 017BB21F9B2D for ; Fri, 28 Jun 2013 02:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1862; q=dns/txt; s=iport; t=1372410205; x=1373619805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tueqa0Oz3maGNo+5cJ6FR+A83uJFKg3c9W4RrLncnh4=; b=Q3EOxR4gVjBMaTTwuu+0DitT2WYkWZJXrPykPMXe2DeOwoXlyOOko7/5 O2LUAoRBX3yX64jMFrhc6Vbw5yZWFQ2GFYCMOLZve+sPfw7/Nqckwgyab HMPW64UZiueEamsm/80bB8I/piLYB9MkrQm2yMG/tR3hb/g64YA3vf0Hx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALFQzVGtJV2c/2dsb2JhbABbgwl6vwqBBRZ0giMBAQEDATo/EAIBCBgKFBAyJQIEDgUIDId0Brt0jyICMQeDAmMDqQqDEYIo X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208";a="225538228" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 09:03:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5S93Ob9010631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 09:03:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 04:03:24 -0500 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] CDNI Logging - IANA section Thread-Index: AQHOcpQgKeVGsgGFeU+hPbb70eXgyplJkSeAgAAItgCAAEA/AIAADzoAgAABTICAAAXtgIAAHlkAgABZPoCAACx+AIAAgKuAgAAWCYA= Date: Fri, 28 Jun 2013 09:03:23 +0000 Message-ID: References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peter Saint-Andre \(psaintan\)" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 09:03:52 -0000 Ben, On 28 Jun 2013, at 09:44, Ben Niven-Jenkins wrote= : >=20 > On 28 Jun 2013, at 01:04, Peter Saint-Andre (psaintan) wrote: >=20 >>> On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" wrote: >>>> So my take is we need to say that some names will be allocated accordi= ng to "Standards Action" and some names will be allocated according to "Spe= cification Required". >>=20 >> Why do we need two separate processes? >>=20 >> Please read RFC 6648. Or read it again. :-) In general there's no need t= o differentiate between "standard" parameters and "non-standard" parameters= . Is CDNI exceptional in this regard? >=20 > Not IMO. The objective of registration is to avoid collisions as they are= bad for interop. So the bar for registration must be low enough to not pre= vent people from registering. >=20 > For registered values that get enough momentum (de facto or via some kind= of RFC/standardisation) to be widely deployed an RFC/standard that describ= es them is useful to the community. >=20 > But I don't think anyone needs to 'vet' the namespace registrations in th= is instance unless we're really worried about people land grabbing/squattin= g which seems unlikely given the size of the registry space available (basi= cally unlimited). Based on RFC 6648, I think we are saying that if you want a name registered= in teh registry, it will have to go through the Specification Required pro= cess (ie get documented somewhere to a level that allows interoperable impl= ementation etc - but that's much lighter than the full RFC publication proc= ess). If you do not want to document the usage, then you can always use a non-all= ocated name (and use that in a "private" environment). Does that work for you? Francois >=20 > Ben >=20 From stpeter@stpeter.im Fri Jun 28 05:25:12 2013 Return-Path: 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 8AAC021F9D2D for ; Fri, 28 Jun 2013 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TZWmqLCNJJcV for ; Fri, 28 Jun 2013 05:25:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E198521F847A for ; Fri, 28 Jun 2013 05:24:59 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 819C3412FB; Fri, 28 Jun 2013 06:25:26 -0600 (MDT) Message-ID: <51CD809B.5040002@stpeter.im> Date: Fri, 28 Jun 2013 06:24:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A@tno.nl> <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "cdni@ietf.org" , "Peter Saint-Andre \(psaintan\)" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 12:25:12 -0000 On 6/28/13 3:03 AM, Francois Le Faucheur (flefauch) wrote: > Ben, > > On 28 Jun 2013, at 09:44, Ben Niven-Jenkins wrote: > >> >> On 28 Jun 2013, at 01:04, Peter Saint-Andre (psaintan) wrote: >> >>>> On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" wrote: >>>>> So my take is we need to say that some names will be allocated according to "Standards Action" and some names will be allocated according to "Specification Required". >>> >>> Why do we need two separate processes? >>> >>> Please read RFC 6648. Or read it again. :-) In general there's no need to differentiate between "standard" parameters and "non-standard" parameters. Is CDNI exceptional in this regard? >> >> Not IMO. The objective of registration is to avoid collisions as they are bad for interop. So the bar for registration must be low enough to not prevent people from registering. >> >> For registered values that get enough momentum (de facto or via some kind of RFC/standardisation) to be widely deployed an RFC/standard that describes them is useful to the community. >> >> But I don't think anyone needs to 'vet' the namespace registrations in this instance unless we're really worried about people land grabbing/squatting which seems unlikely given the size of the registry space available (basically unlimited). > > Based on RFC 6648, I think we are saying that if you want a name registered in teh registry, it will have to go through the Specification Required process (ie get documented somewhere to a level that allows interoperable implementation etc - but that's much lighter than the full RFC publication process). > If you do not want to document the usage, then you can always use a non-allocated name (and use that in a "private" environment). > > Does that work for you? That seems eminently reasonable to me! Peter -- Peter Saint-Andre https://stpeter.im/ From ben@niven-jenkins.co.uk Fri Jun 28 06:00:13 2013 Return-Path: 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 1613B21F9F20 for ; Fri, 28 Jun 2013 06:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 VOR-zgOFwy2T for ; Fri, 28 Jun 2013 06:00:01 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E121F9C31 for ; Fri, 28 Jun 2013 05:53:30 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UsYB6-00054O-A8; Fri, 28 Jun 2013 13:53:28 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 28 Jun 2013 13:53:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <027C7F68-44AE-4EE1-AA0A-0BD52C854499@niven-jenkins.co.uk> References: <32176_1367832523_518777CB_32176_694_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB906C34DC6@PEXCVZYM14.corporate.adroot.infra.ftgroup> <8D4EB831-1E5E-4DF9-815B-71CBAC655558@niven-jenkins.co.uk> , <1933AB61-5B1A-4B70-9CC2-F3F98E7BF56A @tno.nl> <1670FE635C32C34AAD005D960F1C501115C75A65@xmb-aln-x11.cisco.com> To: "Francois Le Faucheur (flefauch)" X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "Peter Saint-Andre \(psaintan\)" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Logging - IANA section 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 13:00:13 -0000 On 28 Jun 2013, at 10:03, Francois Le Faucheur (flefauch) wrote: > Ben, >=20 > On 28 Jun 2013, at 09:44, Ben Niven-Jenkins = wrote: >=20 >> On 28 Jun 2013, at 01:04, Peter Saint-Andre (psaintan) wrote: >>=20 >>>> On 27 jun. 2013, at 18:05, "Francois Le Faucheur (flefauch)" = wrote: >>>>> So my take is we need to say that some names will be allocated = according to "Standards Action" and some names will be allocated = according to "Specification Required". >>>=20 >>> Why do we need two separate processes? >>>=20 >>> Please read RFC 6648. Or read it again. :-) In general there's no = need to differentiate between "standard" parameters and "non-standard" = parameters. Is CDNI exceptional in this regard? >>=20 >> Not IMO. The objective of registration is to avoid collisions as they = are bad for interop. So the bar for registration must be low enough to = not prevent people from registering. >>=20 >> For registered values that get enough momentum (de facto or via some = kind of RFC/standardisation) to be widely deployed an RFC/standard that = describes them is useful to the community. >>=20 >> But I don't think anyone needs to 'vet' the namespace registrations = in this instance unless we're really worried about people land = grabbing/squatting which seems unlikely given the size of the registry = space available (basically unlimited). >=20 > Based on RFC 6648, I think we are saying that if you want a name = registered in teh registry, it will have to go through the Specification = Required process (ie get documented somewhere to a level that allows = interoperable implementation etc - but that's much lighter than the full = RFC publication process). > If you do not want to document the usage, then you can always use a = non-allocated name (and use that in a "private" environment). >=20 > Does that work for you? Yes. Thanks. Ben