From nobody Wed Jan 5 05:44:52 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539133A0910 for ; Wed, 5 Jan 2022 05:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id turapFljySUG for ; Wed, 5 Jan 2022 05:44:39 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4AF3A094B for ; Wed, 5 Jan 2022 05:44:39 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4JTW1c4TrKzFq67; Wed, 5 Jan 2022 14:44:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1641390276; bh=5Z5+PskCeckNaBJ8PalomLVmPbMqTpnvT/zcDS18Uqo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=nMBkfVO+YW6DBKpBkRZlUXNL+tA5JEINCCmsfgjjcU5isL6wEQjMOAtPySpuZbRuF IJ+GCLtboQ5qRDPv5Ai+GvCyI2kVEfNWmGaSJDqJObtUpP4xM3BpVWk55pqeZ1tyCj LezTljXfwsXXwf8a5sti/IBybkmKm/bNpVwl9XVeq3SRAjL3F+dEIeNS8Ob4pesLRZ /n9wr0lp2F5bQ88LVYQUgPZODlsmsBK2NyMWTgGnc6u7iMK2jtCQFyyR4ExEforDtw GhbcesLEGjKG+x4oj0+1tPg+OnQyOk/coE3CJg5c2/5RJgLbd6MIstC7hVsCVpClEp 0QPlLfC0h1JrA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar05.francetelecom.fr (ESMTP service) with ESMTPS id 4JTW1c3WXyz2xDh; Wed, 5 Jan 2022 14:44:36 +0100 (CET) From: To: "Joel M. Halpern" CC: Greg Mirsky , "sfc@ietf.org" Thread-Topic: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam Thread-Index: AQHXz1F51znvKMj22UuU/rlSA5k5qqwCudcAgAjtvoCAABcDgIAAKZkAgAAKXICAALeogIACHMmAgAFQW4CAACcHAIABERUAgAAC4wCABSLBgIAAZPeAgAAFfoCAAA1TAIAdpT2AgASQIoCAACOAgIADKDAA///w+YCAAADlgIAAHmUAgBhAtBA= Content-Class: Date: Wed, 5 Jan 2022 13:44:35 +0000 Message-ID: <6443_1641390276_61D5A0C4_6443_170_1_787AE7BB302AE849A7480A190F8B93303546D415@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <4bb5abb4-a8dc-c8f0-9b99-549f683e7729@joelhalpern.com> <896B8A4B-3717-4150-9944-44906A593BC9@cisco.com> <1B31F06E-974A-4BDA-8C89-81E61B8E6868@cisco.com> <005e334c-fd02-e7b2-4bef-3d0551c1b289@joelhalpern.com> <07cd39c5-9078-ec76-b340-43665d8805eb@joelhalpern.com> <2C6BEA5E-D7A3-4ED7-B1AD-A9353777045D@cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-01-05T12:22:17Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=abf70392-a64c-4d1c-a201-1fa3e5ed07c6; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Regarding last call for draft-ietf-sfc-multi-layer-oam X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 13:44:50 -0000 SGkgSm9lbCwgR3JlZywgYWxsLA0KDQpJIHVzZWQgdG8gaGF2ZSBpbiB0aGUgcGFzdCBhIGNvbW1l bnQgYWJvdXQgdGhlIHNhbWUgcGFydCBxdW90ZWQgYnkgQ2FybG9zLiANCg0KV2UgY291bGQgbGVh dmUgd2l0aG91dCB0YWdnaW5nIHRoZSBkb2N1bWVudCBhcyBpdCB1cGRhdGVzIDgzMDAgYnkgaW5k aWNhdGluZyB0aGF0LCBpbiB0aGUgY29udGV4dCBvZiBhY3RpdmUgT0FNIGNvdmVyZWQgaW4gdGhl IEktRCwgYW4gT0FNIHBhY2tldCAobWVudGlvbmVkIGluIDgzMDApIGlzICJhbiBPQU0gY29tbWFu ZCBhbmQvb3IgZGF0YSBpbiB0aGUgTlNIIENvbnRleHQgSGVhZGVyIG9yIHBhY2tldCBwYXlsb2Fk Ii4gDQoNCkhvd2V2ZXIsIHRoZSBydWxlcyBmb3IgaW50ZXJwcmV0aW5nIHRoZSBjb21iaW5hdGlv biBvZiAwLWJpdCBhbmQgbmV4dC1wcm90b2NvbCBqdXN0aWZpZXMgdGhlICJ1cGRhdGVzIiBoZWFk ZXIgYXMgdGhlIGRvY3VtZW50IHByb3ZpZGVzIHVzZWZ1bCBjaGFyYWN0ZXJpemF0aW9uIG9mIGFu IE9BTSBwYWNrZXQgYW5kIHpvb21zIGludG8gdGhpcyBwYXJ0IG9mIDgzMDA6DQoNCiAgICAgIFRo ZSBhY3R1YWwgZm9ybWF0IGFuZCBwcm9jZXNzaW5nIG9mIFNGQyBPQU0gcGFja2V0cyBpcyBvdXRz aWRlIHRoZQ0KICAgICAgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIChmb3IgZXhhbXBsZSwg c2VlIFtTRkMtT0FNLUZSQU1FV09SS10NCiAgICAgIGZvciBvbmUgYXBwcm9hY2gpLiANCg0KT2Yg Y291cnNlLCAidXBkYXRlcyIgaGVyZSBpcyB0byBiZSB1bmRlcnN0b29kIGFzICJleHRlbmRzIiwg bm90ICJhbWVuZHMiLg0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gRGXCoDogc2ZjIDxzZmMtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBK b2VsIE0uIEhhbHBlcm4NCj4gRW52b3nDqcKgOiBtYXJkaSAyMSBkw6ljZW1icmUgMjAyMSAwNDow MA0KPiDDgMKgOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPjsNCj4gSm9lbCBIYWxwZXJuIERpcmVjdCA8am1oLmRpcmVjdEBq b2VsaGFscGVybi5jb20+DQo+IENjwqA6IEphbWVzIE4gR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hh cmRAZnV0dXJld2VpLmNvbT47IEdyZWcgTWlyc2t5DQo+IDxncmVnaW1pcnNreUBnbWFpbC5jb20+ OyBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKQ0KPiA8ZmJyb2NrbmU9NDBjaXNjby5jb21AZG1h cmMuaWV0Zi5vcmc+OyBzZmNAaWV0Zi5vcmc7IEd5YW4gTWlzaHJhDQo+IDxoYXlhYnVzYWdzbUBn bWFpbC5jb20+DQo+IE9iamV0wqA6IFJlOiBbc2ZjXSBSZWdhcmRpbmcgbGFzdCBjYWxsIGZvciBk cmFmdC1pZXRmLXNmYy1tdWx0aS1sYXllci1vYW0NCj4gDQo+IEF0IHRoaXMgcG9pbnQgSSB3b3Vs ZCByZWFsbHkgbGlrZSB0byBoZWFyIGZyb20gb3RoZXIgcGVvcGxlIGluIHRoZQ0KPiB3b3JraW5n IGdyb3VwLg0KPiANCj4gSXMgYW55b25lIG90aGVyIHRoYW4gdGhlIGF1dGhvcnMsIENhcmxvcywg YWRuIEZyYW5rLCBwYXlpbmcgYXR0ZW50aW9uPw0KPiBQbGVhc2U/DQo+IA0KPiBUaGFuayB5b3Us DQo+IEpvZWwNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Jan 12 17:10:21 2022 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE47A3A09E3; Wed, 12 Jan 2022 17:10:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.42.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <164203621470.21519.16093746413476250644@ietfa.amsl.com> Date: Wed, 12 Jan 2022 17:10:14 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 01:10:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header Metadata Type 2 Variable-Length Context Headers Authors : Yuehua Wei Uri Elzur Sumandra Majee Carlos Pignataro Donald E. Eastlake Filename : draft-ietf-sfc-nsh-tlv-11.txt Pages : 13 Date : 2022-01-12 Abstract: Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-11 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Jan 12 23:36:09 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3093A08A1; Wed, 12 Jan 2022 23:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8gmJ6tjMNGD; Wed, 12 Jan 2022 23:36:03 -0800 (PST) Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20483A0897; Wed, 12 Jan 2022 23:36:02 -0800 (PST) Received: from mse-eu.zte.com.cn (unknown [10.35.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4JZGSN0XxRzB9B9P; Thu, 13 Jan 2022 15:35:48 +0800 (CST) Received: from dgapp01.zte.com.cn ([10.35.13.16]) by mse-eu.zte.com.cn with SMTP id 20D7ZfOc019375; Thu, 13 Jan 2022 15:35:41 +0800 (GMT-8) (envelope-from wei.yuehua@zte.com.cn) Received: from mapi (dgapp01[null]) by mapi (Zmail) with MAPI id mid1; Thu, 13 Jan 2022 15:35:43 +0800 (CST) Date: Thu, 13 Jan 2022 15:35:43 +0800 (CST) X-Zmail-TransId: 2af961dfd64fc9e69839 X-Mailer: Zmail v1.0 Message-ID: <202201131535434655513@zte.com.cn> References: 202112031730532332374@zte.com.cn Mime-Version: 1.0 From: To: , Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-eu.zte.com.cn 20D7ZfOc019375 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at 10-35-8-63 with ID 61DFD654.000 by FangMail milter! X-FangMail-Envelope: 1642059348/4JZGSN0XxRzB9B9P/61DFD654.000/10.35.13.51/[10.35.13.51]/mse-eu.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 61DFD654.000/4JZGSN0XxRzB9B9P Archived-At: Subject: [sfc] =?utf-8?q?Fw=3ARe=3A_Benjamin_Kaduk=27s_Discuss_on_draft-i?= =?utf-8?q?etf-sfc-nsh-tlv-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2022 07:36:07 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQoNClRoZSByb3VnaCByZXNvbHV0aW9uIHRvIHlvdXIgY29tbWVudHMgd2FzIHNl bnQgdG8gb24gMjAyMS0xMi00IC4gSSBmb3J3YXJkIHRoZSBwcmV2aW91cyBlbWFpbCBhZ2Fpbi4N Cg0KDQpXb3VsZCB5b3UgcGxlYXNlIHJldmlldyBteSBjb21tZW50cyBpbmxpbmU/DQoNCg0KdGhl IGxhdGVzdCB2ZXJzaW9uIGlzIGhlcmU6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtc2ZjLW5zaC10bHYvDQoNCg0KVGhhbmsgeW91Lg0KDQoNCg0KDQoNCg0KDQoN CkJlc3QgUmVnYXJkcywNCg0KDQpZdWVodWEgV2VpDQoNCg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoN Cg0KDQrlj5Hku7bkurrvvJrprY/mnIjljY4wMDAxOTY1NQ0K5pS25Lu25Lq677yaQmVuamFtaW5L YWR1a3ZpYURhdGF0cmFja2VyO21hcnRpbnZpZ291cmV1eDsNCuaKhOmAgeS6uu+8mlRoZSBJRVNH O2RyYWZ0LWlldGYtc2ZjLW5zaC10bHZAaWV0Zi5vcmc7c2ZjLWNoYWlyc0BpZXRmLm9yZztzZmNA aWV0Zi5vcmc7Z3JlZ2ltaXJza3lAZ21haWwuY29tOw0K5pelIOacnyDvvJoyMDIx5bm0MTLmnIgw M+aXpSAxNzozMA0K5Li7IOmimCDvvJpSZTpbc2ZjXSBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cg0KDQpEZWFyIEJlbiwNClRoYW5rIHlvdS4gcGxlYXNlIHNlZSB0aGUgY29tbWV0IHJlc29sdXRp b24gaW5saW5lIHdpdGggWXVlaHVhPj4NCg0KVG8gTWFydGluLCAgSSByZWFsbHkgYXBwcmVjaWF0 ZSBpZiB5b3UgY291bGQgcHJvdmlkZSBjb21tZW50cyB0byBZdWVodWEtMiBhbmQgWXVlaGF1LTYu IA0KDQpCZXN0IFJlZ2FyZHMsDQpZdWVodWEgV2VpDQpaVEUgQ29ycG9yYXRpb24NCi0tLS0tLS0t LS0tLS0tLS0tLeWOn+Wni+mCruS7ti0tLS0tLS0tLS0tLS0tLS0tLQ0K5Y+R5Lu25Lq677yaQmVu amFtaW5LYWR1a3ZpYURhdGF0cmFja2VyDQrmlLbku7bkurrvvJpUaGUgSUVTRzsNCuaKhOmAgeS6 uu+8mmRyYWZ0LWlldGYtc2ZjLW5zaC10bHZAaWV0Zi5vcmc7c2ZjLWNoYWlyc0BpZXRmLm9yZztz ZmNAaWV0Zi5vcmc7Z3JlZ2ltaXJza3lAZ21haWwuY29tOw0K5pelIOacnyDvvJoyMDIx5bm0MTHm nIgzMOaXpSAwMjo1OQ0K5Li7IOmimCDvvJpbc2ZjXSBCZW5qYW1pbiBLYWR1aydzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN CkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvcg0KZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi0wOTogRGlzY3Vzcw0KDQpXaGVuIHJlc3BvbmRp bmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwN CmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBm cmVlIHRvIGN1dCB0aGlzDQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCg0KDQpQ bGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYmxvZy9oYW5kbGluZy1pZXNnLWJh bGxvdC1wb3NpdGlvbnMvDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBob3cgdG8gaGFuZGxl IERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC10bHYvDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQooMSkgUkZDIDgzMDAgaXMg cHJldHR5IGNsZWFyIHRoYXQgIk1ldGFkYXRhIHByaXZhY3kgYW5kIHNlY3VyaXR5DQpjb25zaWRl cmF0aW9ucyBhcmUgYSBtYXR0ZXIgZm9yIHRoZSBkb2N1bWVudHMgdGhhdCBkZWZpbmUgbWV0YWRh dGENCmZvcm1hdC4iICBTb21lIG9mIHRoZSBtZXRhZGF0YSBjb250ZXh0IGhlYWRlcnMgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50DQpjbGVhcmx5IGhhdmUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyB0 aGF0IG5lZWQgdG8gYmUgZG9jdW1lbnRlZCAoZS5nLiwNCnBvbGljeSBJRCBhbmQgc291cmNlL2Rl c3RpbmF0aW9uIGdyb3VwIHNlcnZlIHRvIGNvbmNyZXRlbHkgaWRlbnRpZnkNCmZsb3dzIHRoYXQg YXJlIHJlbGF0ZWQgaW4gc29tZSB3YXkpLCB0aG91Z2ggc29tZSBtYXkgbm90IGhhdmUgbXVjaCB0 aGF0DQpuZWVkcyBkb2N1bWVudGluZyAoZS5nLiwgdGhlIGZvcndhcmRpbmcgY29udGV4dCBtZXRh ZGF0YSBzZWVtcyB0byBqdXN0DQpiZSBleHRyYWN0aW5nIG91dCBpbmZvcm1hdGlvbiB0aGF0IGlz IGFscmVhZHkgcHJlc2VudCBpbiB0aGUgcGFja2V0DQpiZWluZyB3cmFwcGVkKS4gIFJlZ2FyZGxl c3MsIHdlIG5lZWQgdG8gaGF2ZSBzb21lIGRpc2N1c3Npb24gb2YgdGhlDQpwcml2YWN5IGFuZCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvZiB0aGUgbmV3IG1ldGFkYXRhIGNvbnRleHQgaGVhZGVy cywNCmV2ZW4gaWYgdGhhdCBpcyBqdXN0ICJubyBuZXcgY29uc2lkZXJhdGlvbnMiIGZvciBzb21l IG9mIHRoZW0uDQoNCll1ZWh1YS0xPj5UaGFuayB5b3UsIEkgdXBkYXRlIHRoZSBzZWN0aW9uIHRv IHZlcjEwIHBlciB5b3UsIFN0aWcgYW5kIEpvaG4ncyBjb21tZW50cy4gIHBsZWFzZSB0YWtlIGEg bG9vayBhbmQgcHJvdmlkZSBmdXJ0aGVyIGNvbW1lbnRzDQoNCigyKSBJIHRoaW5rIHdlIG5lZWQg dG8gZGlzY3VzcyB0aGUgRmxvdyBJRCBjb250ZXh0IGhlYWRlciBmdXJ0aGVyLiAgSXMNCml0IGlu dGVuZGVkIHRvIGp1c3QgYmUgYSBjb250YWluZXIgdG8gaG9sZCBhIGZsb3cgaWRlbnRpZmllciBh bHJlYWR5DQpwcmVzZW50IGluIHRoZSBjb250YWluZWQgcGFja2V0IChzdWNoIGFzIHRoZSBJUHY2 IEZsb3cgTGFiZWwgb3IgTVBMUw0KRW50cm9weSBMYWJlbCB0aGF0IGFyZSBjYWxsZWQgb3V0KSwg b3IgY2FuIGl0IGFsc28gYmUgdXNlZCB0byBhcHBseSBhDQpuZXcgZmxvdyBpZGVudGlmaWVyIGF0 IHRoZSBTRkMgbGF5ZXI/DQoNClRoZSBuYW1lZCBleGFtcGxlcyBvZiBhIGZsb3cgSUQgYXJlIGJv dGggMjAgYml0cyBsb25nOyBpZiB0aGF0IGlzIGFuDQpleGhhdXN0aXZlIGxpc3RpbmcsIHNob3Vs ZG4ndCB3ZSB1cGRhdGUgdGhlIGZpZ3VyZSBhY2NvcmRpbmdseSAodG8NCmluY2x1ZGUgTGVuZ3Ro PTMsIGZvdXIgbGVhZGluZyBiaXRzIG9mIHBhZGRpbmcsIGFuZCBhIHRyYWlsaW5nIGJ5dGUgb2YN CnBhZGRpbmcpPyAgSWYgdGhhdCBpcyBub3QgYW4gZXhoYXVzdGl2ZSBsaXN0aW5nIGFuZCBsb25n ZXIgZmxvdw0KaWRlbnRpZmllcnMgYXJlIGV4cGVjdGVkLCBob3cgZG8gd2Uga25vdyB3aGF0IGxl bmd0aCBvZiBmbG93IGlkZW50aWZpZXINCmlzIGJlaW5nIGNvbnZleWVkPw0KDQpZdWVodWEtMj4+ WW91IHJhaXNlZCBhIGdvb2QgcXVlc3Rpb24uIEkgcHJlZmVyIHRvIGFkZCBDb250ZXh0IFR5cGUg KENUKSB0byBkaXN0aW5ndWlzaCBkaWZmZXJlbnQgZmxvdyBJRHMuIEknZCBhcHByZWNpYXRlIHlv dXIgYWR2aWNlLg0KDQooMykgSWYgd2UgYXJlIHRvIGFsbG93IGZvciBzcGVjaWZ5aW5nIHRoZSAi bG9naWNhbCBncm91cGluZyBvZiBzb3VyY2UgYW5kL29yDQpkZXN0aW5hdGlvbiBvYmplY3RzIiBp biDCpzQuNiAoZW1waGFzaXMgb24gImFuZC9vciIpLCBidXQgdGhlIGNvbnRleHQNCmhlYWRlciBh bHdheXMgY29udmV5cyBib3RoIGEgc291cmNlIGdyb3VwIGFuZCBkZXN0IGdyb3VwIGZpZWxkLCBk byB3ZQ0KbmVlZCB0byByZXNlcnZlIGEgZGVkaWNhdGVkIHZhbHVlIGZvciAibm8gZ3JvdXAgaW5m b3JtYXRpb24gc3BlY2lmaWVkIj8NCg0KWXVlaHVhLTM+PlZlcnkgZ29vZCBvYnNlcnZhdGlvbi4g U2hhbGwgd2Ugc3RhdGUgdGhhdCBpZiB0aGVyZSBpcyAgICJubyBncm91cCBpbmZvcm1hdGlvbiBz cGVjaWZpZWQiIGZvciB0aGUgc291cmNlIG9yIGRlc3QgZmllbGQsIHRoZSBmaWVsZCBNVVNUIGJl IHNlbnQgYXMgemVybyBhbmQgaWdub3JlZCBvbiByZWNlaXB0DQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNP TU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24gMQ0KDQpUaGlzIGRvY3VtZW50IGRvZXMg bm90IGFkZHJlc3MgbWV0YWRhdGEgdXNhZ2UsIHVwZGF0aW5nL2NoYWluaW5nIG9mDQptZXRhZGF0 YSwgb3Igb3RoZXIgU0ZQIGZ1bmN0aW9ucy4gIFRob3NlIHRvcGljcyBhcmUgZGVzY3JpYmVkIGlu DQpbUkZDODMwMF0uDQoNCkknbSBub3QgZW50aXJlbHkgc3VyZSB3aGF0IGlzIG1lYW50IGJ5ICJj aGFpbmluZyBvZiBtZXRhZGF0YSIgKHVubGVzcw0KaXQncyBqdXN0IGEgc3lub255bSBmb3IgInVw ZGF0aW5nIG9mIG1ldGFkYXRhIj8pLCBhbmQgaGF2aW5nIHJldmlld2VkDQphbGwgMTggaW5zdGFu Y2VzIG9mICJjaGFpbiIgYW5kIDg4IGluc3RhbmNlcyBvZiAibWV0YWRhdGEiIGluIFJGQyA4MzAw LA0KSSBhbSBub3Qgc3VyZSB3aGljaCBwYXJ0IHlvdSdyZSBpbnRlbmRpbmcgdG8gcmVmZXIgdG8g YnkgaXQuICBDb3VsZCB5b3UNCnBsZWFzZSBwb2ludCB0byBhIG1vcmUgc3BlY2lmaWMgcGFydCBv ZiBSRkMgODMwMCAoYXQgbGVhc3QgaW4gdGhpcyBlbWFpbA0KdGhyZWFkIGZvciBub3csIG5vdCBu ZWNlc3NhcmlseSBpbiBhIGRvY3VtZW50IHVwZGF0ZSk/DQoNCll1ZWh1YS00Pj4gUkZDODMwMCBk b2Vzbid0IHVzZSDigJxjaGFpbuKAnXRvIGRpc2NyaWJlIG11bHRpcGxlIG1ldGFkYXRhLg0KaXQg bWVudGlvbnMgIklmIG11bHRpcGxlIG1hbmRhdG9yeS10by1wcm9jZXNzIENvbnRleHQgSGVhZGVy cyBhcmUgcmVxdWlyZWQgZm9yIGEgICBnaXZlbiBTRlAiIGFuZCAiSWYgbXVsdGlwbGUgaW5zdGFu Y2VzIG9mIHRoZSBzYW1lIG1ldGFkYXRhIGFyZSBpbmNsdWRlZCBpbiBhbiBOU0ggICBwYWNrZXQi IGluIFJGQzgzMDAgc2VjdGlvbiAyLjUuMQ0KRnVydGhlciBjb21tZW50cyBhcmUgd2VsY29tZQ0K DQoNClNlY3Rpb24gNC4xDQoNCkkgc3VnZ2VzdCBwdXR0aW5nIGEgY29udGV4dCAoZm9yZ2l2ZSB0 aGUgcHVuKSBpbmRpY2F0b3IgaW4gdGhlIGZpZ3VyZQ0KbGVnZW5kcywgZS5nLiwgIkZpZ3VyZSA0 OiBGb3J3YXJkaW5nIENvbnRleHQgLSAyIChRaW5RKSIuICBUaGUNCmluZm9ybWF0aW9uIGlzIGFs cmVhZHkgYXZhaWxhYmxlIGVsc2V3aGVyZSwgYnV0IGhhdmluZyBpdCBpbiB0aGUgY2FwdGlvbg0K aGVscHMgZm9jdXMgdGhlIHJlYWRlciBvbiB0aGUgaW1wb3J0YW50L3JlbGV2YW50IHBhcnQgb2Yg dGhlIGZpZ3VyZS4NCg0KWXVlaHVhLTU+PiBBY2NlcHRlZCwgd2lsbCB1cGRhdGUgdG8gdmVyMTAN Cg0KU2VjdGlvbiA0LjMNCg0KSXQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gc2F5IHNvbWV0aGlu ZyBhYm91dCB3aGVuIHRoZSBTUEkgaXRzZWxmDQpzdWZmaWNlcyB0byBpZGVudGlmeSB0aGUgaW5n cmVzcyBub2RlIHZzLiB3aGVuIHRoaXMgbWV0YWRhdGEgY29udGV4dA0KaGVhZGVyIGlzIG5lZWRl ZC4NCg0KTm9kZSBJRDogUmVwcmVzZW50cyBhbiBvcGFxdWUgdmFsdWUgb2YgdGhlIGluZ3Jlc3Mg bmV0d29yayBub2RlDQpJRC4gIFRoZSBzdHJ1Y3R1cmUgYW5kIHNlbWFudGljcyBvZiB0aGlzIGZp ZWxkIGFyZSBkZXBsb3ltZW50DQpzcGVjaWZpYy4gIEZvciBleGFtcGxlLCBOb2RlIElEIG1heSBi ZSBhIDQgYnl0ZXMgSVB2NCBhZGRyZXNzIE5vZGUNCklELCBvciBhIDE2IGJ5dGVzIElQdjYgYWRk cmVzcyBOb2RlIElELCBvciBhIDYgYnl0ZXMgTUFDIGFkZHJlc3MsDQpvciA4IGJ5dGVzIE1BQyBh ZGRyZXNzIChFVUktNjQpLCBldGMsLg0KDQpUaGVyZSBzZWVtcyB0byBiZSBzb21lIGRpc3NvbmFu Y2UgYmV0d2VlbiBzYXlpbmcgdGhpcyBmaWVsZCBpcyAiYW4NCm9wYXF1ZSB2YWx1ZSIgYW5kIGFs c28gc2F5aW5nIHRoYXQgaXQgbWlnaHQgYmUgYW4gSVAgb3IgTUFDIGFkZHJlc3MuICBJbg0KdGhl IHZlaW4gb2YgRnJhbmNlc2NhJ3MgRGlzY3VzcyBwb2ludCwgSSBkb24ndCB0aGluayB3ZSBjYW4g aGF2ZQ0KaW50ZXJvcGVyYWJpbGl0eSBpZiB0aGUgTlNIIGltcGxlbWVudGF0aW9uIGlzIGV4cGVj dGVkIHRvIHByb2Nlc3MgdGhpcw0KYXMgSVAvTUFDIGFkZHJlc3MgaW5mb3JtYXRpb24gKGFzIG9w cG9zZWQgdG8ganVzdCBhbiBvcGFxdWUgaWRlbnRpZmllcikuDQoNCll1ZWh1YS02Pj4gaXQgaGFz IHJlbGF0aW9uIHRvIA0KDQpTZWN0aW9uIDguMg0KDQpVUkxzIGZvciBbR1JPVVBCQVNFRFBPTElD WV0gYW5kIFtHUk9VUFBPTElDWV0gd291bGQgYmUgaGVscGZ1bC4NCll1ZWh1YS03Pj4gQWNjZXB0 ZWQsIHdpbGwgZml4IHRoZSBwcm9ibGVtIHRvIHZlcjEwDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTJweDtmb250LWZh bWlseTpzYW5zLXNlcmlmOyI+PGJyPjwvcD48cCBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsg Zm9udC1zaXplOiAxMnB4OyI+SGkgQmVuLDwvcD48cCBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1h bDsiPlRoZSByb3VnaCByZXNvbHV0aW9uIHRvIHlvdXIgY29tbWVudHMgd2FzIHNlbnQgdG8gb24m bmJzcDsyMDIxLTEyLTQgLiBJIGZvcndhcmQgdGhlIHByZXZpb3VzIGVtYWlsIGFnYWluLjwvcD48 cCBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPldvdWxkIHlvdSBwbGVhc2UgcmV2aWV3IG15 IGNvbW1lbnRzIGlubGluZT88L3A+PHAgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij50aGUg bGF0ZXN0IHZlcnNpb24gaXMgaGVyZTombmJzcDs8YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi8iPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLW5zaC10bHYvPC9h PjwvcD48cCBzdHlsZT0id2hpdGUtc3BhY2U6IG5vcm1hbDsiPlRoYW5rIHlvdS48L3A+PHAgc3R5 bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7IGZvbnQtc2l6ZTogMTJweDsiPjxicj48L3A+PGRpdiB1 bm9uYW1lY2g9Iumtj+aciOWNjjAwMDE5NjU1IiB1bm9uYW1lZW49IndlaSB5dWVodWEwMDAxOTY1 NSIgc3R5bGU9IndoaXRlLXNwYWNlOiBub3JtYWw7Ij48ZGl2IGNsYXNzPSJ6TWFpbFNpZ25Db250 ZW50Ij48cCBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7Ij48c3Ry b25nPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDE0MiwgMjExKTsgZm9udC1mYW1pbHk6IEFy aWFsOyI+QmVzdCBSZWdhcmRzLDwvc3Bhbj48L3N0cm9uZz48L3A+PHAgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBsaW5lLWhlaWdodDogMjBweDsiPjxzdHJvbmcg c3R5bGU9ImZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDEuNWVtOyI+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMzgsIDM4LCAzOCk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5EsIHNhbnMt c2VyaWY7Ij5ZdWVodWEgV2VpPC9zcGFuPjwvc3Ryb25nPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHlsZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0i emhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDogMTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdo dDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjogI0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQt YWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7 tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRy b2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxl PSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcg bGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNw YW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPumtj+aciOWNjjAwMDE5NjU1PC9zcGFuPjwvZGl2Pjxk aXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ry b25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ QmVuamFtaW5LYWR1a3ZpYURhdGF0cmFja2VyPG5vcmVwbHlAaWV0Zi5vcmc+Ozwvbm9yZXBseUBp ZXRmLm9yZz48L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5 OiBpbmxpbmU7Ij5tYXJ0aW52aWdvdXJldXg8bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+Ozwv bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20+PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5n dWFnZS1kYXRhPSJIaXN0b3J5Q0NUeHQiPuaKhOmAgeS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNz PSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+VGhlIElFU0c8aWVzZ0Bp ZXRmLm9yZz47PC9pZXNnQGlldGYub3JnPjwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFt ZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPmRyYWZ0LWlldGYtc2ZjLW5zaC10bHZAaWV0Zi5v cmc8ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdkBpZXRmLm9yZz47PC9kcmFmdC1pZXRmLXNmYy1uc2gt dGx2QGlldGYub3JnPjwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRp c3BsYXk6IGlubGluZTsiPnNmYy1jaGFpcnNAaWV0Zi5vcmc8c2ZjLWNoYWlyc0BpZXRmLm9yZz47 PC9zZmMtY2hhaXJzQGlldGYub3JnPjwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIg c3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPnNmY0BpZXRmLm9yZzxzZmNAaWV0Zi5vcmc+Ozwvc2Zj QGlldGYub3JnPjwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTxncmVnaW1pcnNreUBnbWFpbC5jb20+ OzwvZ3JlZ2ltaXJza3lAZ21haWwuY29tPjwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9 IiI+MjAyMeW5tDEy5pyIMDPml6UgMTc6MzA8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1 YWdlLWRhdGE9Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJ6cmVhZFRpdGxlIj48c3Ryb25nPlJlOltzZmNdIEJlbmphbWluIEthZHVrJ3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLXNmYy1uc2gtdGx2LTA5OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KTwvc3Ryb25nPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRlbnQi PjxkaXY+RGVhciZuYnNwO0Jlbiw8YnI+VGhhbmsmbmJzcDt5b3UuJm5ic3A7cGxlYXNlJm5ic3A7 c2VlJm5ic3A7dGhlJm5ic3A7Y29tbWV0Jm5ic3A7cmVzb2x1dGlvbiZuYnNwO2lubGluZSZuYnNw O3dpdGgmbmJzcDtZdWVodWEmZ3Q7Jmd0Ozxicj48YnI+VG8mbmJzcDtNYXJ0aW4sJm5ic3A7Jm5i c3A7SSZuYnNwO3JlYWxseSZuYnNwO2FwcHJlY2lhdGUmbmJzcDtpZiZuYnNwO3lvdSZuYnNwO2Nv dWxkJm5ic3A7cHJvdmlkZSZuYnNwO2NvbW1lbnRzJm5ic3A7dG8mbmJzcDtZdWVodWEtMiZuYnNw O2FuZCZuYnNwO1l1ZWhhdS02LiZuYnNwOzxicj48YnI+QmVzdCZuYnNwO1JlZ2FyZHMsPGJyPll1 ZWh1YSZuYnNwO1dlaTxicj5aVEUmbmJzcDtDb3Jwb3JhdGlvbjxicj4tLS0tLS0tLS0tLS0tLS0t LS3ljp/lp4vpgq7ku7YtLS0tLS0tLS0tLS0tLS0tLS08YnI+5Y+R5Lu25Lq677yaQmVuamFtaW5L YWR1a3ZpYURhdGF0cmFja2VyPGJyPuaUtuS7tuS6uu+8mlRoZSZuYnNwO0lFU0c7PGJyPuaKhOmA geS6uu+8mmRyYWZ0LWlldGYtc2ZjLW5zaC10bHZAaWV0Zi5vcmc7c2ZjLWNoYWlyc0BpZXRmLm9y ZztzZmNAaWV0Zi5vcmc7Z3JlZ2ltaXJza3lAZ21haWwuY29tOzxicj7ml6UmbmJzcDvmnJ8mbmJz cDvvvJoyMDIx5bm0MTHmnIgzMOaXpSZuYnNwOzAyOjU5PGJyPuS4uyZuYnNwO+mimCZuYnNwO++8 mltzZmNdJm5ic3A7QmVuamFtaW4mbmJzcDtLYWR1aydzJm5ic3A7RGlzY3VzcyZuYnNwO29uJm5i c3A7ZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi0wOTombmJzcDsod2l0aCZuYnNwO0RJU0NVU1MmbmJz cDthbmQmbmJzcDtDT01NRU5UKTxicj5CZW5qYW1pbiZuYnNwO0thZHVrJm5ic3A7aGFzJm5ic3A7 ZW50ZXJlZCZuYnNwO3RoZSZuYnNwO2ZvbGxvd2luZyZuYnNwO2JhbGxvdCZuYnNwO3Bvc2l0aW9u Jm5ic3A7Zm9yPGJyPmRyYWZ0LWlldGYtc2ZjLW5zaC10bHYtMDk6Jm5ic3A7RGlzY3Vzczxicj48 YnI+V2hlbiZuYnNwO3Jlc3BvbmRpbmcsJm5ic3A7cGxlYXNlJm5ic3A7a2VlcCZuYnNwO3RoZSZu YnNwO3N1YmplY3QmbmJzcDtsaW5lJm5ic3A7aW50YWN0Jm5ic3A7YW5kJm5ic3A7cmVwbHkmbmJz cDt0byZuYnNwO2FsbDxicj5lbWFpbCZuYnNwO2FkZHJlc3NlcyZuYnNwO2luY2x1ZGVkJm5ic3A7 aW4mbmJzcDt0aGUmbmJzcDtUbyZuYnNwO2FuZCZuYnNwO0NDJm5ic3A7bGluZXMuJm5ic3A7KEZl ZWwmbmJzcDtmcmVlJm5ic3A7dG8mbmJzcDtjdXQmbmJzcDt0aGlzPGJyPmludHJvZHVjdG9yeSZu YnNwO3BhcmFncmFwaCwmbmJzcDtob3dldmVyLik8YnI+PGJyPjxicj5QbGVhc2UmbmJzcDtyZWZl ciZuYnNwO3RvJm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYmxvZy9oYW5kbGluZy1pZXNnLWJh bGxvdC1wb3NpdGlvbnMvPGJyPmZvciZuYnNwO21vcmUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Fi b3V0Jm5ic3A7aG93Jm5ic3A7dG8mbmJzcDtoYW5kbGUmbmJzcDtESVNDVVNTJm5ic3A7YW5kJm5i c3A7Q09NTUVOVCZuYnNwO3Bvc2l0aW9ucy48YnI+PGJyPjxicj5UaGUmbmJzcDtkb2N1bWVudCwm bmJzcDthbG9uZyZuYnNwO3dpdGgmbmJzcDtvdGhlciZuYnNwO2JhbGxvdCZuYnNwO3Bvc2l0aW9u cywmbmJzcDtjYW4mbmJzcDtiZSZuYnNwO2ZvdW5kJm5ic3A7aGVyZTo8YnI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtbnNoLXRsdi88YnI+PGJyPjxicj48 YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxicj5ESVNDVVNTOjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj4oMSkm bmJzcDtSRkMmbmJzcDs4MzAwJm5ic3A7aXMmbmJzcDtwcmV0dHkmbmJzcDtjbGVhciZuYnNwO3Ro YXQmbmJzcDsiTWV0YWRhdGEmbmJzcDtwcml2YWN5Jm5ic3A7YW5kJm5ic3A7c2VjdXJpdHk8YnI+ Y29uc2lkZXJhdGlvbnMmbmJzcDthcmUmbmJzcDthJm5ic3A7bWF0dGVyJm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7ZG9jdW1lbnRzJm5ic3A7dGhhdCZuYnNwO2RlZmluZSZuYnNwO21ldGFkYXRhPGJy PmZvcm1hdC4iJm5ic3A7Jm5ic3A7U29tZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWV0YWRhdGEm bmJzcDtjb250ZXh0Jm5ic3A7aGVhZGVycyZuYnNwO2RlZmluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDtkb2N1bWVudDxicj5jbGVhcmx5Jm5ic3A7aGF2ZSZuYnNwO3ByaXZhY3kmbmJzcDtjb25z aWRlcmF0aW9ucyZuYnNwO3RoYXQmbmJzcDtuZWVkJm5ic3A7dG8mbmJzcDtiZSZuYnNwO2RvY3Vt ZW50ZWQmbmJzcDsoZS5nLiw8YnI+cG9saWN5Jm5ic3A7SUQmbmJzcDthbmQmbmJzcDtzb3VyY2Uv ZGVzdGluYXRpb24mbmJzcDtncm91cCZuYnNwO3NlcnZlJm5ic3A7dG8mbmJzcDtjb25jcmV0ZWx5 Jm5ic3A7aWRlbnRpZnk8YnI+Zmxvd3MmbmJzcDt0aGF0Jm5ic3A7YXJlJm5ic3A7cmVsYXRlZCZu YnNwO2luJm5ic3A7c29tZSZuYnNwO3dheSksJm5ic3A7dGhvdWdoJm5ic3A7c29tZSZuYnNwO21h eSZuYnNwO25vdCZuYnNwO2hhdmUmbmJzcDttdWNoJm5ic3A7dGhhdDxicj5uZWVkcyZuYnNwO2Rv Y3VtZW50aW5nJm5ic3A7KGUuZy4sJm5ic3A7dGhlJm5ic3A7Zm9yd2FyZGluZyZuYnNwO2NvbnRl eHQmbmJzcDttZXRhZGF0YSZuYnNwO3NlZW1zJm5ic3A7dG8mbmJzcDtqdXN0PGJyPmJlJm5ic3A7 ZXh0cmFjdGluZyZuYnNwO291dCZuYnNwO2luZm9ybWF0aW9uJm5ic3A7dGhhdCZuYnNwO2lzJm5i c3A7YWxyZWFkeSZuYnNwO3ByZXNlbnQmbmJzcDtpbiZuYnNwO3RoZSZuYnNwO3BhY2tldDxicj5i ZWluZyZuYnNwO3dyYXBwZWQpLiZuYnNwOyZuYnNwO1JlZ2FyZGxlc3MsJm5ic3A7d2UmbmJzcDtu ZWVkJm5ic3A7dG8mbmJzcDtoYXZlJm5ic3A7c29tZSZuYnNwO2Rpc2N1c3Npb24mbmJzcDtvZiZu YnNwO3RoZTxicj5wcml2YWN5Jm5ic3A7YW5kJm5ic3A7c2VjdXJpdHkmbmJzcDtjb25zaWRlcmF0 aW9ucyZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bmV3Jm5ic3A7bWV0YWRhdGEmbmJzcDtjb250ZXh0 Jm5ic3A7aGVhZGVycyw8YnI+ZXZlbiZuYnNwO2lmJm5ic3A7dGhhdCZuYnNwO2lzJm5ic3A7anVz dCZuYnNwOyJubyZuYnNwO25ldyZuYnNwO2NvbnNpZGVyYXRpb25zIiZuYnNwO2ZvciZuYnNwO3Nv bWUmbmJzcDtvZiZuYnNwO3RoZW0uPGJyPjxicj5ZdWVodWEtMSZndDsmZ3Q7VGhhbmsmbmJzcDt5 b3UsJm5ic3A7SSZuYnNwO3VwZGF0ZSZuYnNwO3RoZSZuYnNwO3NlY3Rpb24mbmJzcDt0byZuYnNw O3ZlcjEwJm5ic3A7cGVyJm5ic3A7eW91LCZuYnNwO1N0aWcmbmJzcDthbmQmbmJzcDtKb2huJ3Mm bmJzcDtjb21tZW50cy4mbmJzcDsmbmJzcDtwbGVhc2UmbmJzcDt0YWtlJm5ic3A7YSZuYnNwO2xv b2smbmJzcDthbmQmbmJzcDtwcm92aWRlJm5ic3A7ZnVydGhlciZuYnNwO2NvbW1lbnRzPGJyPjxi cj4oMikmbmJzcDtJJm5ic3A7dGhpbmsmbmJzcDt3ZSZuYnNwO25lZWQmbmJzcDt0byZuYnNwO2Rp c2N1c3MmbmJzcDt0aGUmbmJzcDtGbG93Jm5ic3A7SUQmbmJzcDtjb250ZXh0Jm5ic3A7aGVhZGVy Jm5ic3A7ZnVydGhlci4mbmJzcDsmbmJzcDtJczxicj5pdCZuYnNwO2ludGVuZGVkJm5ic3A7dG8m bmJzcDtqdXN0Jm5ic3A7YmUmbmJzcDthJm5ic3A7Y29udGFpbmVyJm5ic3A7dG8mbmJzcDtob2xk Jm5ic3A7YSZuYnNwO2Zsb3cmbmJzcDtpZGVudGlmaWVyJm5ic3A7YWxyZWFkeTxicj5wcmVzZW50 Jm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtjb250YWluZWQmbmJzcDtwYWNrZXQmbmJzcDsoc3VjaCZu YnNwO2FzJm5ic3A7dGhlJm5ic3A7SVB2NiZuYnNwO0Zsb3cmbmJzcDtMYWJlbCZuYnNwO29yJm5i c3A7TVBMUzxicj5FbnRyb3B5Jm5ic3A7TGFiZWwmbmJzcDt0aGF0Jm5ic3A7YXJlJm5ic3A7Y2Fs bGVkJm5ic3A7b3V0KSwmbmJzcDtvciZuYnNwO2NhbiZuYnNwO2l0Jm5ic3A7YWxzbyZuYnNwO2Jl Jm5ic3A7dXNlZCZuYnNwO3RvJm5ic3A7YXBwbHkmbmJzcDthPGJyPm5ldyZuYnNwO2Zsb3cmbmJz cDtpZGVudGlmaWVyJm5ic3A7YXQmbmJzcDt0aGUmbmJzcDtTRkMmbmJzcDtsYXllcj88YnI+PGJy PlRoZSZuYnNwO25hbWVkJm5ic3A7ZXhhbXBsZXMmbmJzcDtvZiZuYnNwO2EmbmJzcDtmbG93Jm5i c3A7SUQmbmJzcDthcmUmbmJzcDtib3RoJm5ic3A7MjAmbmJzcDtiaXRzJm5ic3A7bG9uZzsmbmJz cDtpZiZuYnNwO3RoYXQmbmJzcDtpcyZuYnNwO2FuPGJyPmV4aGF1c3RpdmUmbmJzcDtsaXN0aW5n LCZuYnNwO3Nob3VsZG4ndCZuYnNwO3dlJm5ic3A7dXBkYXRlJm5ic3A7dGhlJm5ic3A7ZmlndXJl Jm5ic3A7YWNjb3JkaW5nbHkmbmJzcDsodG88YnI+aW5jbHVkZSZuYnNwO0xlbmd0aD0zLCZuYnNw O2ZvdXImbmJzcDtsZWFkaW5nJm5ic3A7Yml0cyZuYnNwO29mJm5ic3A7cGFkZGluZywmbmJzcDth bmQmbmJzcDthJm5ic3A7dHJhaWxpbmcmbmJzcDtieXRlJm5ic3A7b2Y8YnI+cGFkZGluZyk/Jm5i c3A7Jm5ic3A7SWYmbmJzcDt0aGF0Jm5ic3A7aXMmbmJzcDtub3QmbmJzcDthbiZuYnNwO2V4aGF1 c3RpdmUmbmJzcDtsaXN0aW5nJm5ic3A7YW5kJm5ic3A7bG9uZ2VyJm5ic3A7Zmxvdzxicj5pZGVu dGlmaWVycyZuYnNwO2FyZSZuYnNwO2V4cGVjdGVkLCZuYnNwO2hvdyZuYnNwO2RvJm5ic3A7d2Um bmJzcDtrbm93Jm5ic3A7d2hhdCZuYnNwO2xlbmd0aCZuYnNwO29mJm5ic3A7ZmxvdyZuYnNwO2lk ZW50aWZpZXI8YnI+aXMmbmJzcDtiZWluZyZuYnNwO2NvbnZleWVkPzxicj48YnI+WXVlaHVhLTIm Z3Q7Jmd0O1lvdSZuYnNwO3JhaXNlZCZuYnNwO2EmbmJzcDtnb29kJm5ic3A7cXVlc3Rpb24uJm5i c3A7SSZuYnNwO3ByZWZlciZuYnNwO3RvJm5ic3A7YWRkJm5ic3A7Q29udGV4dCZuYnNwO1R5cGUm bmJzcDsoQ1QpJm5ic3A7dG8mbmJzcDtkaXN0aW5ndWlzaCZuYnNwO2RpZmZlcmVudCZuYnNwO2Zs b3cmbmJzcDtJRHMuJm5ic3A7SSdkJm5ic3A7YXBwcmVjaWF0ZSZuYnNwO3lvdXImbmJzcDthZHZp Y2UuPGJyPjxicj4oMykmbmJzcDtJZiZuYnNwO3dlJm5ic3A7YXJlJm5ic3A7dG8mbmJzcDthbGxv dyZuYnNwO2ZvciZuYnNwO3NwZWNpZnlpbmcmbmJzcDt0aGUmbmJzcDsibG9naWNhbCZuYnNwO2dy b3VwaW5nJm5ic3A7b2YmbmJzcDtzb3VyY2UmbmJzcDthbmQvb3I8YnI+ZGVzdGluYXRpb24mbmJz cDtvYmplY3RzIiZuYnNwO2luJm5ic3A7wqc0LjYmbmJzcDsoZW1waGFzaXMmbmJzcDtvbiZuYnNw OyJhbmQvb3IiKSwmbmJzcDtidXQmbmJzcDt0aGUmbmJzcDtjb250ZXh0PGJyPmhlYWRlciZuYnNw O2Fsd2F5cyZuYnNwO2NvbnZleXMmbmJzcDtib3RoJm5ic3A7YSZuYnNwO3NvdXJjZSZuYnNwO2dy b3VwJm5ic3A7YW5kJm5ic3A7ZGVzdCZuYnNwO2dyb3VwJm5ic3A7ZmllbGQsJm5ic3A7ZG8mbmJz cDt3ZTxicj5uZWVkJm5ic3A7dG8mbmJzcDtyZXNlcnZlJm5ic3A7YSZuYnNwO2RlZGljYXRlZCZu YnNwO3ZhbHVlJm5ic3A7Zm9yJm5ic3A7Im5vJm5ic3A7Z3JvdXAmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO3NwZWNpZmllZCI/PGJyPjxicj5ZdWVodWEtMyZndDsmZ3Q7VmVyeSZuYnNwO2dvb2QmbmJz cDtvYnNlcnZhdGlvbi4mbmJzcDtTaGFsbCZuYnNwO3dlJm5ic3A7c3RhdGUmbmJzcDt0aGF0Jm5i c3A7aWYmbmJzcDt0aGVyZSZuYnNwO2lzJm5ic3A7Jm5ic3A7Jm5ic3A7Im5vJm5ic3A7Z3JvdXAm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO3NwZWNpZmllZCImbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtz b3VyY2UmbmJzcDtvciZuYnNwO2Rlc3QmbmJzcDtmaWVsZCwmbmJzcDt0aGUmbmJzcDtmaWVsZCZu YnNwO01VU1QmbmJzcDtiZSZuYnNwO3NlbnQmbmJzcDthcyZuYnNwO3plcm8mbmJzcDthbmQmbmJz cDtpZ25vcmVkJm5ic3A7b24mbmJzcDtyZWNlaXB0PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkNP TU1FTlQ6PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+PGJyPlNlY3Rpb24mbmJzcDsxPGJyPjxicj5UaGlz Jm5ic3A7ZG9jdW1lbnQmbmJzcDtkb2VzJm5ic3A7bm90Jm5ic3A7YWRkcmVzcyZuYnNwO21ldGFk YXRhJm5ic3A7dXNhZ2UsJm5ic3A7dXBkYXRpbmcvY2hhaW5pbmcmbmJzcDtvZjxicj5tZXRhZGF0 YSwmbmJzcDtvciZuYnNwO290aGVyJm5ic3A7U0ZQJm5ic3A7ZnVuY3Rpb25zLiZuYnNwOyZuYnNw O1Rob3NlJm5ic3A7dG9waWNzJm5ic3A7YXJlJm5ic3A7ZGVzY3JpYmVkJm5ic3A7aW48YnI+W1JG QzgzMDBdLjxicj48YnI+SSdtJm5ic3A7bm90Jm5ic3A7ZW50aXJlbHkmbmJzcDtzdXJlJm5ic3A7 d2hhdCZuYnNwO2lzJm5ic3A7bWVhbnQmbmJzcDtieSZuYnNwOyJjaGFpbmluZyZuYnNwO29mJm5i c3A7bWV0YWRhdGEiJm5ic3A7KHVubGVzczxicj5pdCdzJm5ic3A7anVzdCZuYnNwO2EmbmJzcDtz eW5vbnltJm5ic3A7Zm9yJm5ic3A7InVwZGF0aW5nJm5ic3A7b2YmbmJzcDttZXRhZGF0YSI/KSwm bmJzcDthbmQmbmJzcDtoYXZpbmcmbmJzcDtyZXZpZXdlZDxicj5hbGwmbmJzcDsxOCZuYnNwO2lu c3RhbmNlcyZuYnNwO29mJm5ic3A7ImNoYWluIiZuYnNwO2FuZCZuYnNwOzg4Jm5ic3A7aW5zdGFu Y2VzJm5ic3A7b2YmbmJzcDsibWV0YWRhdGEiJm5ic3A7aW4mbmJzcDtSRkMmbmJzcDs4MzAwLDxi cj5JJm5ic3A7YW0mbmJzcDtub3QmbmJzcDtzdXJlJm5ic3A7d2hpY2gmbmJzcDtwYXJ0Jm5ic3A7 eW91J3JlJm5ic3A7aW50ZW5kaW5nJm5ic3A7dG8mbmJzcDtyZWZlciZuYnNwO3RvJm5ic3A7Ynkm bmJzcDtpdC4mbmJzcDsmbmJzcDtDb3VsZCZuYnNwO3lvdTxicj5wbGVhc2UmbmJzcDtwb2ludCZu YnNwO3RvJm5ic3A7YSZuYnNwO21vcmUmbmJzcDtzcGVjaWZpYyZuYnNwO3BhcnQmbmJzcDtvZiZu YnNwO1JGQyZuYnNwOzgzMDAmbmJzcDsoYXQmbmJzcDtsZWFzdCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO2VtYWlsPGJyPnRocmVhZCZuYnNwO2ZvciZuYnNwO25vdywmbmJzcDtub3QmbmJzcDtuZWNl c3NhcmlseSZuYnNwO2luJm5ic3A7YSZuYnNwO2RvY3VtZW50Jm5ic3A7dXBkYXRlKT88YnI+PGJy Pll1ZWh1YS00Jmd0OyZndDsmbmJzcDtSRkM4MzAwJm5ic3A7ZG9lc24ndCZuYnNwO3VzZSZuYnNw O+KAnGNoYWlu4oCddG8mbmJzcDtkaXNjcmliZSZuYnNwO211bHRpcGxlJm5ic3A7bWV0YWRhdGEu PGJyPml0Jm5ic3A7bWVudGlvbnMmbmJzcDsiSWYmbmJzcDttdWx0aXBsZSZuYnNwO21hbmRhdG9y eS10by1wcm9jZXNzJm5ic3A7Q29udGV4dCZuYnNwO0hlYWRlcnMmbmJzcDthcmUmbmJzcDtyZXF1 aXJlZCZuYnNwO2ZvciZuYnNwO2EmbmJzcDsmbmJzcDsmbmJzcDtnaXZlbiZuYnNwO1NGUCImbmJz cDthbmQmbmJzcDsiSWYmbmJzcDttdWx0aXBsZSZuYnNwO2luc3RhbmNlcyZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2FtZSZuYnNwO21ldGFkYXRhJm5ic3A7YXJlJm5ic3A7aW5jbHVkZWQmbmJzcDtp biZuYnNwO2FuJm5ic3A7TlNIJm5ic3A7Jm5ic3A7Jm5ic3A7cGFja2V0IiZuYnNwO2luJm5ic3A7 UkZDODMwMCZuYnNwO3NlY3Rpb24mbmJzcDsyLjUuMTxicj5GdXJ0aGVyJm5ic3A7Y29tbWVudHMm bmJzcDthcmUmbmJzcDt3ZWxjb21lPGJyPjxicj48YnI+U2VjdGlvbiZuYnNwOzQuMTxicj48YnI+ SSZuYnNwO3N1Z2dlc3QmbmJzcDtwdXR0aW5nJm5ic3A7YSZuYnNwO2NvbnRleHQmbmJzcDsoZm9y Z2l2ZSZuYnNwO3RoZSZuYnNwO3B1bikmbmJzcDtpbmRpY2F0b3ImbmJzcDtpbiZuYnNwO3RoZSZu YnNwO2ZpZ3VyZTxicj5sZWdlbmRzLCZuYnNwO2UuZy4sJm5ic3A7IkZpZ3VyZSZuYnNwOzQ6Jm5i c3A7Rm9yd2FyZGluZyZuYnNwO0NvbnRleHQmbmJzcDstJm5ic3A7MiZuYnNwOyhRaW5RKSIuJm5i c3A7Jm5ic3A7VGhlPGJyPmluZm9ybWF0aW9uJm5ic3A7aXMmbmJzcDthbHJlYWR5Jm5ic3A7YXZh aWxhYmxlJm5ic3A7ZWxzZXdoZXJlLCZuYnNwO2J1dCZuYnNwO2hhdmluZyZuYnNwO2l0Jm5ic3A7 aW4mbmJzcDt0aGUmbmJzcDtjYXB0aW9uPGJyPmhlbHBzJm5ic3A7Zm9jdXMmbmJzcDt0aGUmbmJz cDtyZWFkZXImbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2ltcG9ydGFudC9yZWxldmFudCZuYnNwO3Bh cnQmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2ZpZ3VyZS48YnI+PGJyPll1ZWh1YS01Jmd0OyZndDsm bmJzcDtBY2NlcHRlZCwmbmJzcDt3aWxsJm5ic3A7dXBkYXRlJm5ic3A7dG8mbmJzcDt2ZXIxMDxi cj48YnI+U2VjdGlvbiZuYnNwOzQuMzxicj48YnI+SXQmbmJzcDttaWdodCZuYnNwO2JlJm5ic3A7 aW50ZXJlc3RpbmcmbmJzcDt0byZuYnNwO3NheSZuYnNwO3NvbWV0aGluZyZuYnNwO2Fib3V0Jm5i c3A7d2hlbiZuYnNwO3RoZSZuYnNwO1NQSSZuYnNwO2l0c2VsZjxicj5zdWZmaWNlcyZuYnNwO3Rv Jm5ic3A7aWRlbnRpZnkmbmJzcDt0aGUmbmJzcDtpbmdyZXNzJm5ic3A7bm9kZSZuYnNwO3ZzLiZu YnNwO3doZW4mbmJzcDt0aGlzJm5ic3A7bWV0YWRhdGEmbmJzcDtjb250ZXh0PGJyPmhlYWRlciZu YnNwO2lzJm5ic3A7bmVlZGVkLjxicj48YnI+Tm9kZSZuYnNwO0lEOiZuYnNwO1JlcHJlc2VudHMm bmJzcDthbiZuYnNwO29wYXF1ZSZuYnNwO3ZhbHVlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmdy ZXNzJm5ic3A7bmV0d29yayZuYnNwO25vZGU8YnI+SUQuJm5ic3A7Jm5ic3A7VGhlJm5ic3A7c3Ry dWN0dXJlJm5ic3A7YW5kJm5ic3A7c2VtYW50aWNzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Zmll bGQmbmJzcDthcmUmbmJzcDtkZXBsb3ltZW50PGJyPnNwZWNpZmljLiZuYnNwOyZuYnNwO0ZvciZu YnNwO2V4YW1wbGUsJm5ic3A7Tm9kZSZuYnNwO0lEJm5ic3A7bWF5Jm5ic3A7YmUmbmJzcDthJm5i c3A7NCZuYnNwO2J5dGVzJm5ic3A7SVB2NCZuYnNwO2FkZHJlc3MmbmJzcDtOb2RlPGJyPklELCZu YnNwO29yJm5ic3A7YSZuYnNwOzE2Jm5ic3A7Ynl0ZXMmbmJzcDtJUHY2Jm5ic3A7YWRkcmVzcyZu YnNwO05vZGUmbmJzcDtJRCwmbmJzcDtvciZuYnNwO2EmbmJzcDs2Jm5ic3A7Ynl0ZXMmbmJzcDtN QUMmbmJzcDthZGRyZXNzLDxicj5vciZuYnNwOzgmbmJzcDtieXRlcyZuYnNwO01BQyZuYnNwO2Fk ZHJlc3MmbmJzcDsoRVVJLTY0KSwmbmJzcDtldGMsLjxicj48YnI+VGhlcmUmbmJzcDtzZWVtcyZu YnNwO3RvJm5ic3A7YmUmbmJzcDtzb21lJm5ic3A7ZGlzc29uYW5jZSZuYnNwO2JldHdlZW4mbmJz cDtzYXlpbmcmbmJzcDt0aGlzJm5ic3A7ZmllbGQmbmJzcDtpcyZuYnNwOyJhbjxicj5vcGFxdWUm bmJzcDt2YWx1ZSImbmJzcDthbmQmbmJzcDthbHNvJm5ic3A7c2F5aW5nJm5ic3A7dGhhdCZuYnNw O2l0Jm5ic3A7bWlnaHQmbmJzcDtiZSZuYnNwO2FuJm5ic3A7SVAmbmJzcDtvciZuYnNwO01BQyZu YnNwO2FkZHJlc3MuJm5ic3A7Jm5ic3A7SW48YnI+dGhlJm5ic3A7dmVpbiZuYnNwO29mJm5ic3A7 RnJhbmNlc2NhJ3MmbmJzcDtEaXNjdXNzJm5ic3A7cG9pbnQsJm5ic3A7SSZuYnNwO2Rvbid0Jm5i c3A7dGhpbmsmbmJzcDt3ZSZuYnNwO2NhbiZuYnNwO2hhdmU8YnI+aW50ZXJvcGVyYWJpbGl0eSZu YnNwO2lmJm5ic3A7dGhlJm5ic3A7TlNIJm5ic3A7aW1wbGVtZW50YXRpb24mbmJzcDtpcyZuYnNw O2V4cGVjdGVkJm5ic3A7dG8mbmJzcDtwcm9jZXNzJm5ic3A7dGhpczxicj5hcyZuYnNwO0lQL01B QyZuYnNwO2FkZHJlc3MmbmJzcDtpbmZvcm1hdGlvbiZuYnNwOyhhcyZuYnNwO29wcG9zZWQmbmJz cDt0byZuYnNwO2p1c3QmbmJzcDthbiZuYnNwO29wYXF1ZSZuYnNwO2lkZW50aWZpZXIpLjxicj48 YnI+WXVlaHVhLTYmZ3Q7Jmd0OyZuYnNwO2l0Jm5ic3A7aGFzJm5ic3A7cmVsYXRpb24mbmJzcDt0 byZuYnNwOzxicj48YnI+U2VjdGlvbiZuYnNwOzguMjxicj48YnI+VVJMcyZuYnNwO2ZvciZuYnNw O1tHUk9VUEJBU0VEUE9MSUNZXSZuYnNwO2FuZCZuYnNwO1tHUk9VUFBPTElDWV0mbmJzcDt3b3Vs ZCZuYnNwO2JlJm5ic3A7aGVscGZ1bC48YnI+WXVlaHVhLTcmZ3Q7Jmd0OyZuYnNwO0FjY2VwdGVk LCZuYnNwO3dpbGwmbmJzcDtmaXgmbmJzcDt0aGUmbmJzcDtwcm9ibGVtJm5ic3A7dG8mbmJzcDt2 ZXIxMDxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPnNmYyZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPnNmY0BpZXRmLm9yZzxicj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzxicj48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Jan 25 18:06:18 2022 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46F3A1B97; Tue, 25 Jan 2022 18:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <164316277605.11600.15074849542924109335@ietfa.amsl.com> Date: Tue, 25 Jan 2022 18:06:16 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 02:06:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header Metadata Type 2 Variable-Length Context Headers Authors : Yuehua Wei Uri Elzur Sumandra Majee Carlos Pignataro Donald E. Eastlake Filename : draft-ietf-sfc-nsh-tlv-12.txt Pages : 14 Date : 2022-01-25 Abstract: Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Tue Jan 25 18:15:15 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD3F3A1C05; Tue, 25 Jan 2022 18:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1idgbYq2xCs; Tue, 25 Jan 2022 18:15:09 -0800 (PST) Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10593A1C03; Tue, 25 Jan 2022 18:15:08 -0800 (PST) Received: from mse-eu.zte.com.cn (unknown [10.35.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4Jk6k55hZczB5mXl; Wed, 26 Jan 2022 10:14:53 +0800 (CST) Received: from dgapp02.zte.com.cn ([10.35.13.17]) by mse-eu.zte.com.cn with SMTP id 20Q2Emif033913; Wed, 26 Jan 2022 10:14:48 +0800 (GMT-8) (envelope-from wei.yuehua@zte.com.cn) Received: from mapi (dgapp01[null]) by mapi (Zmail) with MAPI id mid1; Wed, 26 Jan 2022 10:14:49 +0800 (CST) Date: Wed, 26 Jan 2022 10:14:49 +0800 (CST) X-Zmail-TransId: 2af961f0ae9920188188 X-Mailer: Zmail v1.0 Message-ID: <202201261014495204767@zte.com.cn> In-Reply-To: References: 163818356894.9882.14504113673742570287@ietfa.amsl.com, f511d5ec-a840-52bc-ec9a-da8b54403781@nokia.com Mime-Version: 1.0 From: To: , Cc: , , , , Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-eu.zte.com.cn 20Q2Emif033913 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at 10-35-8-63 with ID 61F0AE9D.000 by FangMail milter! X-FangMail-Envelope: 1643163293/4Jk6k55hZczB5mXl/61F0AE9D.000/10.35.13.51/[10.35.13.51]/mse-eu.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 61F0AE9D.000/4Jk6k55hZczB5mXl Archived-At: Subject: Re: [sfc] =?utf-8?q?Francesca_Palombini=27s_Discuss_on_draft-ietf-sf?= =?utf-8?q?c-nsh-tlv-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 02:15:14 -0000 Dear Martin and Francesca, Combine with your comments and suggestions, I uploaded a ver12 to reflected the updates. I appreciate your further review. The link of differences is : https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-12.txt Best Regards, Yuehua Wei M: +86 13851460269 E: wei.yuehua@zte.com.cn ------------------原始邮件------------------ 发件人：MartinVigoureux 收件人：Francesca Palombini;The IESG; 抄送人：draft-ietf-sfc-nsh-tlv@ietf.org;sfc-chairs@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; 日 期 ：2021年12月02日 20:31 主 题 ：Re: [sfc] Francesca Palombini's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) Hello Francesca, thank you for your review. Please see inline. I invite the authors to share their views. -m Le 2021-11-29 à 11:59, Francesca Palombini via Datatracker a écrit : > Francesca Palombini has entered the following ballot position for > draft-ietf-sfc-nsh-tlv-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work on this document. > > I have some comments, mostly having to do with clarifications and improvement > of text for readability. I'd like answers to two main points: first - I believe > the lack of normative references to the documents that define the fields this > document registers into IANA is important enough to warrant some discussion. Not sure whether you are asking for Normative references in 4.1 or in 4.2 to 4.6, or both. I'm not sure Normative references would be appropriate for the metadata objects (from 4.2 to 4.6) this document defines. All of them are opaque, and under the control of the operator. Informative references (like in 4.6) would be a plus though. I'm sure the authors can add Normative references to 4.1 too. > Second - I'd like some clarification about interoperability. More details below. It would be great if you could elaborate a bit on the interoperability issues you foresee. Personally, I can envisage misconfiguration driven problems, but not interop ones. > > Francesca > > 1. ----- > > Tenant ID: Represents an opaque value pointing to Orchestration > system-generated tenant identifier. The structure and semantics > of this field are deployment specific. > > FP: I am worried about interoperability, as the field is defined as deployment > specific. Could you clarify why you don't think this is an issue? Also, please > add a normative reference to the section and document defining tenant > identification. > > 2. ---- > > Section 4.3 > > FP: Same comment as above for Node ID: please add a reference and explain > interoperability, as this is defined as deployment specific. > > 3. ----- > > Sections 4.4, 4.5 > > FP: I do think these fields need references to the documents they are defined > in. (I am aware section 2.1 and the normative references should help, but I > think it would be much clearer to have direct links to the right place in the > text.) For Flow ID, if I understand correctly, this document defines it high > level and gives examples of what value it can take. I would clarify that in the > first paragraph of the section (as you do for Section 4.6), instead of having > the references only in the "Length" paragraph. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 4. ----- > > Section 4.1 > > FP: I think it would be better to have the sentence "Reserved bits MUST be sent > as zero and ignored on receipt." only once, rather than repeat for each > context. What is missing instead is the number of bits that are reserved for > each CT. I know that it can be extracted from the figure or from the value of > the Forwarding Context field, but I believe figures should be complemented by > clear written text. Additionally, to improve readability, references should be > added for the forwarding context where they are missing: VLAN identifier, MPLS > VPN label‚ VNI. > > > > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jan 26 07:39:07 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49F3A14DB; Wed, 26 Jan 2022 07:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.097 X-Spam-Level: X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoIgMTRcKMTR; Wed, 26 Jan 2022 07:38:56 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEC73A155D; Wed, 26 Jan 2022 07:38:20 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id w5so15077886vke.12; Wed, 26 Jan 2022 07:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=49HsIgJNd6k29EM7JAV/zUMhtfitOFlfoV7+oFDY7xw=; b=oXKVSLfpVCzsf5NdwZ9tSlXJL6uDnWDYP4Ya5aRXT2OTE30hOY6yQRmKlWT4oIErbM G1k14vpmL0saRaNOdeda1n0+uAymgr8LlS4L1XHswqgvdCqTH/z2GLzfmwyTL0vD0aUU iyqcfipB8t3WhndpHGJonndfE5ijKy+naND1Xv4apmxLJhHCaIUSKj9hurJ+e7e2hnQD zly7DLur1kL51fve47qwVgzCJVU10OO1Jfg0f0G7dTxMec3ukMZDg8xDNWLB2ykqcJIt kETTv6YUQOZT4n6GXzipyDtPSUa9SLdY3kqNShra1VYHxtkk5SLqiv1yo/Vj/5qfjLCW 7LKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=49HsIgJNd6k29EM7JAV/zUMhtfitOFlfoV7+oFDY7xw=; b=bhf9Q+6u/daha7feFVMmNFi5KeV1hUk0moegjcrA5pJY7DVlSq6tDO6MnpGaJ84x2G /8ZKKyaLei1CX7abZtCwwUmdctKFi6jhxqy2RtpxWWcvvMD3eTnTx8IVAeMriNtJuTJh jX7qUv3CERHD5Ymz+xHCevC0h3/T021tghfORfkR15oqEUrBPeRWXjUT9kvD3h/iD1z/ /vb66T6mpdr+csAf7WNqrmPA7bSKW4yXxhsbJxFjd5VcbCLBEuFmMYRUjGTmJmPVtovg Ym4f2jjMHa0TExpfSCgJwsf/nW22zPMAwtL1hATWQ76Qdw91ZoZDw98dxt0FHcUlw1Bz WIzw== X-Gm-Message-State: AOAM531n0/Wt3xVBVmu/PFhiRGebHjBDuGB6UAZPgXFAWzJ87ER3I3wv 78VKtMSwbT818sZkyuvlIEh42HJN09k8XC3gJrA= X-Google-Smtp-Source: ABdhPJzDfbVyHKq8Rkx80XMjz+C3ipOd/EsijS1FvnH1xwyPzm/wU+JFbH4nD36HHfLlFOQq3boljUCYXZduc+DUTwg= X-Received: by 2002:a05:6122:223:: with SMTP id e3mr5001412vko.18.1643211497967; Wed, 26 Jan 2022 07:38:17 -0800 (PST) MIME-Version: 1.0 References: <202112031702237499021@zte.com.cn> <27638_1638527561_61A9F249_27638_478_1_787AE7BB302AE849A7480A190F8B93303545E945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <21793_1638775114_61ADB94A_21793_201_1_787AE7BB302AE849A7480A190F8B93303545F530@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <21793_1638775114_61ADB94A_21793_201_1_787AE7BB302AE849A7480A190F8B93303545F530@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: "Murray S. Kucherawy" Date: Wed, 26 Jan 2022 07:38:06 -0800 Message-ID: To: mohamed.boucadair@orange.com Cc: Martin Vigoureux , "wei.yuehua@zte.com.cn" , "draft-ietf-sfc-nsh-tlv@ietf.org" , "sfc-chairs@ietf.org" , "iesg@ietf.org" , "sfc@ietf.org" , "gregimirsky@gmail.com" Content-Type: multipart/alternative; boundary="000000000000a0960b05d67dfd84" Archived-At: Subject: Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2022 15:39:01 -0000 --000000000000a0960b05d67dfd84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, The new version posted yesterday fixes the original problem but I think it has a new one. It now says: IANA is requested to assign the following types (Table 1) from the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry available at [IANA-NSH-MD2 ].These Metadata Types only apply when the Metadata Class is 0x000 (IETF Base NSH MD Class) I would argue that the trailing sentence is not part of the instructions to IANA, and should be presented elsewhere in the document. It's information for implementers, not for IANA. -MSK On Sun, Dec 5, 2021 at 11:18 PM wrote: > Hi Martin, > > I think the confusion can be clarified if we read this part from RFC8300: > > The Type values within the IETF Base NSH MD Class, i.e., when the MD > Class is set to 0x0000 (see Section 9.1.4), are the Types owned by > the IETF. Per this document, IANA has created a registry for the > Type values for the IETF Base NSH MD Class called the "NSH IETF- > Assigned Optional Variable-Length Metadata Types" registry, as > specified in Section 2.5.1. > > The reasoning for calling out 0x0000 under the IANA section is to save a > check for IANA to make sure that the requested codepoints are for this > specific MD Class. > > Anyway, I think that the current text should be fixed: > > =3D=3D > IANA is requested to assign the following types from the "NSH IETF- > Assigned Optional Variable-Length Metadata Types" registry available > at [IANA-NSH-MD2]: > > This document defines the following new values (Table 1) in the > Network Service Header (NSH) metadata context Type registry: > =3D=3D > > The second sentence should be deleted. It is this part which is confusing= . > > Cheers, > Med > > > -----Message d'origine----- > > De : Martin Vigoureux > > Envoy=C3=A9 : vendredi 3 d=C3=A9cembre 2021 17:53 > > =C3=80 : BOUCADAIR Mohamed INNOV/NET ; > > wei.yuehua@zte.com.cn; superuser@gmail.com > > Cc : draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org; iesg@ietf.or= g > ; > > sfc@ietf.org; gregimirsky@gmail.com > > Objet : Re: [sfc] Murray Kucherawy's Discuss on > draft-ietf-sfc-nsh-tlv-09: > > (with DISCUSS and COMMENT) > > > > Med, > > > > I don't oppose to that but this is what confused Murray, so introducing > it > > back as is may not be the best thing to do. Also, I don't think this is > > relevant for the registration of the new values. The body of document i= s > > very explicit that they are for MD Class 0x0000. > > > > -m > > > > Le 2021-12-03 =C3=A0 11:32, mohamed.boucadair@orange.com a =C3=A9crit : > > > Hi Yuehua, > > > > > > For Murray's DISCUSS point, I would proceed with this change rather > than > > the one in -10: > > > > > > > > > =3D=3D=3D=3D > > > OLD: > > > IANA is requested to assign the following types from the "NSH > > IETF- > > > Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > > Base > > > NSH MD Class) registry available at [IANA-NSH-MD2]: > > > > > > This document defines the following new values (Table 1) in the > > > Network Service Header (NSH) metadata context Type registry: > > > > > > NEW: > > > IANA is requested to assign the following types from the "NSH > > IETF- > > > Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > > Base > > > NSH MD Class) registry available at [IANA-NSH-MD2]: > > > > > > =3D=3D=3D > > > > > > Please note that the assigned values should be bound to the MD Class > > 0x0000. > > > > > > Cheers, > > > Med > > > > > >> -----Message d'origine----- > > >> De : sfc De la part de wei.yuehua@zte.com.cn > > >> Envoy=C3=A9 : vendredi 3 d=C3=A9cembre 2021 10:02 > > >> =C3=80 : martin.vigoureux@nokia.com; superuser@gmail.com > > >> Cc : draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org; > > iesg@ietf.org; > > >> sfc@ietf.org; gregimirsky@gmail.com > > >> Objet : Re: [sfc] Murray Kucherawy's Discuss on > draft-ietf-sfc-nsh-tlv- > > 09: > > >> (with DISCUSS and COMMENT) > > >> > > >> Dear Martin and Murray, > > >> I appreciate your comments. > > >> Please see inline with Yuehua-n>> > > >> > > >> Best Regards, > > >> Yuehua Wei > > >> ZTE Corporation > > >> ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6--------------= ---- > > >> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AMartinVigoureux > > >> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AMurray Kucherawy;The IESG; > > >> =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Adraft-ietf-sfc-nsh-tlv@ietf.org;= sfc- > > >> chairs@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; > > >> =E6=97=A5 =E6=9C=9F =EF=BC=9A2021=E5=B9=B412=E6=9C=8802=E6=97=A5 18:= 47 > > >> =E4=B8=BB =E9=A2=98 =EF=BC=9ARe: Murray Kucherawy's Discuss on draft= -ietf-sfc-nsh-tlv-09: > > (with > > >> DISCUSS and COMMENT) Hello Murray Le 2021-12-02 =C3=A0 7:34, Murray > > Kucherawy > > >> via Datatracker a =C3=A9crit : > > >>> Murray Kucherawy has entered the following ballot position for > > >>> draft-ietf-sfc-nsh-tlv-09: Discuss > > >>> > > >>> When responding, please keep the subject line intact and reply to a= ll > > >>> email addresses included in the To and CC lines. (Feel free to cut > > >>> this introductory paragraph, however.) > > >>> > > >>> > > >>> Please refer to > > >>> https://www.ietf.org/blog/handling-iesg-ballot-positions/ > > >>> for more information about how to handle DISCUSS and COMMENT > > positions. > > >>> > > >>> > > >>> The document, along with other ballot positions, can be found here: > > >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ > > >>> > > >>> > > >>> > > >>> > ---------------------------------------------------------------------- > > >>> DISCUSS: > > >>> > ---------------------------------------------------------------------- > > >>> > > >>> I'm having trouble understanding the first thing you've got in > Section > > >>> 7. You have one table of assignments to make, but you're referenci= ng > > >>> two distinct sub-registries under "Network Service Header (NSH) > > >>> Parameters", namely "NSH MD Class" and "NSH IETF-Assigned Optional > > >>> Variable-Length Metadata Types". There doesn't appear to be a > > >>> "metadata context type registry". I think this change clarifies wh= at > > >> you mean, but please tell me if I'm wrong: > > >>> > > >>> OLD: > > >>> > > >>> IANA is requested to assign the following types from the "NSH > > IETF- > > >>> Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > > Base > > >>> NSH MD Class) registry available at [IANA-NSH-MD2]: > > >>> > > >>> This document defines the following new values (Table 1) in th= e > > >>> Network Service Header (NSH) metadata context Type registry: > > >>> > > >>> NEW: > > >>> > > >>> IANA is requested to assign the following types (Table 1) from > > the > > >> IETF > > >>> Review range in the "NSH MD Class" sub-registry of the "Networ= k > > >> Service > > >>> Header (NSH) Parameters" registry: > > >> Thanks for catching this. This is indeed a bit confusing but the > intent > > of > > >> the draft doesn't match with your suggestion: > > >> The new metadata defined by this document shall be registered in "NS= H > > >> IETF-Assigned Optional Variable-Length Metadata Types". > > >> So each object will have its own type but all will be of the same MD > > Class > > >> (0x0000, which is the only value registered by 8300, and which is in > > the > > >> "NSH MD Class" registry). > > >> So I think the new text should simply be: > > >> IANA is requested to assign the following types from the "NSH IETF- > > >> Assigned Optional Variable-Length Metadata Types" registry available > at > > >> [IANA-NSH-MD2]: > > >> -m > > >> > > >> Yuehua-1>>Will delete "(0x0000 IETF Base NSH MD Class)" which is > > >> Yuehua-1>>confusing and not needed here > > >> > > >>> > > >>> > > >>> > ---------------------------------------------------------------------- > > >>> COMMENT: > > >>> > ---------------------------------------------------------------------- > > >>> > > >>> Thank you for a well done shepherd writeup. > > >>> > > >>> I support Ben's DISCUSS position, particularly the first point. > > >> > > >> Yuehua-2>>Will resolve Ben's comments in the email thread reply to > > Ben's > > >> > > >>> A suggestion on organization: I think what you have as the top of > > >>> Section 7 should be a subsection (e.g., 7.1), and then the other > > >> subsections moved down. > > >>> It doesn't make sense to me to have these registrations be dominant > > >>> over the others; they're all just a set of IANA actions. > > >> > > >> Yuehua-3>>Accepted. will update to ver10 > > >> > > >>> I have the same comment as Francesca about Section 4.1. > > >> > > >> Yuehua-4>>Will resolve Francesca's comment in the email thread reply > to > > >> Yuehua-4>>Francesca's > > >> > > >>> > > >>> > > >>> > > >>> > > >> > > >> _______________________________________________ > > >> sfc mailing list > > >> sfc@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sfc > > > > > > > > > _________________________________________________________________________= _ > > _______________________________________________ > > > > > > 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 ave= z > > 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, > > > Orange decline toute responsabilite si ce message a ete altere, defor= me > > ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or privileg= ed > > 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 an= d > > delete 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. > > > > > > _________________________________________________________________________= ________________________________________________ > > 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, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > 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, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > --000000000000a0960b05d67dfd84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The new version posted yest= erday fixes the original problem but I think it has a new one.=C2=A0 It now= says:

   IANA is=
 requested to assign the following types (Table 1) from the
   "NSH IETF- Assigned Optional Variable-Length Metadata Types" r=
egistry
   available at [IANA-NSH-MD2].These Metadata Types o=
nly apply when the
   Metadata Class is 0x000 (IETF Base NSH MD Class)

I would argue that the trailing sentence is not part of the instruc= tions to IANA, and should be presented elsewhere in the document.=C2=A0 It&= #39;s information for implementers, not for IANA.

<= div>-MSK


On Sun, Dec 5, 2021 at 11:18 PM <mohamed.boucadair@orange.com> wrote:<= br>
Hi Martin,

I think the confusion can be clarified if we read this part from RFC8300:
=C2=A0 =C2=A0The Type values within the IETF Base NSH MD Class, i.e., when = the MD
=C2=A0 =C2=A0Class is set to 0x0000 (see Section 9.1.4), are the Types owne= d by
=C2=A0 =C2=A0the IETF.=C2=A0 Per this document, IANA has created a registry= for the
=C2=A0 =C2=A0Type values for the IETF Base NSH MD Class called the "NS= H IETF-
=C2=A0 =C2=A0Assigned Optional Variable-Length Metadata Types" registr= y, as
=C2=A0 =C2=A0specified in Section 2.5.1.

The reasoning for calling out 0x0000 under the IANA section is to save a ch= eck for IANA to make sure that the requested codepoints are for this specif= ic MD Class.

Anyway, I think that the current text should be fixed:

=3D=3D
=C2=A0 =C2=A0IANA is requested to assign the following types from the "= ;NSH IETF-
=C2=A0 =C2=A0Assigned Optional Variable-Length Metadata Types" registr= y available
=C2=A0 =C2=A0at [IANA-NSH-MD2]:

=C2=A0 =C2=A0This document defines the following new values (Table 1) in th= e
=C2=A0 =C2=A0Network Service Header (NSH) metadata context Type registry: =3D=3D

The second sentence should be deleted. It is this part which is confusing.<= br>
Cheers,
Med

> -----Message d'origine-----
> De=C2=A0: Martin Vigoureux <martin.vigoureux@nokia.com>
> Envoy=C3=A9=C2=A0: vendredi 3 d=C3=A9cembre 2021 17:53
> =C3=80=C2=A0: BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com&= gt;;
> wei.yuehua@= zte.com.cn; su= peruser@gmail.com
> Cc=C2=A0: draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org; iesg@ietf.org;
> sfc@ietf.org; gregimirsky@gmail.= com
> Objet=C2=A0: Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sf= c-nsh-tlv-09:
> (with DISCUSS and COMMENT)
>
> Med,
>
> I don't oppose to that but this is what confused Murray, so introd= ucing it
> back as is may not be the best thing to do. Also, I don't think th= is is
> relevant for the registration of the new values. The body of document = is
> very explicit that they are for MD Class 0x0000.
>
> -m
>
> Le 2021-12-03 =C3=A0 11:32, mohamed.boucadair@orange.com a =C3=A9crit=C2=A0= :
> > Hi Yuehua,
> >
> > For Murray's DISCUSS point, I would proceed with this change = rather than
> the one in -10:
> >
> >
> > =3D=3D=3D=3D
> >=C2=A0 =C2=A0OLD:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0IANA is requested to assign the followi= ng types from the "NSH
> IETF-
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Assigned Optional Variable-Length Metad= ata Types" (0x0000 IETF
> Base
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0NSH MD Class) registry available at [IA= NA-NSH-MD2]:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the following new= values (Table 1) in the
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Network Service Header (NSH) metadata c= ontext Type registry:
> >
> >=C2=A0 =C2=A0NEW:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0IANA is requested to assign the followi= ng types from the "NSH
> IETF-
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Assigned Optional Variable-Length Metad= ata Types" (0x0000 IETF
> Base
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0NSH MD Class) registry available at [IA= NA-NSH-MD2]:
> >
> > =3D=3D=3D
> >
> > Please note that the assigned values should be bound to the MD Cl= ass
> 0x0000.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De=C2=A0: sfc <sfc-bounces@ietf.org> De la part de wei.yuehua@zte.com.cn
> >> Envoy=C3=A9=C2=A0: vendredi 3 d=C3=A9cembre 2021 10:02
> >> =C3=80=C2=A0: martin.vigoureux@nokia.com; superuser@gmail.com
> >> Cc=C2=A0: draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org;
> iesg@ietf.org;<= br> > >> sfc@ietf.or= g; gregimirs= ky@gmail.com
> >> Objet=C2=A0: Re: [sfc] Murray Kucherawy's Discuss on draf= t-ietf-sfc-nsh-tlv-
> 09:
> >> (with DISCUSS and COMMENT)
> >>
> >> Dear Martin and Murray,
> >> I appreciate your comments.
> >> Please see inline with Yuehua-n>>
> >>
> >> Best Regards,
> >> Yuehua Wei
> >> ZTE Corporation
> >> ------------------=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-------= -----------
> >> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AMartinVigoureux
> >> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AMurray Kucherawy;The IESG= ;
> >> =E6=8A=84=E9=80=81=E4=BA=BA=EF=BC=9Adraft-ietf-sfc-nsh-tlv@ietf.org= ;sfc-
> >> chairs@i= etf.org;sfc@ietf.org<= /a>;gregimirsky@= gmail.com;
> >> =E6=97=A5 =E6=9C=9F =EF=BC=9A2021=E5=B9=B412=E6=9C=8802=E6=97= =A5 18:47
> >> =E4=B8=BB =E9=A2=98 =EF=BC=9ARe: Murray Kucherawy's Discu= ss on draft-ietf-sfc-nsh-tlv-09:
> (with
> >> DISCUSS and COMMENT) Hello Murray Le 2021-12-02 =C3=A0 7:34, = Murray
> Kucherawy
> >> via Datatracker a =C3=A9crit :
> >>> Murray Kucherawy has entered the following ballot positio= n for
> >>> draft-ietf-sfc-nsh-tlv-09: Discuss
> >>>
> >>> When responding, please keep the subject line intact and = reply to all
> >>> email addresses included in the To and CC lines. (Feel fr= ee to cut
> >>> this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> https://www.ietf.org/blog= /handling-iesg-ballot-positions/
> >>> for more information about how to handle DISCUSS and COMM= ENT
> positions.
> >>>
> >>>
> >>> The document, along with other ballot positions, can be f= ound here:
> >>> https://datatracker.ietf.o= rg/doc/draft-ietf-sfc-nsh-tlv/
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------= -------------
> >>> DISCUSS:
> >>> ---------------------------------------------------------= -------------
> >>>
> >>> I'm having trouble understanding the first thing you&= #39;ve got in Section
> >>> 7.=C2=A0 You have one table of assignments to make, but y= ou're referencing
> >>> two distinct sub-registries under "Network Service H= eader (NSH)
> >>> Parameters", namely "NSH MD Class" and &qu= ot;NSH IETF-Assigned Optional
> >>> Variable-Length Metadata Types".=C2=A0 There doesn&#= 39;t appear to be a
> >>> "metadata context type registry".=C2=A0 I think= this change clarifies what
> >> you mean, but please tell me if I'm wrong:
> >>>
> >>> OLD:
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 IANA is requested to assign the follo= wing types from the "NSH
> IETF-
> >>>=C2=A0 =C2=A0 =C2=A0 Assigned Optional Variable-Length Met= adata Types" (0x0000 IETF
> Base
> >>>=C2=A0 =C2=A0 =C2=A0 NSH MD Class) registry available at [= IANA-NSH-MD2]:
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 This document defines the following n= ew values (Table 1) in the
> >>>=C2=A0 =C2=A0 =C2=A0 Network Service Header (NSH) metadata= context Type registry:
> >>>
> >>> NEW:
> >>>
> >>>=C2=A0 =C2=A0 =C2=A0 IANA is requested to assign the follo= wing types (Table 1) from
> the
> >> IETF
> >>>=C2=A0 =C2=A0 =C2=A0 Review range in the "NSH MD Clas= s" sub-registry of the "Network
> >> Service
> >>>=C2=A0 =C2=A0 =C2=A0 Header (NSH) Parameters" registr= y:
> >> Thanks for catching this. This is indeed a bit confusing but = the intent
> of
> >> the draft doesn't match with your suggestion:
> >> The new metadata defined by this document shall be registered= in "NSH
> >> IETF-Assigned Optional Variable-Length Metadata Types".<= br> > >> So each object will have its own type but all will be of the = same MD
> Class
> >> (0x0000, which is the only value registered by 8300, and whic= h is in
> the
> >> "NSH MD Class" registry).
> >> So I think the new text should simply be:
> >> IANA is requested to assign the following types from the &quo= t;NSH IETF-
> >> Assigned Optional Variable-Length Metadata Types" regist= ry available at
> >> [IANA-NSH-MD2]:
> >> -m
> >>
> >> Yuehua-1>>Will delete "(0x0000 IETF Base NSH MD Cl= ass)" which is
> >> Yuehua-1>>confusing and not needed here
> >>
> >>>
> >>>
> >>> ---------------------------------------------------------= -------------
> >>> COMMENT:
> >>> ---------------------------------------------------------= -------------
> >>>
> >>> Thank you for a well done shepherd writeup.
> >>>
> >>> I support Ben's DISCUSS position, particularly the fi= rst point.
> >>
> >> Yuehua-2>>Will resolve Ben's comments in the email = thread reply to
> Ben's
> >>
> >>> A suggestion on organization: I think what you have as th= e top of
> >>> Section 7 should be a subsection (e.g., 7.1), and then th= e other
> >> subsections moved down.
> >>> It doesn't make sense to me to have these registratio= ns be dominant
> >>> over the others; they're all just a set of IANA actio= ns.
> >>
> >> Yuehua-3>>Accepted. will update to ver10
> >>
> >>> I have the same comment as Francesca about Section 4.1. > >>
> >> Yuehua-4>>Will resolve Francesca's comment in the e= mail thread reply to
> >> Yuehua-4>>Francesca's
> >>
> >>>
> >>>
> >>>
> >>>
> >>
> >> _______________________________________________
> >> sfc mailing list
> >> sfc@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/sfc=
> >
> >
> ______________________________________________________________________= ____
> _______________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des information= s
> 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. L= es messages
> electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, d= eforme
> ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or priv= ileged
> information that may be protected by law;
> > they should not be distributed, used or copied without authorisat= ion.
> > If you have received this email in error, please notify the sende= r and
> delete 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.
> >

___________________________________________________________________________= ______________________________________________

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 message= s electroniques 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.

--000000000000a0960b05d67dfd84-- From nobody Wed Jan 26 19:33:50 2022 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC133A07AA; Wed, 26 Jan 2022 19:33:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <164325442806.23569.14622096662033958673@ietfa.amsl.com> Date: Wed, 26 Jan 2022 19:33:48 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-13.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 03:33:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header Metadata Type 2 Variable-Length Context Headers Authors : Yuehua Wei Uri Elzur Sumandra Majee Carlos Pignataro Donald E. Eastlake Filename : draft-ietf-sfc-nsh-tlv-13.txt Pages : 14 Date : 2022-01-26 Abstract: Service Function Chaining (SFC) uses the Network Service Header (NSH) (RFC 8300) to steer and provide context Metadata (MD) with each packet. Such Metadata can be of various Types including MD Type 2 variable length context headers. This document specifies several such context headers that can be used within a service function path. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-13 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Jan 26 19:36:12 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491433A07D9; Wed, 26 Jan 2022 19:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJWFP9PzCYbO; Wed, 26 Jan 2022 19:36:00 -0800 (PST) Received: from mxde.zte.com.cn (mxde.zte.com.cn [209.9.37.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1603A07D4; Wed, 26 Jan 2022 19:35:59 -0800 (PST) Received: from mse-eu.zte.com.cn (unknown [10.35.13.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxde.zte.com.cn (FangMail) with ESMTPS id 4JkmSy1r9wzB5mbP; Thu, 27 Jan 2022 11:35:46 +0800 (CST) Received: from dgapp02.zte.com.cn ([10.35.13.17]) by mse-eu.zte.com.cn with SMTP id 20R3Zf7r083881; Thu, 27 Jan 2022 11:35:41 +0800 (GMT-8) (envelope-from wei.yuehua@zte.com.cn) Received: from mapi (dgapp02[null]) by mapi (Zmail) with MAPI id mid1; Thu, 27 Jan 2022 11:35:42 +0800 (CST) Date: Thu, 27 Jan 2022 11:35:42 +0800 (CST) X-Zmail-TransId: 2afa61f2130ea80c58cb X-Mailer: Zmail v1.0 Message-ID: <202201271135424394081@zte.com.cn> In-Reply-To: References: 202112031702237499021@zte.com.cn, 27638_1638527561_61A9F249_27638_478_1_787AE7BB302AE849A7480A190F8B93303545E945@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, fbb959f3-978f-d0ac-f6f6-12be7bd75ee9@nokia.com, 21793_1638775114_61ADB94A_21793_201_1_787AE7BB302AE849A7480A190F8B93303545F530@OPEXCAUBMA2.corporate.adroot.infra.ftgroup, CAL0qLwby=VVM2cqis+nrPCky+umwok_W2SW6JpRTFJ2WrFSjnw@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , , , , , Content-Type: text/plain; charset="UTF-8" X-MAIL: mse-eu.zte.com.cn 20R3Zf7r083881 X-Fangmail-Gw-Spam-Type: 0 X-FangMail-Miltered: at 10-35-8-64 with ID 61F21312.000 by FangMail milter! X-FangMail-Envelope: 1643254546/4JkmSy1r9wzB5mbP/61F21312.000/10.35.13.51/[10.35.13.51]/mse-eu.zte.com.cn/ X-Fangmail-Anti-Spam-Filtered: true X-Fangmail-MID-QID: 61F21312.000/4JkmSy1r9wzB5mbP Archived-At: Subject: Re: [sfc] =?utf-8?q?Murray_Kucherawy=27s_Discuss_on_draft-ietf-sfc-n?= =?utf-8?q?sh-tlv-09=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 03:36:05 -0000 Hi Murray, Thank you for pointing it out. Fixed in the new version : https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ Best Regards, Yuehua Wei M: +86 13851460269 E: wei.yuehua@zte.com.cn ------------------原始邮件------------------ 发件人：MurrayS.Kucherawy 收件人：mohamed.boucadair@orange.com; 抄送人：Martin Vigoureux;魏月华00019655;draft-ietf-sfc-nsh-tlv@ietf.org;sfc-chairs@ietf.org;iesg@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; 日 期 ：2022年01月26日 23:38 主 题 ：Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT) Hi all, The new version posted yesterday fixes the original problem but I think it has a new one. It now says: IANA is requested to assign the following types (Table 1) from the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry available at [IANA-NSH-MD2].These Metadata Types only apply when the Metadata Class is 0x000 (IETF Base NSH MD Class) I would argue that the trailing sentence is not part of the instructions to IANA, and should be presented elsewhere in the document. It's information for implementers, not for IANA. -MSK On Sun, Dec 5, 2021 at 11:18 PM wrote: Hi Martin, I think the confusion can be clarified if we read this part from RFC8300: The Type values within the IETF Base NSH MD Class, i.e., when the MD Class is set to 0x0000 (see Section 9.1.4), are the Types owned by the IETF. Per this document, IANA has created a registry for the Type values for the IETF Base NSH MD Class called the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry, as specified in Section 2.5.1. The reasoning for calling out 0x0000 under the IANA section is to save a check for IANA to make sure that the requested codepoints are for this specific MD Class. Anyway, I think that the current text should be fixed: == IANA is requested to assign the following types from the "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry available at [IANA-NSH-MD2]: This document defines the following new values (Table 1) in the Network Service Header (NSH) metadata context Type registry: == The second sentence should be deleted. It is this part which is confusing. Cheers, Med > -----Message d'origine----- > De : Martin Vigoureux > Envoyé : vendredi 3 décembre 2021 17:53 > À : BOUCADAIR Mohamed INNOV/NET ; > wei.yuehua@zte.com.cn; superuser@gmail.com > Cc : draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org; iesg@ietf.org; > sfc@ietf.org; gregimirsky@gmail.com > Objet : Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: > (with DISCUSS and COMMENT) > > Med, > > I don't oppose to that but this is what confused Murray, so introducing it > back as is may not be the best thing to do. Also, I don't think this is > relevant for the registration of the new values. The body of document is > very explicit that they are for MD Class 0x0000. > > -m > > Le 2021-12-03 à 11:32, mohamed.boucadair@orange.com a écrit : > > Hi Yuehua, > > > > For Murray's DISCUSS point, I would proceed with this change rather than > the one in -10: > > > > > > ==== > > OLD: > > IANA is requested to assign the following types from the "NSH > IETF- > > Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > Base > > NSH MD Class) registry available at [IANA-NSH-MD2]: > > > > This document defines the following new values (Table 1) in the > > Network Service Header (NSH) metadata context Type registry: > > > > NEW: > > IANA is requested to assign the following types from the "NSH > IETF- > > Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > Base > > NSH MD Class) registry available at [IANA-NSH-MD2]: > > > > === > > > > Please note that the assigned values should be bound to the MD Class > 0x0000. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : sfc De la part de wei.yuehua@zte.com.cn > >> Envoyé : vendredi 3 décembre 2021 10:02 > >> À : martin.vigoureux@nokia.com; superuser@gmail.com > >> Cc : draft-ietf-sfc-nsh-tlv@ietf.org; sfc-chairs@ietf.org; > iesg@ietf.org; > >> sfc@ietf.org; gregimirsky@gmail.com > >> Objet : Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv- > 09: > >> (with DISCUSS and COMMENT) > >> > >> Dear Martin and Murray, > >> I appreciate your comments. > >> Please see inline with Yuehua-n>> > >> > >> Best Regards, > >> Yuehua Wei > >> ZTE Corporation > >> ------------------原始邮件------------------ > >> 发件人：MartinVigoureux > >> 收件人：Murray Kucherawy;The IESG; > >> 抄送人：draft-ietf-sfc-nsh-tlv@ietf.org;sfc- > >> chairs@ietf.org;sfc@ietf.org;gregimirsky@gmail.com; > >> 日 期 ：2021年12月02日 18:47 > >> 主 题 ：Re: Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: > (with > >> DISCUSS and COMMENT) Hello Murray Le 2021-12-02 à 7:34, Murray > Kucherawy > >> via Datatracker a écrit : > >>> Murray Kucherawy has entered the following ballot position for > >>> draft-ietf-sfc-nsh-tlv-09: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut > >>> this introductory paragraph, however.) > >>> > >>> > >>> Please refer to > >>> https://www.ietf.org/blog/handling-iesg-ballot-positions/ > >>> for more information about how to handle DISCUSS and COMMENT > positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> I'm having trouble understanding the first thing you've got in Section > >>> 7. You have one table of assignments to make, but you're referencing > >>> two distinct sub-registries under "Network Service Header (NSH) > >>> Parameters", namely "NSH MD Class" and "NSH IETF-Assigned Optional > >>> Variable-Length Metadata Types". There doesn't appear to be a > >>> "metadata context type registry". I think this change clarifies what > >> you mean, but please tell me if I'm wrong: > >>> > >>> OLD: > >>> > >>> IANA is requested to assign the following types from the "NSH > IETF- > >>> Assigned Optional Variable-Length Metadata Types" (0x0000 IETF > Base > >>> NSH MD Class) registry available at [IANA-NSH-MD2]: > >>> > >>> This document defines the following new values (Table 1) in the > >>> Network Service Header (NSH) metadata context Type registry: > >>> > >>> NEW: > >>> > >>> IANA is requested to assign the following types (Table 1) from > the > >> IETF > >>> Review range in the "NSH MD Class" sub-registry of the "Network > >> Service > >>> Header (NSH) Parameters" registry: > >> Thanks for catching this. This is indeed a bit confusing but the intent > of > >> the draft doesn't match with your suggestion: > >> The new metadata defined by this document shall be registered in "NSH > >> IETF-Assigned Optional Variable-Length Metadata Types". > >> So each object will have its own type but all will be of the same MD > Class > >> (0x0000, which is the only value registered by 8300, and which is in > the > >> "NSH MD Class" registry). > >> So I think the new text should simply be: > >> IANA is requested to assign the following types from the "NSH IETF- > >> Assigned Optional Variable-Length Metadata Types" registry available at > >> [IANA-NSH-MD2]: > >> -m > >> > >> Yuehua-1>>Will delete "(0x0000 IETF Base NSH MD Class)" which is > >> Yuehua-1>>confusing and not needed here > >> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> COMMENT: > >>> ---------------------------------------------------------------------- > >>> > >>> Thank you for a well done shepherd writeup. > >>> > >>> I support Ben's DISCUSS position, particularly the first point. > >> > >> Yuehua-2>>Will resolve Ben's comments in the email thread reply to > Ben's > >> > >>> A suggestion on organization: I think what you have as the top of > >>> Section 7 should be a subsection (e.g., 7.1), and then the other > >> subsections moved down. > >>> It doesn't make sense to me to have these registrations be dominant > >>> over the others; they're all just a set of IANA actions. > >> > >> Yuehua-3>>Accepted. will update to ver10 > >> > >>> I have the same comment as Francesca about Section 4.1. > >> > >> Yuehua-4>>Will resolve Francesca's comment in the email thread reply to > >> Yuehua-4>>Francesca's > >> > >>> > >>> > >>> > >>> > >> > >> _______________________________________________ > >> sfc mailing list > >> sfc@ietf.org > >> https://www.ietf.org/mailman/listinfo/sfc > > > > > __________________________________________________________________________ > _______________________________________________ > > > > 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, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou falsifie. Merci. > > > > 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, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. 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, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Thu Jan 27 11:51:49 2022 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B143A10BA; Thu, 27 Jan 2022 11:51:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-sfc-nsh-tlv@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, gregimirsky@gmail.com, gregimirsky@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.43.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <164331310051.7049.4403209173510676698@ietfa.amsl.com> Date: Thu, 27 Jan 2022 11:51:40 -0800 Archived-At: Subject: [sfc] Murray Kucherawy's No Objection on draft-ietf-sfc-nsh-tlv-13: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2022 19:51:41 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-sfc-nsh-tlv-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for a well done shepherd writeup. Thanks also for tidying up the IANA Considerations. I support Ben's DISCUSS position, particularly the first point. A suggestion on organization: I think what you have as the top of Section 7 should be a subsection (e.g., 7.1), and then the other subsections moved down. It doesn't make sense to me to have these registrations be dominant over the others; they're all just a set of IANA actions. I have the same comment as Francesca about Section 4.1. From nobody Fri Jan 28 11:05:32 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114B03A0AB0 for ; Fri, 28 Jan 2022 11:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wckc9dmaLlr6 for ; Fri, 28 Jan 2022 11:05:26 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667053A0AAC for ; Fri, 28 Jan 2022 11:05:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Jln3B17Cpz1p5xR for ; Fri, 28 Jan 2022 11:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1643396726; bh=Le6IxeWfhVLF7KZwSDf0CRSqVXg9m+RAM+HT524YCiQ=; h=Date:From:Subject:To:From; b=HCbyBXuO+E/U3bcjtTgI72p8Y8WXV9DXVuMbdsUCIfT7WLsPv7/REDq9xk7SAqSqh uSIIlblabG1IrR9Q2PahVmCu20GkAtjfmuTRqmlZk8XFJox8J86acSkTgWqMTyeNBI BRzXLMM+qxEZfUgDlbAum7T7JFOp6icH44AJYssg= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Jln395RRDz1p5jg for ; Fri, 28 Jan 2022 11:05:25 -0800 (PST) Message-ID: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> Date: Fri, 28 Jan 2022 14:05:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 From: "Joel M. Halpern" To: "sfc@ietf.org" Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 19:05:31 -0000 SFC Working Group: As part of discussing the OAM elated drafts in SFC, the chairs have been looking at the overall working group participation. We note that very few people have spoken up about the issues being discussed. For most recent drafts we have been working to advance, it has been a lot of work to get enough comments to justify advancement (and folks could argue that we did not succeed.) We are considering various alternatives. We could, for example, just close the working group. One possibility is to recharter the working group to expand the scope. There are two related questions that we would like to hear from the working group about this. 1) If we were to consider expanding the charter, what things would you like to see included in it? 2) If we do recharter will you work on the existing documents, and will you engage on documents other than the one or two you personally would like to see included? Thank you, Joel and Jim From nobody Fri Jan 28 12:14:24 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A223A1058 for ; Fri, 28 Jan 2022 12:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQq3WLYL-gaO for ; Fri, 28 Jan 2022 12:14:17 -0800 (PST) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB963A104D for ; Fri, 28 Jan 2022 12:14:17 -0800 (PST) Received: by mail-ej1-x62e.google.com with SMTP id j2so19519026ejk.6 for ; Fri, 28 Jan 2022 12:14:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nkan1InjvKaG6wI1eV/LXi5w+jU2s/t9vbKW5rdrXT8=; b=JRXQBk6l5E0obTz6kovdt/J1gqkZy/JFzSZDMJqU5PAS+/2moGRWhNYpbCRVZVdO+G io6TiErD/7bF3rDG3bwaUMjtSqH2KBHpaKhNqgsvdzVLQKQZGl5ineNVavuViHmCag1Q io8Fj4INCmEA5D6BnL3RmHmijmeeZz0uUdivo/1y1Y+MkCtVka31fOUY/lyR9KGfye4T S2F6nXpe4utEc/+o2V8+KbfFgvJU022A+Emx+YcgtW9ZwwWrrv7Eyiu2KLU5t45jZv96 mugXv7rBEsAcuuYcKkxJTjLGbuNlMKmZYcyRgl+99PT8yxDE6tkduTUFzXZs/e1nMkIN 9Vgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nkan1InjvKaG6wI1eV/LXi5w+jU2s/t9vbKW5rdrXT8=; b=mdwCPh+bUfs6cmXpfB4XpKBmotMfkeSkqc31lyZRPBbqu0O3+dQVZe2GewW0ETjRtY boScAuU/Iw8XAo1XNzKz4CIXFAfhL8UazhB1HL4to6ztD2JSE2LEpFPaivOGNAsabhDf fukolYK0A3uGM2F+krG2gofLOfXa/nVjjAsn4woAuPnHAs0sP2ZcKKAf95kQAPeZesI3 2isFnlC/cCBBhJahZMnjyVk+fFEDtMWbouHz16eL3Dx6QKpmkf4hjvfkhJfnxEP8M0zx LtTDqKUMPN95dmowBevEunAG8xoHaUyAxr1f26sdepMX0zWDQThGCx0M2b46DSQ+zQj3 BQvw== X-Gm-Message-State: AOAM531kHCW6trvK8b62VVPysaTCRPHLYCsari6RaNvWL/xcRIzrgGg2 8Sj9kvEVxiCzWF4dUrK5OIuS1JiOSL86X+u25ZaRj3Wv X-Google-Smtp-Source: ABdhPJwcyQZVcwKUQRAW+9Tib6CPcUO7t980K4mQRfUdpoOpug6e6OWJzomAgK2cdAnSzgXlRnpPRK2pkoD/bd3B+c0= X-Received: by 2002:a17:907:160f:: with SMTP id hb15mr7786046ejc.213.1643400854920; Fri, 28 Jan 2022 12:14:14 -0800 (PST) MIME-Version: 1.0 References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> From: Greg Mirsky Date: Fri, 28 Jan 2022 12:14:03 -0800 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002e650d05d6aa14e9" Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 20:14:22 -0000 --0000000000002e650d05d6aa14e9 Content-Type: text/plain; charset="UTF-8" Hi Joel, Jim, and All, though I don't have proposals for re-chartering the WG, I am committed to continuing working on the drafts I have been involved in and helping with reviewing the work from other members of the community. Regards, Greg On Fri, Jan 28, 2022 at 11:05 AM Joel M. Halpern wrote: > SFC Working Group: > > As part of discussing the OAM elated drafts in SFC, the chairs have > been looking at the overall working group participation. We note that > very few people have spoken up about the issues being discussed. For > most recent drafts we have been working to advance, it has been a lot of > work to get enough comments to justify advancement (and folks could > argue that we did not succeed.) > > We are considering various alternatives. We could, for example, > just close the working group. > One possibility is to recharter the working group to expand the scope. > There are two related questions that we would like to hear from the > working group about this. > > 1) If we were to consider expanding the charter, what things would you > like to see included in it? > > 2) If we do recharter will you work on the existing documents, and will > you engage on documents other than the one or two you personally would > like to see included? > > Thank you, > Joel and Jim > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > --0000000000002e650d05d6aa14e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel, Jim, and All,
though I don't have proposa= ls for re-chartering the WG, I am committed to continuing working on the dr= afts I have been involved in and helping with reviewing the work from other= members of the community.

Regards,
Greg=

On Fri, Jan 28, 2022 at 11:05 AM Joel M. Halpern <jmh@joelhalpern.com> wrote:
SFC Working Group:

=C2=A0 =C2=A0 =C2=A0As part of discussing the OAM elated drafts in SFC, the= chairs have
been looking at the overall working group participation.=C2=A0 We note that=
very few people have spoken up about the issues being discussed.=C2=A0 For =
most recent drafts we have been working to advance, it has been a lot of work to get enough comments to justify advancement (and folks could
argue that we did not succeed.)

=C2=A0 =C2=A0 =C2=A0We are considering various alternatives.=C2=A0 We could= , for example,
just close the working group.
One possibility is to recharter the working group to expand the scope.
There are two related questions that we would like to hear from the
working group about this.

1) If we were to consider expanding the charter, what things would you
like to see included in it?

2) If we do recharter will you work on the existing documents, and will you engage on documents other than the one or two you personally would
like to see included?

Thank you,
Joel and Jim

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
--0000000000002e650d05d6aa14e9-- From nobody Fri Jan 28 22:43:38 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129123A0DDC for ; Fri, 28 Jan 2022 22:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57ar-HJk_QaW for ; Fri, 28 Jan 2022 22:42:34 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19F83A0DE2 for ; Fri, 28 Jan 2022 22:42:33 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id 15so7268222ilg.8 for ; Fri, 28 Jan 2022 22:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g0+pdbzlTrbd2seLVoDEC9qVqVMLIN85kjdlW9ik5q8=; b=MPB3fdXOLjrgTOtpT+q159G9BooKLiX+7IErxtCe24oyZmmeRzkI18wIKotODQRtrV FuFVcHTW08lS9Y0kNHN878QIkGhfHpAs38qSLWZ+7vezPvYLee8gDIVTB+zHSy7ncwvs jiCuJVwFOc8uD8jDz6mZ/Ibsdfd2JA++nX7mjUMj8+h45WkFw0AjXEf/ePd2pUf8On/k JyKV+DFHabRNvIsLVcOpYmL5G0nvdpvGzgkcyp9VJiGjPsEfj2VaBKcsWjcQ3WcoweYY 3kZNKJ+dP1v65dR2A9JiyJYsfbGLn1oqaXkK+VeqyTwQOHw9uRhlSwEzyYnbcyjKB1na AoYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=g0+pdbzlTrbd2seLVoDEC9qVqVMLIN85kjdlW9ik5q8=; b=HlTfIXkU51V/velVc7JBKxYd2+Ac0vhbK5J8g0w3g4Yu7YO/YqR9DoFggYZ5dMcpR/ 2OuQvfeaxXc4OcCtjD1/1rxabP3D+hqryiWorMO6YXt7u79Pr0j9e6cqH/X3akZI+LWB O3/vVByQzz1kfKuzRhZKoHF2qBtEwsA4yoT33j1KsK6OSrRiWDGpYTquTnU4Ew+3CaLo uWTtLoxiEjtgdf9WmOvYi1sCsqeGWpRsladBrkdKjqYKycL+NNEbN+SW0/HquR4JYqXu 4kpKSu/bUCzsUUbSkKD+9Y9cqqsKaEde+/nW89rQb54gBpmWC2YiJkoruF7OsLwAEChe 296g== X-Gm-Message-State: AOAM5308KJdqPecZm1LoeToTMHMUEvb3FVKsx/5rdY5XAnl/Qz4F7sX1 uIadOuituXg22Ft+LCV+SEnYZ+Z19jFa7nzqKXI= X-Google-Smtp-Source: ABdhPJznRWDeM9ksicB2IV+WshqEaDj1snF62qgZTLKcon6BNQLbrQgkd5cY+ClvhFjZAiFl/7i5w1VQYCwxfxcUhDA= X-Received: by 2002:a05:6e02:1bc2:: with SMTP id x2mr8131985ilv.322.1643438551834; Fri, 28 Jan 2022 22:42:31 -0800 (PST) MIME-Version: 1.0 References: <3fb99d69-5c6c-01df-ebb0-66edb9afcd8a@joelhalpern.com> In-Reply-To: From: Donald Eastlake Date: Sat, 29 Jan 2022 01:42:20 -0500 Message-ID: To: "Joel M. Halpern" Cc: "sfc@ietf.org" , Greg Mirsky Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [sfc] Future of SFC work X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2022 06:42:41 -0000 I would support and agree with what Greg said for my drafts and those of others in SFC. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Jan 28, 2022 at 3:14 PM Greg Mirsky wrote: > > Hi Joel, Jim, and All, > though I don't have proposals for re-chartering the WG, I am committed to continuing working on the drafts I have been involved in and helping with reviewing the work from other members of the community. > > Regards, > Greg > > On Fri, Jan 28, 2022 at 11:05 AM Joel M. Halpern wrote: >> >> SFC Working Group: >> >> As part of discussing the OAM elated drafts in SFC, the chairs have >> been looking at the overall working group participation. We note that >> very few people have spoken up about the issues being discussed. For >> most recent drafts we have been working to advance, it has been a lot of >> work to get enough comments to justify advancement (and folks could >> argue that we did not succeed.) >> >> We are considering various alternatives. We could, for example, >> just close the working group. >> One possibility is to recharter the working group to expand the scope. >> There are two related questions that we would like to hear from the >> working group about this. >> >> 1) If we were to consider expanding the charter, what things would you >> like to see included in it? >> >> 2) If we do recharter will you work on the existing documents, and will >> you engage on documents other than the one or two you personally would >> like to see included? >> >> Thank you, >> Joel and Jim >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Jan 31 20:22:05 2022 Return-Path: X-Original-To: sfc@ietf.org Delivered-To: sfc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D77C53A11F4; Mon, 31 Jan 2022 20:22:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sfc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.44.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sfc@ietf.org Message-ID: <164368932381.19904.367436042440675405@ietfa.amsl.com> Date: Mon, 31 Jan 2022 20:22:03 -0800 Archived-At: Subject: [sfc] I-D Action: draft-ietf-sfc-ioam-nsh-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 04:22:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining WG of the IETF. Title : Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data Authors : Frank Brockners Shwetha Bhandari Filename : draft-ietf-sfc-ioam-nsh-07.txt Pages : 9 Date : 2022-01-31 Abstract: In-situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated with the Network Service Header (NSH). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-ioam-nsh-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Jan 31 20:57:38 2022 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FFC3A136B for ; Mon, 31 Jan 2022 20:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=thoughtspot.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsYyFr8DSqVy for ; Mon, 31 Jan 2022 20:57:32 -0800 (PST) Received: from mx0a-0055fe01.pphosted.com (mx0a-0055fe01.pphosted.com [205.220.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853463A1367 for ; Mon, 31 Jan 2022 20:57:32 -0800 (PST) Received: from pps.filterd (m0211451.ppops.net [127.0.0.1]) by mx0b-0055fe01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 20VLUFUQ003362 for ; Mon, 31 Jan 2022 20:24:48 -0800 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by mx0b-0055fe01.pphosted.com (PPS) with ESMTPS id 3dw3ks74px-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 31 Jan 2022 20:24:47 -0800 Received: by mail-qk1-f200.google.com with SMTP id d130-20020a379b88000000b004e11e7b51c4so1382258qke.17 for ; Mon, 31 Jan 2022 20:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thoughtspot.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pIqBuLs/deyh+pId9GKByrkE6rA7gMhPXQCuI/EQdVU=; b=RQDiWpwIH6sEc4N48ABR2ElChPoX+C3akbuRhilvxauaA9+u2W8MxfIkPBs2Dxo3lh OD0w///aauSYH5zRg5x/NnI36naI4dOLMvJm2tdLdlEZ+3DiuNLBGn6xHLbJuCcHvAEN RVm3xQygs1SpcECgdLcEs+BWLnbvhliQ1G+vdpamMhW2ZSrm5DQFFj4lNw7mQTQw2cuI fZtTn4Pv6c5ZOyYQQOm+BjCa4Pqi/IJwI/WMeYTipO0Mslz6h/44H6OQXFP/YDpZMjiO VBmv/Dq7g9EE5mrsYshJZrHPSmNRsnMt4/fcLwWsi+WN+rt8hNKLK1yj2CJjuK+Bj7LS rJLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pIqBuLs/deyh+pId9GKByrkE6rA7gMhPXQCuI/EQdVU=; b=eVOZTr3p1Zw59O1jH9me2RXYxoEIpzxZlVSjQAiAgGd8nmvmA3Q3kZjxZAHMRdFvTg 9unJboGYo+6tyJzlxtTfBQ5CWGMX3G8zm8wEXLCyhAAGfiqQHE8JgEsnilG+DE0hCch7 cN/oWInHIO29jgrDQDZElaob0I+DjH9ghyj5REBJwLFRn5NmIyT+Mm8B9i3EddFZ4ce5 mscmCcdPXCe6TG5pOCyUsiK9SEP793MslPuywFOiT0fPE+GqCYUz+xONJr2wdTTjy+4t D1jCULolvyjaPNxYrVO6X8NS/tRULBnS6sz01bN+co1yzW+qiinQRYqdNbcsPjDuQqvW tvow== X-Gm-Message-State: AOAM531gc6psf4GTug3XZYCPhxl+ZHIBcsnJAlXVRfPnsc3XcU9o33Q7 451arZrtKP/ZHqVtNdJC/Dtyc+cgRRS/hy/MwreYBfBt6PDuxTwcpU35LImBt6zjF9tgDwmQRID oJN+LtwGDvGLB8aOlats= X-Received: by 2002:a05:620a:4727:: with SMTP id bs39mr3240561qkb.486.1643689486356; Mon, 31 Jan 2022 20:24:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3eHziKgF74RtTWLVbNRtuGNvnLAtmopeCVv7CU/jplKu5IemxVemm0OPj7vL+f/08a5oRwAW3Gxt3CZlTcbc= X-Received: by 2002:a05:620a:4727:: with SMTP id bs39mr3240547qkb.486.1643689486009; Mon, 31 Jan 2022 20:24:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Shwetha Bhandari Date: Tue, 1 Feb 2022 09:54:35 +0530 Message-ID: To: Greg Mirsky Cc: James Guichard , draft-ietf-sfc-ioam-nsh@ietf.org, "sfc@ietf.org" , "sfc-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ef60fb05d6ed47ad" X-Proofpoint-GUID: EkgxeqlHchLro6dgr6WB0w7wMslwvyJW X-Proofpoint-ORIG-GUID: EkgxeqlHchLro6dgr6WB0w7wMslwvyJW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-01_01,2022-01-31_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 clxscore=1011 impostorscore=0 suspectscore=0 adultscore=0 mlxscore=0 phishscore=0 mlxlogscore=612 bulkscore=5 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202010022 Archived-At: Subject: Re: [sfc] WGLC for https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2022 04:57:37 -0000 --000000000000ef60fb05d6ed47ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, Sorry for the late action on this. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07 has been now posted with the edits per this discussion. Hi Jim, After Greg's review please let us know if the changes are good to progress the draft to the next step. Thanks, Shwetha On Wed, Oct 27, 2021 at 7:31 PM Greg Mirsky wrote: > Hi Shwetha, > thank you for the detailed response to my comments. Please feel free to > share any updates you're considering for the next version. I'll be glad t= o > work together on these. > I have several follow-up notes in-lined below under the GIM>> tag. > > Regards, > Greg > > On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhandari < > shwetha.bhandari@thoughtspot.com> wrote: > >> Hi Greg, >> >> Sorry for the very late reply. Please find responses to your comments >> inline @Shwetha: >> >> >> >> On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky wrote= : >> >>> Dear Authors and All, >>> I've read the current version of the draft and have some comments I'd >>> like to share with you. I much appreciate your thoughts on where this w= ork >>> should go considering developments in other IETF WGs. Please find my no= tes >>> and questions below: >>> >>> - It is stated in the Abstract that: >>> >>> In-situ Operations, Administration, and Maintenance (IOAM) records >>> operational and telemetry information in the packet while the packet >>> traverses a path between two points in the network. >>> >>> But that is the case only for the pre-allocated and incremental trace >>> option types. The Direct Export option >>> >>> does not write telemetry data into the data packet itself but export >>> telemetry information in a specially constructed packet. >>> And as we are talking about different IOAM trace options, the >>> question of the scope of this document seems appropriate. There is a >>> WGLC on two IOAM documents >>> >>> active through September 15th at the IPPM WG. I believe that it would b= e >>> beneficial if we had a single document that describes the applicability= of >>> IOAM in all its functionality defined by documents in IPPM WG. Of cours= e, >>> that cannot be a moving target as that would not be helpful. But since = the >>> IPPM WG discusses the progress of two IOAM documents, it could be a gre= at >>> time to address the applicability of the Direct Export trace type >>> >>> and Loopback and Active flags defined in draft-ietf-ippm-ioam-flags >>> . >>> It would be concerning to have more than one SFC document describing th= e >>> applicability of the generic IOAM mechanisms >>> >>> >> Shwetha> This is a fair point. We will revise the draft with text in th= e >> abstract and Section 3 IOAM-Type to be updated to include the usage of >> trace and DEX options. The encapsulation of IOAM options within NSH its= elf >> in its current form already supports all the IOAM Option Type defined bo= th >> from draft-ietf-ippm-ioam-data and draft-ietf-ippm-ioam-direct-export >> along with the flags supported within the options. Hence the >> IOAM-data-field definitions in the draft will remain unchanged. >> > GIM>> I agree that the definitions of the IOAM data-fields are invariant > in various data plane encapsulations. You likely follow the discussion of > the IAOM Direct Export and IOAM flags on the IPPM WG list. I think that f= or > SFC NSH, IOAM Direct Export could be as simple as "use the local policy". > The applicability of the Loopback and Active flags seems to require > detailed explanation by SFP actors. > >> >> >>> >>> >>> - The location of the IOAM header in the SFC NSH-encapsulated packet >>> is defined in Section 3: >>> >>> IOAM-Data-Fields are carried in NSH >>> using a next protocol header which follows the NSH MD context >>> headers. >>> >>> I've checked RFC 8300 but couldn't find it defines the Next Protocol >>> header. Also, it appears that NSH Context headers are optional. Hence m= y >>> question. Is the presence of an NSH Context header required when using >>> IOAM? Could you clarify which mechanism is used to identify the payload= of >>> an SFC NSH-encapsulated packet as IOAM? >>> >>> Shwetha> We will reword it, it is not Next Protocol header but using >> IOAM as a Next Protocol as described in Section 4.1 and requested in IAN= A >> section. Following is the proposed text to align with the RFC 8300 >> reference to context headers following base header and service path head= er: >> "The NSH is defined in [RFC8300]. IOAM-Data-Fields are carried in >> NSH using a next protocol to identify IOAM data fields that follows NSH >> context headers." >> > GIM>> I think that RFC 8300 views data following Context Headers as NSH > payload, not being "in NSH". > >> >>> - If I understand the format of the IOAM header defined in Section 3 >>> correctly, the header's length is limited by 1020 octets, while the >>> effective length containing IOAM options and data - 1016 octets. Is = that >>> correct? What is the recommended technique of collecting IOAM data t= hat >>> exceeds that limit? >>> >>> Shwetha > IOAM options inherently support specifying the size limits at >> the node that added the IOAM options. While operationalizing the solutio= n >> the data types included and number of nodes expected to be adding the da= ta >> should be selected. This is covered in deployment >> considerations draft-brockners-opsawg-ioam-deployment. >> >>> >>> - In Section 4.1, I've found the text reflecting the history of the >>> discussion about how to carry the IOAM header using NSH encapsulatio= n. As >>> the text has no normative value, I suggest moving it into an Appendi= x. >>> >>> Shwetha > Agreed, revised draft will have this section moved to >> Appendix. >> > GIM>> Thank you. > >> >>> - I find the rules of handling the O-bit in NSH listed in Section >>> 4.2 inconsistent and confusing. The IOAM header is not part of NSH >>> encapsulation but is a part of the payload. But in one case, when us= er data >>> follows it, the O-bit must not be set as. If there's no user data af= ter the >>> IOAM header, then the O-bit must be set. But from the perspective of= NSH >>> encapsulation, it includes specially constructed data added for the = sole >>> purpose of collecting OAM/telemetry information. Then, why, in one c= ase, >>> the O-bit is cleared and in the other set if, in both cases, the >>> NSH-encapsulated packet is used to perform the OAM function? >>> >>> Shwetha > The reason for not setting the O-bit for packets that contain= s >> actual user data is because RFC 8300 has " SF/SFF/SFC Proxy/Classifier >> implementations that do not support >> >> SFC OAM procedures SHOULD discard packets with O bit set". It will= be undesirable to discard packets with O-bit set that carry user data as I= OAM can be inserted insitu. >> >> For synthetic traffic created for OAM along with IOAM-data-fields in NSH= following the NSH OAM function with 0-bit set is desirable. >> >> GIM>> This is an interesting situation. I agree that there could be an > SFC element not supporting "SFC OAM procedures" (not clear what these are= ). > By the same token, would such SFC element support IOAM, be capable of > processing IOAM without adverse impact to user data? I am not certain and > it seems that it might be better to recommend that NSH packets with IOAM = be > dropped by an SFP element if it does not support "SFC OAM". What are your > thoughts? > > >> >> Thanks, >> Shwetha >> >>> I much appreciate your consideration of my comments and questions and >>> looking forward to your feedback. >>> >>> Regards, >>> Greg >>> >>> On Wed, Aug 18, 2021 at 5:32 AM James Guichard < >>> james.n.guichard@futurewei.com> wrote: >>> >>>> Dear WG: >>>> >>>> >>>> >>>> This email starts a 2 week Working Group Last Call for >>>> draft-ietf-sfc-ioam-nsh [1]. >>>> >>>> >>>> >>>> Please read this document if you haven=E2=80=99t read the most recent = version >>>> and send your comments to the SFC WG list no later than September 1st >>>> 2021. >>>> >>>> >>>> >>>> If you are raising a point which you expect will be specifically >>>> debated on the mailing list, consider using a specific email/thread fo= r >>>> this point. >>>> >>>> >>>> >>>> Lastly, if you are an author or contributor please response to indicat= e >>>> whether you know of any undisclosed IPR related to this document. >>>> >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> Jim & Joel >>>> >>>> >>>> >>>> [1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>>> >>> --000000000000ef60fb05d6ed47ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Sorry for the late action on t= his. https://datatracker.ietf.org/doc/html/draft-ietf-sfc-ioam-nsh-07= has been now posted with the edits per this discussion.=C2=A0

Hi Jim,

After Greg's review p= lease let us know if the changes are good to progress the draft to the next= step.

Thanks,
Shwetha

On Wed, Oct = 27, 2021 at 7:31 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
H= i Shwetha,
thank you for the detailed response to my comments. Please f= eel free to share any updates you're considering for the next version. = I'll be glad to work together on these.
I have several follow= -up notes in-lined below under the GIM>> tag.

Regards,
Greg

On Tue, Oct 26, 2021 at 6:51 PM Shwetha Bhan= dari <shwetha.bhandari@thoughtspot.com> wrote:
Hi Greg,

Sorry for the very late reply. Please = find responses to your comments inline @Shwetha:



On Wed, Sep 8, 2021 at 3:30 AM Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
Dear Authors and All,
I've read the current version of th= e draft and have some comments I'd like to share with you. I much appre= ciate your thoughts on where this work should go considering developments i= n other IETF WGs. Please find my notes and questions below:
    <= li>It is stated in the Abstract that:
=C2=A0 =C2=A0In-situ Operati= ons, Administration, and Maintenance (IOAM) records
=C2=A0 =C2=A0operati= onal and telemetry information in the packet while the packet
=C2=A0 =C2= =A0traverses a path between two points in the network.
But that is the case only for the pre-allocated and incremental trace opt= ion=C2=A0types. The Direct Export option does not write telemetry=C2=A0data = into the data packet itself but export telemetry information in a specially= constructed packet.=C2=A0
And as we are talking about different = IOAM trace options, the question=C2=A0of the scope of this document seems a= ppropriate. There is a WGLC on two IOAM documents active through Septembe= r 15th at the IPPM WG. I believe that it would be beneficial if we had a si= ngle document that describes the applicability of IOAM in all its functiona= lity defined by documents in IPPM WG. Of course, that cannot be a moving ta= rget as that would not be helpful. But since the IPPM WG discusses the prog= ress of two IOAM documents, it could be a great time to address the applica= bility of the Direct Export trace type and Loopback and Active flags defined= in=C2=A0draf= t-ietf-ippm-ioam-flags. It would be concerning to have more than one SF= C document describing the applicability of the generic IOAM mechanisms

Shwetha> This is a fair point. = We will revise the=C2=A0 draft with text in the abstract and Section 3 IOAM-Type=C2=A0to be updated to include the usage of trace and DEX options.=C2= =A0 The encapsulation of IOAM options within NSH itself in its current form= already supports all the IOAM Option Type defined both from draft-ietf-ippm-ioam-d= ata and=C2=A0draft-ietf-ippm-ioam-direct-export along with the flags supported within the options.= Hence the IOAM-data-field definitions in the draft will remain unchanged.= =C2=A0
GIM>> I agree that t= he definitions of the IOAM data-fields are invariant in various data plane = encapsulations. You likely follow the discussion of the IAOM Direct Export = and IOAM flags on the IPPM WG list. I think that for SFC NSH, IOAM Direct E= xport could be as simple as "use the local policy". The applicabi= lity of the Loopback and Active flags seems to require detailed explanation= by SFP actors.

=C2=A0
  • The location of the IOAM header in the SFC = NSH-encapsulated=C2=A0packet is defined in Section 3:
=C2=A0= =C2=A0IOAM-Data-Fields are carried in NSH
=C2=A0 =C2=A0using a n= ext protocol header which follows the NSH MD context
=C2=A0 =C2= =A0headers.
I've checked RFC 8300 but couldn't fi= nd it defines the Next Protocol header. Also, it appears that NSH Context h= eaders=C2=A0are optional. Hence my question. Is the presence of an NSH Cont= ext header required when using IOAM? Could you clarify which mechanism is u= sed to identify the payload of an SFC NSH-encapsulated packet as IOAM?
Shwetha> We will reword it, it is not Next Protocol header but using IO= AM as a Next Protocol as described in Section 4.1 and requested in IANA sec= tion. Following is the proposed text to align with the RFC 8300 reference t= o context headers following base header and service path header:
"The NSH is defined in [RFC8300].=C2= =A0 IOAM-Data-Fields are carried in NSH=C2=A0using a next protocol to ident= ify IOAM data fields that follows NSH context headers."
GIM>> I think that RFC 8300 views data fo= llowing Context Headers as NSH payload, not being "in NSH".=C2=A0=
=
  • If I understand the format of the IOAM header= defined in Section 3 correctly, the header's length is limited by 1020= octets, while the effective length containing IOAM options and data - 1016= octets. Is that correct? What is the recommended technique of collecting I= OAM data that exceeds that limit?
Shwetha > IOAM options inherently support specify= ing the size limits at the node that added the IOAM options. While operatio= nalizing the solution the data types included and number of nodes expected = to be adding the data should be selected. This is covered in deployment con= siderations=C2=A0draft-brockners-opsawg-ioam-deployment.
  • I= n Section 4.1, I've found the text reflecting the history of the discus= sion about how to carry the IOAM header using NSH encapsulation. As the tex= t has no normative value, I suggest moving it into an Appendix.
Shwetha > Agreed, r= evised draft will have this section moved to Appendix.=C2=A0
GIM>> Thank you.=C2=A0
  • I find the rules of handling the O-bit in NSH listed in Section = 4.2 inconsistent and confusing. The IOAM header is not part of NSH encapsul= ation but is a part of the payload. But in one case, when user data follows= it, the O-bit must not be set as. If there's no user data after the IO= AM header, then the O-bit must be set. But from the perspective of NSH enca= psulation, it includes specially constructed data added for the sole purpos= e of collecting OAM/telemetry information. Then, why, in one case, the O-bi= t is cleared and in the other set if, in both cases, the NSH-encapsulated p= acket is used to perform the OAM function?
Shwetha > The reason for not setting the= O-bit for packets that contains actual user data is because RFC 8300 has &= quot; SF/SFF/SFC Proxy/Classifier imp= lementations that do not support
      SFC O=
AM procedures SHOULD discard packets with O bit set". It will be undes=
irable to discard packets with O-bit set that carry user data as IOAM can b=
e inserted insitu.
For synthetic traffic created for OAM along=
 with IOAM-data-fields in NSH following the NSH OAM function with 0-bit set=
 is desirable.
=C2=A0GIM>> This = is an interesting situation. I agree that there could be an SFC element not= supporting "SFC OAM procedures" (not clear what these are). By t= he same token, would such SFC element support IOAM, be capable of processin= g IOAM without adverse impact to user data? I am not certain and it seems t= hat it might be better to recommend that NSH packets with IOAM be dropped b= y an SFP element if it does not support "SFC OAM". What are your = thoughts?
=C2=A0

Thanks,
Shwe= tha=C2=A0
I much appreciate your consideration of my comments= and questions and looking forward to your feedback.

Regards,
Greg

=
On Wed, Aug 18, 2021 at 5:32 AM James= Guichard <james.n.guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

This email starts a 2 week Working Group Last Call f= or draft-ietf-sfc-ioam-nsh [1].

=C2=A0

Please read this document if you haven=E2=80=99t rea= d the most recent version and send your comments to the SFC WG list no late= r than September 1st 2021.

=C2=A0

If you are raisi= ng a point which you expect will be specifically debated on the mailing lis= t, consider using a specific email/thread for this point.

=C2=A0=

Lastly, if you a= re an author or contributor please response to indicate whether you know of= any undisclosed IPR related to this document.

=C2=A0

Thanks!

=C2=A0

Jim & Joel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/

=C2=A0

=C2=A0

=C2=A0

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.i= etf.org/mailman/listinfo/sfc
--000000000000ef60fb05d6ed47ad--