From nobody Mon Nov 2 10:31:35 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3913A0365; Mon, 2 Nov 2020 10:31:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160434187993.1575.17754543317504078999@ietfa.amsl.com> Date: Mon, 02 Nov 2020 10:31:19 -0800 Archived-At: Subject: [babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:31:20 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the SECDIR review from Valery Smyslov. Please review and respond to the remaining items. In particular, I concur with the recommendations about precise language around the names of the parameters. Section 3.1. babel-implementation-version. Is there any guidance on the format of this string (or is it free form like a Server: in HTTP)? Section 3.1. babel-metric-comp-algorithms, babel-mac-algorithms, babel-dtls-cert-types. Is there any guidance to provide on the delimiter between a list of values, or is that explicitly a data model issue? Section 3.1. babel-security-supported, babel-mac-algorithms, babel-dtls-cert-types. Consider providing citations on “MAC” and “DTLS”; and “HMAC-SHA256” and “BLAKE2s”; and “X.509” and “RawPublicKey” (just like was done for babel-metric-comp-algorithms). Section 3.8. babel-mac-key-value. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. I was under the impression that this was an information model to encode generic Babel protocol parameter and that the underlying protocol documents fully specified the normative behavior. However, this guidance appears to be introducing more restrictive configuration guidance not found in draft-ietf-babel-hmac making this document an information model + profile. Was this intentional? Section 3.8 and 3.9. babel-mac-key-test and babel-cert-test. It would be useful to explain the use case for this testing API. Section 5. Note that operations are also exposed in the information model. OLD This document defines a set of information model objects and parameters that may be exposed to be visible from other devices NEW This document defines a set of information model objects, parameters, and operations that may be exposed to be visible from other devices Section 5. Per: MAC keys are allowed to be as short as zero-length. This is useful for testing. Network operators are advised to follow current best practices for key length and generation of keys related to the MAC algorithm associated with the key. Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks. Add clarifying text that the information model explicitly enables this brute force attack where most of the workload is pushed onto the server (since it computes the hash). Also add a mitigation. Perhaps something like “This information model provides an oracle via the babel-mac-key-test operation that would enable such a brute force attack. Operators SHOULD rate limit access to this operation.” From nobody Mon Nov 2 12:05:48 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5397F3A1216; Mon, 2 Nov 2020 12:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 CYEJTOoFZ0kQ; Mon, 2 Nov 2020 12:05:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0144B3A11E0; Mon, 2 Nov 2020 12:04:29 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A2JtHFp014423; Mon, 2 Nov 2020 15:04:25 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 34hmvrkvvv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2020 15:04:25 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K4Mi8017221; Mon, 2 Nov 2020 15:04:23 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K4I3L017080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2020 15:04:19 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id DE8D44005C1F; Mon, 2 Nov 2020 20:04:18 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (unknown [135.50.89.109]) by zlp30484.vci.att.com (Service) with ESMTPS id B9CBD4005C1C; Mon, 2 Nov 2020 20:04:18 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 2 Nov 2020 15:04:12 -0500 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Mon, 2 Nov 2020 15:04:12 -0500 From: "STARK, BARBARA H" To: "'Geoff Huston'" , "'rtg-ads@ietf.org'" CC: "'rtg-dir@ietf.org'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" , "'last-call@ietf.org'" Thread-Topic: [babel] RtgDir review: draft-ietf-babel-information-model-11.txt Thread-Index: AQHWpsrbOgEYG24sekSUx14m/vPz3Km1VaFQ Date: Mon, 2 Nov 2020 20:04:12 +0000 Message-ID: <04540478027d442c9bb448ebd132b9b8@att.com> References: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> In-Reply-To: <8EAB2DD3-8337-42D6-ACC6-82197CC958E9@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.127.123] x-tm-snts-smtp: D5DA6D70E167529B99144850B9B067066EEA7EF6E86610968AF17AB2BDF738832 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-02_13:2020-11-02, 2020-11-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 bulkscore=0 phishscore=0 suspectscore=0 mlxscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 clxscore=1011 malwarescore=0 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011020152 Archived-At: Subject: Re: [babel] RtgDir review: draft-ietf-babel-information-model-11.txt X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 20:05:28 -0000 VGhhbmtzLCBHZW9mZiwgZm9yIHJldmlld2luZy4gSSdtIHNvcnJ5IGZvciBteSBkZWxheWVkIHJl c3BvbnNlLCBidXQgYW0gZ2xhZCB0aGF0IG90aGVycyB3ZXJlIGFibGUgdG8gcmVzcG9uZC4gR2l2 ZW4gdGhlaXIgcmVzcG9uc2VzLCBJJ20gcmVzb2x2aW5nIHlvdXIgY29tbWVudHMgYXMgZm9sbG93 cy4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBkaXNhZ3JlZS4gQW5kIHRob3VnaCBJJ20gcHJv cG9zaW5nIG5vIGNoYW5nZSwgSSByZWFsbHkgZG8gYXBwcmVjaWF0ZSB5b3VyIHJldmlldy4gU3Ry aW5nIGxlbmd0aCBhbmQgdW5pdHMgYXJlIGV4dHJlbWVseSBpbXBvcnRhbnQgY29uY2VwdHMgd2hl biBzcGVjaWZ5aW5nIGFuIGluZm9ybWF0aW9uIG9yIGRhdGEgbW9kZWwuDQoNCj4gTml0czoNCj4g DQo+IEl0IHNlZW1zIGFub21hbG91cyB0byB0aGlzIHJldmlld2VyIHRoYXQgaXQgZ29lcyB0byB0 aGUgYml0IGxlbmd0aHMgb2Ygc29tZQ0KPiBpbnRlZ2VyIHZhbHVlZCBvYmplY3RzLCB5ZXQgbGVh dmVzIHN0cmluZyBvYmplY3RzIHVuZGVmaW5lZCBpbiB0ZXJtcyBvZiBhbnkNCj4gbWF4aW11bSBs ZW5ndGguDQoNCk5vIGNoYW5nZS4gQXMgbm90ZWQgYnkgb3RoZXJzIGluIHRoZWlyIHJlc3BvbnNl cyB0byB0aGlzIGNvbW1lbnQsIHRoZSBiaXQgbGVuZ3RocyBvZiBpbnRlZ2VyIHZhbHVlcyBtdXN0 IGJlIHNwZWNpZmllZCBiZWNhdXNlIHRoZXkgY29ycmVzcG9uZCB0byBwcm90b2NvbCBwYXJhbWV0 ZXJzIHRoYXQgaGF2ZSBzcGVjaWZpYyBsZW5ndGggcmVxdWlyZW1lbnRzLiBTdHJpbmcgb2JqZWN0 cyBoYXZlIG5vIGxlbmd0aCBzcGVjaWZpZWQgYnkgdGhlIHByb3RvY29sLiBJbiB0aGlzIGNhc2Us IGl0IGlzIGNvbW1vbiBwcmFjdGljZSAoZm9yIGluZm9ybWF0aW9uIGFuZCBkYXRhIG1vZGVscykg dG8gbGVhdmUgbGVuZ3RoIHNwZWNpZmljYXRpb24gdG8gdGhlIGltcGxlbWVudGF0aW9uLiBJJ3Zl IGxlYXJuZWQgdGhpcyB0aGUgaGFyZCB3YXkgb3ZlciB0aGUgbGFzdCAxNSB5ZWFycyAoc3BlY2lm eWluZyBzdHJpbmcgbGVuZ3RocyB0aGF0IHR1cm5lZCBvdXQgdG9vIHNob3J0IG9yIHRvbyBsb25n IGZvciBob3cgc29tZW9uZSB3YW50ZWQgdG8gdXNlIHRoZW0pLg0KDQo+ICJjZW50aXNlY29uZHMi PyBSZWFsbHk/ICJ0ZW50aHMgb2Ygc2Vjb25kcyIgd291bGQgYmUgY2xlYXJlciB0byBtb3N0DQo+ IHJlYWRlcnMhDQoNCk5vIGNoYW5nZS4gQXMgbm90ZWQgYnkgb3RoZXJzIGluIHRoZWlyIHJlc3Bv bnNlcyB0byB0aGlzIGNvbW1lbnQsIGNlbnRpc2Vjb25kcyBpcyB0aGUgdW5pdCBzcGVjaWZpZWQg YnkgdGhlIHByb3RvY29sIChzbyB0aGUgaW5mbyBtb2RlbCBpcyB1c2luZyBjb25zaXN0ZW50IHVu aXQgbm9tZW5jbGF0dXJlKSBhbmQgaXQgaXMgdGhlIHByZWZlcnJlZCBtYW5uZXIgZm9yIGV4cHJl c3NpbmcgdGhpcyB1bml0IGluIGRhdGEgbW9kZWxzIEknbSBpbnZvbHZlZCB3aXRoLg0KDQpUaGFu a3MgYWdhaW4sDQpCYXJiYXJhDQoNCg0K From nobody Mon Nov 2 12:07:43 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351A53A11C9; Mon, 2 Nov 2020 12:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2U00cdtm2biu; Mon, 2 Nov 2020 12:07:41 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 38DD73A1037; Mon, 2 Nov 2020 12:07:41 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A2K3v3N003403; Mon, 2 Nov 2020 15:07:40 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049297.ppops.net-00191d01. with ESMTP id 34hmw7v1c8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2020 15:07:40 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K7buP026606; Mon, 2 Nov 2020 15:07:39 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2K7YJx026439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2020 15:07:34 -0500 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id F0DC94005C1B; Mon, 2 Nov 2020 20:07:33 +0000 (GMT) Received: from GAALPA1MSGEX1CE.ITServices.sbc.com (unknown [135.50.89.112]) by zlp30484.vci.att.com (Service) with ESMTPS id DC29D4005C19; Mon, 2 Nov 2020 20:07:33 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CE.ITServices.sbc.com (135.50.89.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 2 Nov 2020 15:07:27 -0500 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Mon, 2 Nov 2020 15:07:27 -0500 From: "STARK, BARBARA H" To: "'Roni Even'" , "'gen-art@ietf.org'" CC: "'babel@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" , "'last-call@ietf.org'" Thread-Topic: Genart last call review of draft-ietf-babel-information-model-11 Thread-Index: AQHWqFDT6Q6IP24KRUuG/gawomnMbqm1Vpkg Date: Mon, 2 Nov 2020 20:07:27 +0000 Message-ID: <8ed107aa3fe547168bbd5b301028d47e@att.com> References: <160335680561.31770.717841242125658048@ietfa.amsl.com> In-Reply-To: <160335680561.31770.717841242125658048@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.127.123] x-tm-snts-smtp: 45496689C4C4127B8E60E977E9863EC4E84B0CB4988ADAF4395F103BBFD1F3AE2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-02_13:2020-11-02, 2020-11-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 clxscore=1011 impostorscore=0 adultscore=0 spamscore=0 mlxscore=0 phishscore=0 malwarescore=0 bulkscore=0 mlxlogscore=836 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011020154 Archived-At: Subject: Re: [babel] Genart last call review of draft-ietf-babel-information-model-11 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 20:07:42 -0000 SGkgUm9uaSwNCkV2ZW4gdGhvdWdoIHlvdSBoYWQgbm8gY29tbWVudHMsIEkgZGlkIHdhbnQgdG8g dGhhbmsgeW91IGZvciByZXZpZXdpbmcgdGhpcy4gSSBhcHByZWNpYXRlIHlvdXIgc3BlbmRpbmcg dGhlIHRpbWUuDQpUaHgsDQpCYXJiYXJhDQoNCj4gUmV2aWV3ZXI6IFJvbmkgRXZlbg0KPiBSZXZp ZXcgcmVzdWx0OiBSZWFkeQ0KPiANCj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCByZXZpZXdl ciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYQ0KPiBSZXZpZXcgVGVhbSAoR2VuLUFS VCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkDQo+IGJ5IHRoZSBJ RVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 DQo+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IEZvciBtb3JlIGlu Zm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQNCj4gDQo+IERvY3VtZW50OiBkcmFmdC1p ZXRmLWJhYmVsLWluZm9ybWF0aW9uLW1vZGVsLT8/DQo+IFJldmlld2VyOiBSb25pIEV2ZW4NCj4g UmV2aWV3IERhdGU6IDIwMjAtMTAtMjINCj4gSUVURiBMQyBFbmQgRGF0ZTogMjAyMC0xMC0yNw0K PiBJRVNHIFRlbGVjaGF0IGRhdGU6IE5vdCBzY2hlZHVsZWQgZm9yIGEgdGVsZWNoYXQNCj4gDQo+ IFN1bW1hcnk6DQo+IFRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24gYXMgaW5m b3JtYXRpb25hbCBSRkMNCj4gDQo+IE1ham9yIGlzc3VlczoNCj4gDQo+IE1pbm9yIGlzc3VlczoN Cj4gDQo+IE5pdHMvZWRpdG9yaWFsIGNvbW1lbnRzOg0KPiANCj4gDQoNCg== From nobody Mon Nov 2 12:16:32 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4423A12EA; Mon, 2 Nov 2020 12:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 lnxRwoR1fU-V; Mon, 2 Nov 2020 12:15:43 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 9C4083A11F1; Mon, 2 Nov 2020 12:15:34 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A2KErS7041806; Mon, 2 Nov 2020 15:15:32 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 34h49ynw4j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Nov 2020 15:15:32 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2KFUad011203; Mon, 2 Nov 2020 15:15:31 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A2KFPXk010915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Nov 2020 15:15:25 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 3EB9240145B2; Mon, 2 Nov 2020 20:15:25 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (unknown [135.50.89.109]) by zlp30483.vci.att.com (Service) with ESMTPS id 28F6B40145AF; Mon, 2 Nov 2020 20:15:25 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 2 Nov 2020 15:15:24 -0500 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Mon, 2 Nov 2020 15:15:24 -0500 From: "STARK, BARBARA H" To: =?utf-8?B?J0FudG9uaW4gRMOpY2ltbyc=?= , "'last-call@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" , "'babel@ietf.org'" Thread-Topic: [babel] Last Call: , naming inconsistencies Thread-Index: AQHWq6CT/5N1+3233kaoJnBjzifPvam1UW5w Date: Mon, 2 Nov 2020 20:15:24 +0000 Message-ID: References: <20201026140147.19834-1-antonin.decimo@gmail.com> In-Reply-To: <20201026140147.19834-1-antonin.decimo@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.127.123] x-tm-snts-smtp: A7CC7C6B354D5D1136FDF410B0C60341EB989C7AA15C2AE29351152FB1A245072 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-02_13:2020-11-02, 2020-11-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1015 priorityscore=1501 lowpriorityscore=0 spamscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 suspectscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011020155 Archived-At: Subject: Re: [babel] Last Call: , naming inconsistencies X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 20:15:52 -0000 SGkgQW50b25pbiwNClRoYW5rcyBhZ2Fpbi4gSSBzZWUgaW4gdGhpcyBlbWFpbCB0aGF0LCBpbiBh ZGRpdGlvbiB0byB0aGUgcHJldmlvdXMgMiBlcnJvcnMgcmVsYXRlZCB0byBtYWMta2V5LXNldHMs IHlvdSBpbmNsdWRlIGNvcnJlY3Rpb25zIGZvciBTZWN0aW9uIDI6DQoNCi0gICArLS0gcm91dGVy LWlkDQotICAgKy0tIHNlbGYtc2Vxbm8NCg0KKyAgICstLSBiYWJlbC1zZWxmLXJvdXRlci1pZA0K KyAgICstLSBiYWJlbC1zZWxmLXNlcW5vDQoNCkknbGwgaW5jbHVkZSB0aGVzZSBmaXhlcyBpbiB0 aGUgbmV4dCB2ZXJzaW9uLg0KVGh4LA0KQmFyYmFyYQ0KDQo+IC0tLQ0KPiBEZWFyIGFsbCwNCj4g DQo+IEnigJl2ZSBmb3VuZCBzb21lIGluY29uc2lzdGVuY2llcyBpbiB0aGUgbmFtaW5nIG9mIHNv bWUgZmllbGRzIGluIHRoZQ0KPiBCYWJlbCBJbmZvcm1hdGlvbiBNb2RlbC4gSeKAmXZlIGFscmVh ZHkgc2VuZCBtYWlscyBhYm91dCB0aGVtOyBidXQgSeKAmW0NCj4gYWZyYWlkIG15IG1haWxzIG1p Z2h0IGhhdmUgZmFsbGVuIGluIGxpbWJvLiBUaGUgaXNzdWUgaXMgbWlub3IuDQo+IEJlbG93IGlz IGEgcGF0Y2ggZm9yIHRoZSBmaWVsZHMuDQo+IA0KPiBCZXN0IHJlZ2FyZHMsDQo+IA0KPiBBbnRv bmluDQo+IA0KPiANCj4gIGRyYWZ0LWlldGYtYmFiZWwtaW5mb3JtYXRpb24tbW9kZWwubWQgfCA4 ICsrKystLS0tDQo+ICAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9u cygtKQ0KPiANCj4gZGlmZiAtLWdpdCBhL2RyYWZ0LWlldGYtYmFiZWwtaW5mb3JtYXRpb24tbW9k ZWwubWQgYi9kcmFmdC1pZXRmLWJhYmVsLQ0KPiBpbmZvcm1hdGlvbi1tb2RlbC5tZA0KPiBpbmRl eCA3OTkwYjdhLi4xNTg4Nzk3IDEwMDY0NA0KPiAtLS0gYS9kcmFmdC1pZXRmLWJhYmVsLWluZm9y bWF0aW9uLW1vZGVsLm1kDQo+ICsrKyBiL2RyYWZ0LWlldGYtYmFiZWwtaW5mb3JtYXRpb24tbW9k ZWwubWQNCj4gQEAgLTE3OSw4ICsxNzksOCBAQCBUaGUgSW5mb3JtYXRpb24gTW9kZWwgaXMgaGll cmFyY2hpY2FsbHkgc3RydWN0dXJlZCBhcw0KPiBmb2xsb3dzOg0KPiAgKy0tIGJhYmVsLWluZm9y bWF0aW9uDQo+IA0KPiAgICAgKy0tIGJhYmVsLWltcGxlbWVudGF0aW9uLXZlcnNpb24NCj4gDQo+ ICAgICArLS0gYmFiZWwtZW5hYmxlDQo+IA0KPiAtICAgKy0tIHJvdXRlci1pZA0KPiANCj4gLSAg ICstLSBzZWxmLXNlcW5vDQo+IA0KPiArICAgKy0tIGJhYmVsLXNlbGYtcm91dGVyLWlkDQo+IA0K PiArICAgKy0tIGJhYmVsLXNlbGYtc2Vxbm8NCj4gDQo+ICAgICArLS0gYmFiZWwtbWV0cmljLWNv bXAtYWxnb3JpdGhtcw0KPiANCj4gICAgICstLSBiYWJlbC1zZWN1cml0eS1zdXBwb3J0ZWQNCj4g DQo+ICAgICArLS0gYmFiZWwtbWFjLWFsZ29yaXRobXMNCj4gDQo+IEBAIC01MzQsNyArNTM0LDcg QEAgYmFiZWwtbWFjLWVuYWJsZToNCj4gICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGNob29zZQ0K PiANCj4gICAgdG8gZXhwb3NlIHRoaXMgcGFyYW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+ IA0KPiANCj4gDQo+IC1iYWJlbC1pZi1tYWMta2V5cy1zZXRzOg0KPiANCj4gK2JhYmVsLWlmLW1h Yy1rZXktc2V0czoNCj4gDQo+ICA6IExpc3Qgb2YgcmVmZXJlbmNlcyB0byB0aGUgYmFiZWwtbWFj IGVudHJpZXMgdGhhdCBhcHBseSB0byB0aGlzDQo+IA0KPiAgICBpbnRlcmZhY2UuIFdoZW4gYW4g aW50ZXJmYWNlIGluc3RhbmNlIGlzIGNyZWF0ZWQsIGFsbCBiYWJlbC1tYWMta2V5LXNldHMNCj4g DQo+ICAgIGluc3RhbmNlcyB3aXRoIGJhYmVsLW1hYy1kZWZhdWx0LWFwcGx5ICJ0cnVlIiB3aWxs IGJlIGluY2x1ZGVkDQo+IA0KPiBAQCAtODI4LDcgKzgyOCw3IEBAIGJhYmVsLW1hYy1kZWZhdWx0 LWFwcGx5Og0KPiAgICBhcHBsaWVkIHRvIGFsbCBuZXcgYmFiZWwtaW50ZXJmYWNlIGluc3RhbmNl cywgYnkgZGVmYXVsdC4NCj4gDQo+ICAgIElmICJ0cnVlIiwgdGhpcyBpbnN0YW5jZSBpcyBhcHBs aWVkIHRvDQo+IA0KPiAgICBuZXcgYmFiZWwtaW50ZXJmYWNlcyBpbnN0YW5jZXMgYXQgdGhlIHRp bWUgdGhleSBhcmUgY3JlYXRlZCwgYnkgaW5jbHVkaW5nDQo+IA0KPiAtICBpdCBpbiB0aGUgYmFi ZWwtaW50ZXJmYWNlLW1hYy1rZXlzIGxpc3QuDQo+IA0KPiArICBpdCBpbiB0aGUgYmFiZWwtaWYt bWFjLWtleS1zZXRzIGxpc3QuDQo+IA0KPiAgICBJZiAiZmFsc2UiLCB0aGlzIGluc3RhbmNlIGlz IG5vdCBhcHBsaWVkIHRvIG5ldyBiYWJlbC1pbnRlcmZhY2VzDQo+IA0KPiAgICBpbnN0YW5jZXMg d2hlbiB0aGV5IGFyZSBjcmVhdGVkLg0KPiANCj4gICAgQW4gaW1wbGVtZW50YXRpb24gTUFZIGNo b29zZQ0KPiANCj4gLS0NCj4gMi4yOS4xDQoNCg== From nobody Mon Nov 2 16:08:41 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EE83A135E; Mon, 2 Nov 2020 16:08:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160436211925.31069.7931310164710901437@ietfa.amsl.com> Date: Mon, 02 Nov 2020 16:08:39 -0800 Archived-At: Subject: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-information-model-11: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 00:08:39 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 2 says that the "DTLS certificate values" are required to return no value when read, but this property seems to be intended for private data such as DTLS private key values, not the certificates themselves (which are public). While I appreciate that IPv6 is the current version of the internet protocol, I do see that 6126bis allows for Babel to run over both IPv6 and IPv4, yet this document in multiple places implicitly assumes that Babel runs over IPv6, to the exclusion of IPv4. Such a restriction from the core protocol spec should only be undertaken by an information model with clear reasoning and loud disclaimer. Similarly (as Roman notes), we are putting requirements on the key length for MAC keys (relative to the block size of the underlying hash function) that have were once present in draft-ietf-babel-hmac but have been removed as of draft-ietf-babel-hmac-10. I assume that the intent is not to impose additional restrictions compared to the protocol spec, thus we need to catch up to those changes. The description of the babel-mac-key-test and babel-cert-test operations need to be tightened up, as the secdir reviewer noted. (See COMMENT.) We seem to be using terminology from the Network Management Datastore Architecture without reference or otherwise introducing the concepts. This is a Discuss point because the only candidate reference I know of, RFC 8342, is specific to YANG and data models, so it's applicability for use in an information model may be subject to discussion. (Hopefully this only reflects my ignorance and not a fundamental lack of datastore architecture for information models.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.1 Please use the specific RFC 8174 boilerplate (in particular, it includes "NOT RECOMMENDED"). Section 2 We have separate MAC/DTLS-enablement nodes at a per-interface level, so not having them at the global level is perhaps suprising. I'm happy to see babel-dtls-cert-types, given that the babel/DTLS spec leaves much open as to how to authenticate peers. Even more specificity could be useful. Most parameters are read-only. Following is a descriptive list of the parameters that are not required to be read-only: It's suprising to not see router-id on this list; 6126bis says only that "every Babel speaker is assigned a router-id" without saying how. In the absence of a "how", it seems reasonable to assume "assigned by the administrator" as a valid option. How do I configure which prefixes to advertise as originated from this router? Do I just add something to the babel-routes list with NULL received metric? But if that's how I do it, then the babel-route-obj can't be 'ro'... o Interface: Metric algorithm o Interface: Split horizon o Interface: enable/disable Babel on this interface [...] It might be useful to list these in the same order as they appear in the tree diagram. o Interface: MAC algorithm What node in the tree does this correspond to? Section 3.1 babel-enable: When written, it configures whether the protocol should be enabled (true) or disabled (false). A read from the running or intended datastore indicates the configured administrative value of whether the protocol is enabled (true) or not (false). A read from the operational datastore indicates Perhaps it's just me, but running/intended/operational datastores feels like a YANG/NMDA thing and is surprising to see in a nominally generic information model, absent further reference. (Similarly for subsequent usage of the terms.) babel-self-router-id: The router-id used by this instance of the Babel protocol to identify itself. [I-D.ietf-babel-rfc6126bis] describes this as an arbitrary string of 8 octets. The router-id value MUST NOT consist of all zeroes or all ones. Why is the MUST NOT a requirement of the information model rather than the protocol? babel-metric-comp-algorithms: List of supported cost computation algorithms. Possible values include "2-out-of-3", and "ETX". "2- out-of-3" is described in [I-D.ietf-babel-rfc6126bis], section A.2.1. "ETX" is described in [I-D.ietf-babel-rfc6126bis], section A.2.2. Perhaps this is just me, but the way this is written implies that the specific string values are to be used, which may be overly prescriptive for an information model. Also, is there a registry for these algorithms that could be referenced? babel-security-supported: List of supported security mechanisms. Possible values include "MAC" and "DTLS". babel-mac-algorithms: List of supported MAC computation algorithms. Possible values include "HMAC-SHA256", "BLAKE2s". babel-dtls-cert-types: List of supported DTLS certificate types. Possible values include "X.509" and "RawPublicKey". Likewise, are there registries for these? (D)TLS does have an existing certificate types registry (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3 is the one to use), but for the MAC algorithms that's pretty inherently a very flexible extension point so it's easy to add a new algorithm with no or a very minimal written spec. Section 3.2 babel-mcast-group: Multicast group for sending and listening to multicast announcements on IPv6. Default is ff02::1:6. An IIRC the core protocol only has it as RECOMMENDED for control traffic to be over IPv6; the "on IPv6" here seems unnecessarily limiting. Section 3.3 babel-interface-reference: Reference to an interface object that can be used to send and receive IPv6 packets, as defined by the data [again the implicit IPv6 requirement] babel-mcast-hello-interval: The current interval in use for multicast Hellos sent on this interface. Units are centiseconds. This is a 16-bit unsigned integer. Perhaps it is better to discuss that the units need to have sufficient precision to represent centisecond granularity rather than to enforce a specific unit and constrain data models/implementations. (Similarly for other mentions of units.) babel-dtls-cached-info: Indicates whether the cached_info extension is included in ClientHello and ServerHello packets. The extension Please reference RFC 7924 here. is included if the value is "true". An implementation MAY choose to expose this parameter as read-only ("ro"). I wonder if we can/should give a bit more guidance on what to include in the extension, as currently it would be compliant with this spec (but not very useful) to emit a cached_information extension that is highly unlikely to result in any packet size savings. babel-dtls-cert-prefer: List of supported certificate types, in order of preference. The values MUST be among those listed in the babel-dtls-cert-types parameter. This list is used to populate the server_certificate_type extension in a Client Hello. Values An RFC 7250 reference is probably in order. babel-packet-log: A reference or url link to a file that contains a timestamped log of packets received and sent on babel-udp-port on this interface. The [libpcap] file format with .pcap file extension SHOULD be supported for packet log files. Logging is Does there need to be a mechanism for content-type negotiation/indication? Section 3.4 Shouldn't these all be 'counter's, not 'uint's? Section 3.5 babel-hello-mcast-history: The multicast Hello history of whether or not the multicast Hello packets prior to babel-exp-mcast-hello- seqno were received. A binary sequence where the most recently received Hello is expressed as a "1" placed in the left-most bit, This seems to indicate that the leftmost bit is always '1', and thus that we cannot be in a situation where we missed one expected multicast hello and are already expecting "the one after it". Is that correct? Also, should we say anything about truncating the bitstring at some arbitrary point? (Similarly for the unicast case, on both counts.) babel-exp-ucast-hello-seqno: Expected unicast Hello sequence number of next Hello to be received from this neighbor. If unicast Hello packets are not expected, or processing of unicast packets is not enabled, this MUST be NULL. This is a 16-bit unsigned integer; if (We haven't defined "NULL" semantics yet.) Section 3.6 babel-route-neighbor: Reference to the babel-neighbors entry for the neighbor that advertised this route. Wouldn't that make this a "reference" type rather than "string"? babel-route-seqno: The sequence number with which this route was advertised. This is a 16-bit unsigned integer. Is this text correct for locally originated routes? Section 3.7 I don't wish to revisit the decision, but it might have been interesting to record some of the reasoning for having an additional abstraction for "key set" and having a list of key-sets, vs just having a list of keys directly. (Similarly for the DTLS cert sets.) Section 3.8 babel-mac-key-use-sign: Indicates whether this key value is used to sign sent Babel packets. Sent packets are signed using this key if the value is "true". If the value is "false", this key is not I agree with the secdir reviewer that the "sign" terminology is problematic here, and would prefer something like "babel-mac-key-use-generate" and a similar wording in the prose. babel-mac-key-value: The value of the MAC key. An implementation MUST NOT allow this parameter to be read. This can be done by always providing an empty string when read, or through permissions, or other means. This value MUST be provided when this instance is created, and is not subsequently writable. This value is of a length suitable for the associated babel-mac-key- algorithm. If the algorithm is based on the HMAC construction [RFC2104], the length MUST be between 0 and the block size of the underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. [Per the Discuss, this key-length guidance is not aligned with draft-ietf-babel-hmac.] babel-mac-key-test: An operation that allows the MAC key and hash algorithm to be tested to see if they produce an expected outcome. Input to this operation is a binary string. The implementation is expected to create a hash of this string using the babel-mac-key- value and the babel-mac-key-algorithm. The output of this operation is the resulting hash, as a binary string. s/create a hash of/create a MAC over/ s/resulting hash/resulting MAC value/ Given that the intent is to test the MAC operation, it seems like we might want to say that the input string is treated as a babel packet, getting the pseudo-header added per draft-ietf-babel-hmac §4.1, etc. It would be in keeping with cryptographic best practice to continue to use the same pseudo-header (and possibly even include a disambiguating context string) to avoid the risk of being an oracle for generating the MAC of arbitrary text that could then be used to forge other packets elsewhere. As the secdir review noted, the MAC output length is not necessarily fixed by the algorithm, so some indicatino of the output length is also in order. Section 3.10 babel-cert-name: A unique name for this DTLS certificate that can be used to identify the certificate in this object instance, since the value is too long to be useful for identification. This value Some guidance on whether or not it is expected to be useful to draw naming information from the certificate's Subject information, vs an arbitrary or fingerprint-based naming scheme, might be in order. Also, it's somewhat unusual to talk about "(D)TLS certificates" as opposed to X.509 certificate, raw public key, etc.. babel-cert-test: An operation that allows a hash of the provided input string to be created using the certificate public key and the SHA-256 hash algorithm. Input to this operation is a binary string. The output of this operation is the resulting hash, as a binary string. This is problematic in several ways, as noted by the secdir reviewer. For one, if we want to test a certificate, we usually would do that by producing a signature, not a hash over the public key and some other input. Furthermore, not all the signatures produced by X.509 certificates compatible with DTLS require a hash at all or are allowed to use SHA-256 within the signature operation. It may be possible to require SHA-256 always by having the input to the signature operation be the SHA-256 output, which would then be hashed again during the process of computing an (e.g., RSA) signature, but that is also a bit weird. The purpose of the operation needs to be made more clear (is it to verify the public key? The private key?) as well as how the input is structured; if the certificate private key is used to generate a signature we must take care to avoid producing a signing oracle that can be used to produce signatures valid in other contexts. Section 5 We do expose an operation to get a packet dump, but it's not clear that there are particularly noteworthy security considerations regarding that -- the dump would appear to be the ciphertext based on the language used, so it would not be a way to bypass DTLS encryption, for example. This information model defines objects that can allow credentials (for this device, for trusted devices, and for trusted certificate authorities) to be added and deleted. Public keys may be exposed through this model. This model requires that private keys never be It might be worth another sentence indicating the scale of the consequences of erroneously/maliciously setting such credentials. exposed. The Babel security mechanisms that make use of these credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) identify what credentials can be used with those mechanisms. The DTLS one really doesn't, though -- it says only something like "details of identity management are left to deployment profiles", and there's a wide variety of DTLS credentials that are possible. The MAC mechanism has a much clearer picture about what is allowed by virtue of using the raw crypto primitive (though the allowed MAC algorithms are negotiated out-of-band there as well). algorithm associated with the key. Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks. I don't think it's true to say that "keys that make use of only alphanumeric characters are highly susceptible to brute force attacks". Even if I stick to a 32-byte key, `dd if=/dev/random bs=1 count=24|openssl base64` is giving me 192 bits of randomness, which is plenty for a modern security protocol. I think you mean to say that short keys are especially susceptible to brute-force when they only use alphanumeric characters. Section 8.2 Per https://www.ietf.org/iesg/statement/normative-informative.html even optional features like DTLS, MAC, RFC 3339 timestasmps, etc., should be listed as normative references. From nobody Mon Nov 2 18:30:40 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882503A1354; Mon, 2 Nov 2020 18:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, 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 I5_ARopMxWH1; Mon, 2 Nov 2020 18:30:36 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 C16263A1352; Mon, 2 Nov 2020 18:30:36 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id t13so6867211ilp.2; Mon, 02 Nov 2020 18:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z4RR3Nbdphot5fDE7H5YuE0N3syxL4quc5hmNuhMlTE=; b=Uzrf/on/sPIQcpzgndhn9j6MeNmQFhj31IpDnNLHVAbE8Uu/E9MLFeEc07bj6JpKX8 GaZTpRw6gY6/KhP5AsCrq70BwokY3NHMFJZOYmADrDCJ4Iyrx5R4NmH59HNufRzutXIz IVrfPVseKM+GEPgFcwHhuUKE9UIRggw0P1u5UdnbzURAR9jzjGwJagmvxKC2W1YXt8ap vPzNq3YkPPI8RgNBuG9XTAH8/9VnA0gMqqwmshAhZn8wWrPvgHp36Hcdhd4QCctYr4g5 SGdHBHDiAxk7MCnuaexlj5K9xacV0tMHtc7oNiYqgbhwrjNp/HxoeC5cFkF1KmAlJzLV 0mRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z4RR3Nbdphot5fDE7H5YuE0N3syxL4quc5hmNuhMlTE=; b=cT1b0ItZsY5X2IDd7grx6iZqiTPcH+WKGR3jnZTFHDE75ZRxBUG+e/QggJBRy+YnjU S8qP7+2jc2D6C2Dci6BLXMfX3MnzYZ8zB6TlSMo02Vt7dszTuIdXXiZUgbGKa5dC5Xmh q9dvh0glnIeVIycf79Bvv6+XgOlcUMxGJGerkQ4VMPbh4En+8k30D6QO8l1Fr8+Nd9Ec eKDdyfEMZcPuqyIi/qT+8AZ9bNZ3G/eAYhLlRH77uWNzmxrmEpBYQVfUmgQRXVwDEi1G QncYOS9U3HzVdEYIfU1BNCAVJMeXWxef8DY0tPDdl1JEUCoin6NUWNEWjpFNxajTkWBG L/kg== X-Gm-Message-State: AOAM5317MGphFikUas88nVeBJJdG2x2fMwrMPFkCFkt6JDwTlpoUT4n2 m5CDpZGJnjMm0ZaAjmdzQbxlaM65+UqHBTjFAGtrDhqLQgk= X-Google-Smtp-Source: ABdhPJwGpUqAT7esIGE/0wrv97WZ8Z5BR3ZFapz//ymSMG997EmQA2BwdTkVS51R1JPfgJqDB90uPbWzkipboTCBQ8o= X-Received: by 2002:a92:d449:: with SMTP id r9mr2715266ilm.276.1604370635807; Mon, 02 Nov 2020 18:30:35 -0800 (PST) MIME-Version: 1.0 References: <87zh4mi6e2.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Mon, 2 Nov 2020 21:30:24 -0500 Message-ID: To: Babel at IETF Cc: babel-chairs Content-Type: multipart/alternative; boundary="000000000000d5e2ec05b32aa50f" Archived-At: Subject: [babel] Cancelled: Re: [Babel] IETF-109 online X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 02:30:39 -0000 --000000000000d5e2ec05b32aa50f Content-Type: text/plain; charset="UTF-8" Hi, No one has asked to present at the Babel WG meeting at the upcoming IETF meeting so I am cancelling it. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sat, Oct 17, 2020 at 11:44 PM Donald Eastlake wrote: > Hi Juliusz, > > Thanks for your message below. > > The Babel WG meeting has been tentatively scheduled for > UTC: Tuesday November 17th 07:30 to 08:30 > Bangkok time: Tuesday November 17th 14:30 to 15:30 > > However, at this point no one has requested to present and if there > aren't any requests in the next couple of weeks, the meeting will be > cancelled. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > On Fri, Oct 16, 2020 at 10:37 AM Juliusz Chroboczek wrote: > > > > Dear all, > > > > IETF-109 will be held online from 16 to 20 November. There might or > might > > not be a Babel meeting. > > > > They appear to have listened to our complaints, and requesting a fee > > waiver no longer requires slaughtering an immaculate goat over your > > keyboard. In order to participate for free, you need to: > > > > 1. Open an account on the IETF datatracker (unless you already have one): > > > > https://datatracker.ietf.org/accounts/create/ > > > > 2. Submit a waiver request on: > > > > https://www.ietf.org/forms/109-registration-fee-waiver/ > > > > I don't know how busy the secretariat is, but just in case, I would > > recommend doing that earlier rather than later. > > > > Regards, > > > > -- Juliusz > > > > _______________________________________________ > > Babel-users mailing list > > Babel-users@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users > --000000000000d5e2ec05b32aa50f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

No one has asked to present at the Babel WG meeting at the upco= ming IETF meeting so I am cancelling it.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. E= astlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, A= popka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Sat, Oct 17, 2020 at 11:44 P= M Donald Eastlake <d3e3e3@gmail.com<= /a>> wrote:
H= i Juliusz,

Thanks for your message below.

The Babel WG meeting has been tentatively scheduled for
UTC: Tuesday November 17th 07:30 to 08:30
Bangkok time: Tuesday November 17th 14:30 to 15:30

However, at this point no one has requested to present and if there
aren't any requests in the next couple of weeks, the meeting will be cancelled.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.co= m

On Fri, Oct 16, 2020 at 10:37 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> Dear all,
>
> IETF-109 will be held online from 16 to 20 November.=C2=A0 There might= or might
> not be a Babel meeting.
>
> They appear to have listened to our complaints, and requesting a fee > waiver no longer requires slaughtering an immaculate goat over your > keyboard.=C2=A0 In order to participate for free, you need to:
>
> 1. Open an account on the IETF datatracker (unless you already have on= e):
>
>=C2=A0 =C2=A0https://datatracker.ietf.org/accounts/= create/
>
> 2. Submit a waiver request on:
>
>=C2=A0 =C2=A0https://www.ietf.org/forms/1= 09-registration-fee-waiver/
>
> I don't know how busy the secretariat is, but just in case, I woul= d
> recommend doing that earlier rather than later.
>
> Regards,
>
> -- Juliusz
>
> _______________________________________________
> Babel-users mailing list
> Babel-users@alioth-lists.debian.net
> https://alioth-lists.debian= .net/cgi-bin/mailman/listinfo/babel-users
--000000000000d5e2ec05b32aa50f-- From nobody Tue Nov 3 07:11:53 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C210D3A0855; Tue, 3 Nov 2020 07:11:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <160441631177.15161.14360810315064872038@ietfa.amsl.com> Date: Tue, 03 Nov 2020 07:11:51 -0800 Archived-At: Subject: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 15:11:52 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am balloting DISCUSS because I believe that the document is missing important considerations/details related to the operation of Babel in a network. I hope these points should be easy to address. This draft describes destination-first forwarding. If I understand correctly, for the table in §4: destination source next-hop 2001:DB8:0:1::/64 ::/0 A ::/0 2001:DB8:0:2::/64 B ...and the example presented of a "source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57", the result is that the packet is forwarded to A. Is this the correct interpretation? If so, then I believe there are important assumptions made that are not mentioned. In line with this document being "applicable to small networks" (§1), BCP 84/§4.3 recommends the following: For smaller edge networks that use provider-based addressing and whose ISPs implement ingress filters (which they should do), the third option is to route traffic being sourced from a given provider's address space to that provider. Given that the draft provides no details, I assume that being "compatible with [BCP84]" (§1) means at least that Babel nodes aim to "route traffic being sourced from a given provider's address space to that provider". (a) While I understand the table above is just an example, it can be interpreted as indicating that B is the provider that assigned the 2001:DB8:0:2::/64 prefix. If traffic sourced from that prefix is sent to A, then there's a good chance that the packet will be dropped (in line with BCP 84, BCP 38, etc.). Maybe the table is not intended to illustrate the routing table at a multihomed edge router. Still, it shows how easy it is to define a policy that may not result in the expected behavior because of the destination-first operation. Please add some guidance on the advertisements and how they may interact in the routing table. Note that what I'm asking for may just be a good example of what to do/not to do. rfc8678/§5 presents an example of how the forwarding table is constructed based on a set of routes -- something like that would be great! (b) How is the source address selected by the host? rfc8678 uses guidance from rfc8028 and other RFCs as part of a set of "Mechanisms for Hosts To Choose Good Default Source Addresses in a Multihomed Site". rfc8678 significantly differs from this document in that it assumes source-first forwarding when discussing the selection of the source address. Are any of the recommendations in rfc8678 applicable here? I may be missing something, but it seems to me that the current standards-based recommendations/mechanisms don't easily apply to this specification. I don't think there's anything wrong with doing things a different way -- but I expect those differences to be explicitly explained. SS-ROUTING suggests a trial-and-error mechanism: for "destination addresses...the sending host tries them all...similarly, all possible source addresses are tried in turn." Is that the expectation here? Even though this document is about Babel and not the host, I would like to see a (short) discussion about how the host is expected to behave (or what it needs to consider) in light of the destination-first operation. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) §4 talks about "lower layers", what are those? Please be specific. (2) The second bullet in §4 says that "Babel...MUST either silently ignore any source-specific routes, or disambiguate..." Given the required (use of MUST) nature of the disambiguation, I would like to see an algorithm for it, not just an example. I do not include this point in the DISCUSS section because I think there are ways not to require disambiguation; perhaps something along the lines of: ...SHOULD silently ignore any source-specific routes. A router can also choose to use a disambiguation algorithm (see SS-ROUTING for an example), but the details are out of this document's scope. (3) §7.1: "Source Plen The length of the advertised source prefix." Indicate in bits. From nobody Tue Nov 3 13:42:05 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD1B3A120A; Tue, 3 Nov 2020 13:41:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <160443971755.21752.8598533003327960774@ietfa.amsl.com> Date: Tue, 03 Nov 2020 13:41:57 -0800 Archived-At: Subject: [babel] Alvaro Retana's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 21:42:00 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I want to revisit the question about including support for source-specific routing in the Information model. This topic came up already, but the discussion focused only on whether source-specific routing needed to be enabled or not, with one implementor mentioning that their implementation required it [1]. In addition to enabling the functionality, and because "most of the information model is focused on reporting Babel protocol operational state" (§1), I am interested in the reporting side. It seems to me that the incremental cost to add this support is trivial (as described in §3/draft-ietf-babel-source-specific: "Data Structures"). Why is source-specific routing not supported? I find it to be a significant omission, especially considering that the source-specific routing spec is in IESG Evaluation at the same time. [1] https://mailarchive.ietf.org/arch/msg/babel/F7tlCQk8IeTaHN_rKHbsoKF3urE/ From nobody Tue Nov 3 13:45:54 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594693A1213; Tue, 3 Nov 2020 13:45:48 -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, 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=toke.dk 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 WDmEj2A4D_nC; Tue, 3 Nov 2020 13:45:46 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 90D773A120E; Tue, 3 Nov 2020 13:45:44 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604439941; bh=BSqu/N6Qck9YU2QvO5y8NzMbQxEsW/cAiRSSA5JQRe8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TjSUj4uGaJqdVQKT2v6Hy213m6oW9a8CC7R1JasgQHELWuDlpcjDpMPhq/Tc3yg20 nKQOKQ/IyOE3PSK5TF671JQPYneW3UjwkG7le6+qHVMZrEtDGsH0pZaYLvJDjnsEbB 1ccgg7mrBNFqMzHHhuU6v7LcdlTprPLFyNTA7cfuSJp4tZbA1gu3wnwxjQ2uHSHvJU GDjUyYkoja02aV4zYT5PVBseT2UcmGz+2IimH37P/T47ZIPeJmW2fj86Cq2r7xnwDH BOQQMUwTY51Et0eYITwQvOJTDLIgygQUkPpM4aZyGgkDqjaFO9t2yrga8ix1+btxds ZV9g6C5E7CefA== To: Alvaro Retana , The IESG Cc: babel-chairs@ietf.org, Donald Eastlake , babel@ietf.org, draft-ietf-babel-source-specific@ietf.org In-Reply-To: <160441631177.15161.14360810315064872038@ietfa.amsl.com> References: <160441631177.15161.14360810315064872038@ietfa.amsl.com> Date: Tue, 03 Nov 2020 22:45:40 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87d00ujerf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 21:45:49 -0000 Alvaro Retana via Datatracker writes: > This draft describes destination-first forwarding. If I understand corre= ctly, > for the table in =C2=A74: > > destination source next-hop > 2001:DB8:0:1::/64 ::/0 A > ::/0 2001:DB8:0:2::/64 B [...] > ...and the example presented of a "source 2001:DB8:0:2::42 and destination > 2001:DB8:0:1::57", the result is that the packet is forwarded to A. Is t= his > the correct interpretation? Yes. > If so, then I believe there are important assumptions made that are > not mentioned. > > In line with this document being "applicable to small networks" (=C2=A71)= , BCP > 84/=C2=A74.3 recommends the following: > > For smaller edge networks that use provider-based addressing and > whose ISPs implement ingress filters (which they should do), the > third option is to route traffic being sourced from a given > provider's address space to that provider. > > Given that the draft provides no details, I assume that being "compatible= with > [BCP84]" (=C2=A71) means at least that Babel nodes aim to "route traffic = being > sourced from a given provider's address space to that provider". > > (a) While I understand the table above is just an example, it can be > interpreted as indicating that B is the provider that assigned the > 2001:DB8:0:2::/64 prefix. If traffic sourced from that prefix is sent to= A, > then there's a good chance that the packet will be dropped (in line with = BCP > 84, BCP 38, etc.). > > Maybe the table is not intended to illustrate the routing table at a mult= ihomed > edge router. It's not. Here's a bit of my real routing table (slightly altered to aid clarity of example), illustrating what a real multi-homing scenario would look like: default from 2a00:xxxx::/48 via fe80::feec:daff:fe55:4a3b dev eth1 proto bi= rd metric 32 pref medium default from 2a0c:yyyy::/48 via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bi= rd metric 32 pref medium 2a0c:yyyy::/64 via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bi= rd metric 32 pref medium 2a0c:yyyy:1::/64 via fe80::da58:d7ff:fe00:1d2b dev eth1 proto bi= rd metric 32 pref medium 2a00:xxxx::/64 via fe80::feec:daff:fe55:4a3b dev eth1 proto bi= rd metric 32 pref medium 2a00:xxxx:1::/64 via fe80::feec:daff:fe55:4a3b dev eth1 proto bi= rd metric 32 pref medium The first two default routes are from two different upstreams that have assigned me prefix 2a00:xxxx::/48 and 2a0c:yyyy::/48 respectively. For the "multi-homed ISP" scenario, the expectation is that an edge router will announce a default route (or something similarly broad) with a source prefix of the delegated prefix. This is absolutely compatible with BCP38; in fact it provides automatic BCP38 filtering at the first hop, since if a packet is spoofing its source address to something that is outside the assigned prefix, there will not be any valid route for that packet to reach the internet at all. The four other more-specific routes in the snippet above have no source prefix announced (like in the example in the draft); in this case, they come from the routers exporting the prefixes used by each of local their interfaces as separate routes to the local network. This means that a packet trying to reach a node on the local network would be routed directly to that router and on to the host, no matter it's source prefix, instead of going over the internet from ISP to ISP. This is obviously the correct behaviour in such a multi-homed scenario. > Still, it shows how easy it is to define a policy that may not result > in the expected behavior because of the destination-first operation. > Please add some guidance on the advertisements and how they may > interact in the routing table. > > Note that what I'm asking for may just be a good example of what to do/no= t to > do. rfc8678/=C2=A75 presents an example of how the forwarding table is c= onstructed > based on a set of routes -- something like that would be great! Since your concern seems to be related to a particular example of what the source-specific extension can be used for, mentioned in the introduction, I'm not sure I see how it would improve the document to write a whole bunch of text addressing this particular operational concern? I mean, the section you're quoting the example from (section 4) literally says that the choice of dest first / source first is arbitrary and all that is required is that it is consistent, before then going ahead and spelling out the choice. One small change in the introduction that may make this clearer, was to amend this sentence in the third paragraph of the introduction: "When using this technique in a network connected to multiple providers, every host is assigned multiple addresses, one per provider." to read something like: "When using this technique in a network connected to multiple providers, every host is assigned multiple addresses, one per provider, and each edge router exports a default route with a source prefix corresponding to the prefix delegated from its upstream." > (b) How is the source address selected by the host? [...] > Even though this document is about Babel and not the host, I would > like to see a (short) discussion about how the host is expected to > behave (or what it needs to consider) in light of the > destination-first operation. Juliusz can correct me if I'm wrong here, but I believe this is left out because it really doesn't matter. The host can pick source addresses however it likes, and packets will make their way to the right upstream (in the multi-homing scenario). -Toke From nobody Tue Nov 3 15:10:51 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618BC3A1294; Tue, 3 Nov 2020 15:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 P6MWN9zVX_W1; Tue, 3 Nov 2020 15:10:48 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 0D6243A1220; Tue, 3 Nov 2020 15:10:47 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A3N4Qjh013641; Tue, 3 Nov 2020 18:10:47 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 34hncq4p7r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Nov 2020 18:10:46 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A3NAkqq003363; Tue, 3 Nov 2020 18:10:46 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A3NAdrO003230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Nov 2020 18:10:39 -0500 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 228994009E6F; Tue, 3 Nov 2020 23:10:39 +0000 (GMT) Received: from GAALPA1MSGEX1CF.ITServices.sbc.com (unknown [135.50.89.113]) by zlp30486.vci.att.com (Service) with ESMTPS id 0D5704009E63; Tue, 3 Nov 2020 23:10:39 +0000 (GMT) Received: from GAALPA1MSGEX1CB.ITServices.sbc.com (135.50.89.109) by GAALPA1MSGEX1CF.ITServices.sbc.com (135.50.89.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Tue, 3 Nov 2020 18:10:38 -0500 Received: from GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) by GAALPA1MSGEX1CB.ITServices.sbc.com ([135.50.89.109]) with mapi id 15.01.2044.006; Tue, 3 Nov 2020 18:10:38 -0500 From: "STARK, BARBARA H" To: "'Barry Leiba'" , "'The IESG'" CC: "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'Donald Eastlake'" Thread-Topic: Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWr+9mGXz5hG4j3Ue0wjxxvMzJ1qm3DEQA Date: Tue, 3 Nov 2020 23:10:38 +0000 Message-ID: <183ee01e884f4c01aa7520b9ed48b061@att.com> References: <160419457047.13941.8784738161520575163@ietfa.amsl.com> In-Reply-To: <160419457047.13941.8784738161520575163@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.81.76] x-tm-snts-smtp: BF318B7DED39A7B69C9A8C4A576B4411F8A5802784B5C08470D535FC745FDBDE2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-03_16:2020-11-03, 2020-11-03 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 bulkscore=0 phishscore=0 malwarescore=0 adultscore=0 suspectscore=0 impostorscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=764 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011030152 Archived-At: Subject: Re: [babel] Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 23:10:49 -0000 SGkgQmFycnksDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBJJ2xsIG1ha2UgYm90aCBvZiB0aGUg Y2hhbmdlcyB5b3Ugc3VnZ2VzdC4NCkJhcmJhcmENCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1F TlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IEp1c3QgYSBjb3VwbGUgb2YgbWlub3IgY29tbWVu dHMgaGVyZToNCj4gDQo+IOKAlCBTZWN0aW9uIDEuMSDigJQNCj4gUGxlYXNlIHVzZSB0aGUgZXhh Y3QgQkNQIDE0IGJvaWxlcnBsYXRlIGZyb20gUkZDIDgxNzQuDQoNCkkgd2lsbCBjaGFuZ2UgdG8g dXNlIHRoZSBleGFjdCBCQ1AgMTQgYm9pbGVycGxhdGUuDQoNCj4g4oCUIFNlY3Rpb24gMS4yIOKA lA0KPiBGb3Ig4oCcZGF0ZXRpbWXigJ0sIEkgc3VnZ2VzdCBhZGRpbmcg4oCcU2VjdGlvbiA1Ljbi gJ0gdG8gdGhlIHJlZmVyZW5jZSB0byBSRkMgMzMzOSwNCj4gdG8NCj4gbWFrZSB0aGUgc3BlY2lm aWMgZm9ybWF0IGVhc2llciB0byBmaW5kLiAgQW5kIEkgdGhpbmsgdGhlIHVzZSBvZiAzMzM5IGlu IHRoZQ0KPiBkZWZpbml0aW9uIG9mIHRoZSB0eXBlIG1ha2VzIGl0IGEgbm9ybWF0aXZlIHJlZmVy ZW5jZS4NCg0KSSB3aWxsIGFkZCBTZWN0aW9uIDUuNiB0byB0aGUgUkZDIDMzMzkgcmVmZXJlbmNl Lg0KDQo+IFNpbWlsYXJseSwgdGhlIHVzZSBvZiBJU08uMTA2NDYgdG8gZGVmaW5lIOKAnHN0cmlu Z+KAnSBtYWtlcyBpdCBub3JtYXRpdmUuDQo+IA0KPiANCg0K From nobody Tue Nov 3 15:24:59 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40953A1114; Tue, 3 Nov 2020 15:24:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <160444589696.9348.17838097712934982658@ietfa.amsl.com> Date: Tue, 03 Nov 2020 15:24:56 -0800 Archived-At: Subject: [babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 23:24:57 -0000 Warren Kumari has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I apologize for being rushed, and not balloting earlier, but I feel like I must have missed something fundamental here. The example in Section 4 (Data Forwarding) illustrates an issue, but doesn't actually *state* which (A or B) next hop will be used. The text then says that: "A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering,". I interpret this to mean that the packet "with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57" should use next-hop A. This means that you will be sending the packet to the destination with no regard for if the provider connected to next-hop A carries/announces 2001:DB8:0:2::/64. If if it doesn't, this will look like a spoofing attack, and the ISP will (rightly) drop it. The only way that I can see this working is if: 1: destination routes never point "outside" the network (and so will never hit inbound BCP38 filters) or 2: destination routes always "match" - if you install x:y:z::/q pointing at next-hop A, you also install the same router pointing at next-hop B (this is pointless). Please help me understand what I'm missing here -- routing on destination to an ISP (which is what I'm assuming based on the "small networks" statement) seems like it will route packets with ISP B sources addresses to ISP A, running into BCP38/anti-spoofing filters. BCP84 also covers a number of scenarios - it sounds like you are referring to Section 4.3. Send Traffic Using a Provider Prefix Only to That Provider, but that is exactly what is not happening above. Again, I'm assuming that I'm just missing something blindingly obvious here, but it would be good to figure out what, so the document can be clarified and others don't fall into the same trap... From nobody Tue Nov 3 19:49:53 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1D73A13A1; Tue, 3 Nov 2020 19:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 EzWTvXJd6v5w; Tue, 3 Nov 2020 19:49:45 -0800 (PST) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 3264B3A139B; Tue, 3 Nov 2020 19:49:45 -0800 (PST) Received: by mail-vk1-f171.google.com with SMTP id q77so768645vkq.1; Tue, 03 Nov 2020 19:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oCbuFmWg7WWQvpY3UjU1rtdr03aBaxg1MMxaVy68FSA=; b=N0fs5Phyy9Gtb+G6Y7i85Cu2Te16ofZM0TqlUWflxO0uW+k3ONVbTMYructZbmFw4W /I/2XyzC6XXK7rh/qFZDqyralm71NsbMf5FpUGx9skMyUb7Uq7EOnHngfP5YvjuA3xc2 6+r4vvFUlXjXaxkViMhRWtsLDXoqeO5D/EPWFzW2oVT2UtMDvrzZeuuUK3vXqebTiyW0 eVeFu0+AVxYVsVaAWT58vTePXmASWuT13T3j+BMCWkUaaiykVNDMszcbfbuSrV6hWNLk iPTrRotBhA6tiy2bS54hx2r8mNMErxLIutun0WyBQrp2SIqfKuvsgj2/ZEJjN2yHeo6T h5QQ== X-Gm-Message-State: AOAM531onVxbiICaChh0A5MuY2lRrxVcygWDfC2She2XFtq36AUTyU5n tNfnl5vvYn1svn+OrhqQYyUGtqnNpscCjjKg/Ls= X-Google-Smtp-Source: ABdhPJwZGcbhjZpEjFBK5URGY28gJDQyeHp2y9YlOK60JB4ifSxtDxvr5bmqHdgBq/qndogwF1w32zbei/aLp8bIo5Y= X-Received: by 2002:a1f:2ad0:: with SMTP id q199mr19031214vkq.20.1604461783951; Tue, 03 Nov 2020 19:49:43 -0800 (PST) MIME-Version: 1.0 References: <160419457047.13941.8784738161520575163@ietfa.amsl.com> <183ee01e884f4c01aa7520b9ed48b061@att.com> In-Reply-To: <183ee01e884f4c01aa7520b9ed48b061@att.com> From: Barry Leiba Date: Tue, 3 Nov 2020 22:49:32 -0500 Message-ID: To: "STARK, BARBARA H" Cc: Donald Eastlake , The IESG , "babel-chairs@ietf.org" , "babel@ietf.org" , "draft-ietf-babel-information-model@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b02f3405b33fde36" Archived-At: Subject: Re: [babel] Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 03:49:47 -0000 --000000000000b02f3405b33fde36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Barbara. Barry On Tue, Nov 3, 2020 at 6:11 PM STARK, BARBARA H wrote: > Hi Barry, > Thanks for your review. I'll make both of the changes you suggest. > Barbara > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Just a couple of minor comments here: > > > > =E2=80=94 Section 1.1 =E2=80=94 > > Please use the exact BCP 14 boilerplate from RFC 8174. > > I will change to use the exact BCP 14 boilerplate. > > > =E2=80=94 Section 1.2 =E2=80=94 > > For =E2=80=9Cdatetime=E2=80=9D, I suggest adding =E2=80=9CSection 5.6= =E2=80=9D to the reference to RFC > 3339, > > to > > make the specific format easier to find. And I think the use of 3339 i= n > the > > definition of the type makes it a normative reference. > > I will add Section 5.6 to the RFC 3339 reference. > > > Similarly, the use of ISO.10646 to define =E2=80=9Cstring=E2=80=9D make= s it normative. > > > > > > --000000000000b02f3405b33fde36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Barbara.

Barry

On Tue, Nov 3, 2020 at 6:11 PM STARK, BARBARA H <bs7652@att.com> wrote:
Hi Barry,
Thanks for your review. I'll make both of the changes you suggest.
Barbara

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Just a couple of minor comments here:
>
> =E2=80=94 Section 1.1 =E2=80=94
> Please use the exact BCP 14 boilerplate from RFC 8174.

I will change to use the exact BCP 14 boilerplate.

> =E2=80=94 Section 1.2 =E2=80=94
> For =E2=80=9Cdatetime=E2=80=9D, I suggest adding =E2=80=9CSection 5.6= =E2=80=9D to the reference to RFC 3339,
> to
> make the specific format easier to find.=C2=A0 And I think the use of = 3339 in the
> definition of the type makes it a normative reference.

I will add Section 5.6 to the RFC 3339 reference.

> Similarly, the use of ISO.10646 to define =E2=80=9Cstring=E2=80=9D mak= es it normative.
>
>

--000000000000b02f3405b33fde36-- From nobody Tue Nov 3 22:43:50 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8323D3A09FC; Tue, 3 Nov 2020 22:43:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160447222149.25425.9921856923705203834@ietfa.amsl.com> Date: Tue, 03 Nov 2020 22:43:41 -0800 Archived-At: Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 06:43:42 -0000 Erik Kline has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 3.1 ] * s/running and operational/running any operational/? From nobody Wed Nov 4 01:55:21 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9C3A0E2D; Wed, 4 Nov 2020 01:55:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160448371881.21438.10396700174694695891@ietfa.amsl.com> Date: Wed, 04 Nov 2020 01:55:18 -0800 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-information-model-11=3A_=28with_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 09:55:19 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and some nits. I also second Alvaro's question about the source-routing component. I hope that this helps to improve the document, Regards, -éric == COMMENTS == I have a slight concern that draft-ietf-babel-yang-model is not reviewed at the same time as the information model but, at least, they will be reviewed in the right order ;-) -- Section 3 -- For an informational document, I wonder whether the use of normative "MAY" is required. -- Section 3.2 -- About the UDP port, should the Babel default be part of the information model description ? I would prefer to leave it to the protocol specifications. Same remark applies to other objects/properties when the Babel default value is repeated in the information model. What is the usefulness of repeating it ? == NITS == -- Section 2 -- It is probably a matter of taste ;-) but I do not like too much the fact that all the objects names start with "babel-" as it is implicit. From nobody Wed Nov 4 03:27:37 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23D3A0FCF; Wed, 4 Nov 2020 03:27:36 -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, 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=toke.dk 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 S_n2TxS_bCkh; Wed, 4 Nov 2020 03:27:34 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 072C43A0D6C; Wed, 4 Nov 2020 03:27:31 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604489249; bh=ZLmbCbvyw4TdKjosPRlJ6sN7fcqFar2i6WmoA4iYTLU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=dzS/IMeIAM9Pl3X54EbFiKCTF0juom7gV+CSSrvJvEWaLMxfjVUzvhje6r7oeE3WH RV740itqhOrpiXl1CVvZ3w3uSLBjKg2xYR9rP29tJQ/eLIF4aHDZWb3N1024HIiQo1 zom3BoBcvMcQCjnacDLcuZqXhRRSgoF/N1ovn4uVY13/r/jlz2OV19hh8gRWeTvDTB dgo3ScYxm//dL+it0D5iV6kRVEuIqO7iBI8U4i2IinAeSqPyXwzrFZMsu+/Aeb1zY1 y85XL0KbahYkNZQPkBCZwF6xRyBehTB7oIqTev86AuBFFpWNg3NJorz/9sTrcDrC11 sBeV/yA5KBPnQ== To: Warren Kumari , The IESG Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, draft-ietf-babel-source-specific@ietf.org In-Reply-To: <160444589696.9348.17838097712934982658@ietfa.amsl.com> References: <160444589696.9348.17838097712934982658@ietfa.amsl.com> Date: Wed, 04 Nov 2020 12:27:27 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wnz1uzts.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 11:27:36 -0000 Warren Kumari via Datatracker writes: > Warren Kumari has entered the following ballot position for > draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I apologize for being rushed, and not balloting earlier, but I feel like I must > have missed something fundamental here. > > The example in Section 4 (Data Forwarding) illustrates an issue, but doesn't > actually *state* which (A or B) next hop will be used. The text then says that: > "A Babel implementation MUST choose routing table entries by using the > so-called destination-first ordering,". I interpret this to mean that the > packet "with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57" should > use next-hop A. This means that you will be sending the packet to the > destination with no regard for if the provider connected to next-hop A > carries/announces 2001:DB8:0:2::/64. If if it doesn't, this will look like a > spoofing attack, and the ISP will (rightly) drop it. > > The only way that I can see this working is if: > 1: destination routes never point "outside" the network (and so will never hit > inbound BCP38 filters) or 2: destination routes always "match" - if you install > x:y:z::/q pointing at next-hop A, you also install the same router pointing at > next-hop B (this is pointless). > > Please help me understand what I'm missing here -- routing on destination to an > ISP (which is what I'm assuming based on the "small networks" statement) seems > like it will route packets with ISP B sources addresses to ISP A, running into > BCP38/anti-spoofing filters. BCP84 also covers a number of scenarios - it > sounds like you are referring to Section 4.3. Send Traffic Using a Provider > Prefix Only to That Provider, but that is exactly what is not happening above. > > Again, I'm assuming that I'm just missing something blindingly obvious here, > but it would be good to figure out what, so the document can be clarified and > others don't fall into the same trap... Please see my reply to Alvaro, where I describe how the multi-provider use case is supposed to work: https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/ -Toke From nobody Wed Nov 4 03:53:38 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC953A1026; Wed, 4 Nov 2020 03:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=att.onmicrosoft.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 Wc0qmbCr9RYf; Wed, 4 Nov 2020 03:53:30 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 7CA483A101F; Wed, 4 Nov 2020 03:53:30 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A4BiIeI024731; Wed, 4 Nov 2020 06:53:29 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 34kd6bbtfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 06:53:28 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4BrRF1004800; Wed, 4 Nov 2020 06:53:27 -0500 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4BrPhv004791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 06:53:25 -0500 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id 247F1400AE34; Wed, 4 Nov 2020 11:53:25 +0000 (GMT) Received: from MISOUT7MSGED1AA.ITServices.sbc.com (unknown [135.66.184.195]) by zlp27130.vci.att.com (Service) with ESMTPS id 0B9FD4000537; Wed, 4 Nov 2020 11:53:25 +0000 (GMT) Received: from MISOUT7MSGED1BC.ITServices.sbc.com (135.66.184.196) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 06:53:24 -0500 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGED1BC.ITServices.sbc.com (135.66.184.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 06:53:24 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 06:53:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JeGJBDm1/x6byiQew4UsskUu98PRC/dtGie8dBaKQMvxNm1o++Azcz3zn5FiM60jarwIwZp8PPVgYQklPdBMfqub2XUwYpwUhxc+0vfSATCqORD77hr0gvbr7QR0cLPifHBjdkKyiq/0qdCUqywsIiQzqXjF9bfn1qK6PnjF1HF1NGvZAPrIB/fc0apC2suSYZ0QXqkbmxHc+lvxX2nQiuN+SArv4N00w1R/4cm9LQW9rFThv+jF9gEZNRso5mrKekKXe89iFp+ibMpYLcqi98lZG+2Na+/QxGFjcdT9uWmD/3ehOTlzAarUBxowNnuX8LDoRLrkrlIRwWwlhr5sPw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o4l1b0HfsY321O8n87xO1GZuWtHHWZaG5zUiGKncWW0=; b=hJqYhYp00ntRmubDBSRmgN7KKp7oYYkd4xSd+ERQ4t8NJn3GRVyizJmTp05k4nimsItK0EFhB6CkOix3gDtxgHUb4y+77q9e2dYvtNpsQivUgr9xedNEj7umgQBJ/vrixfbyGfIlfpI5jZctWEclVd+QQ09lTZUNY/c8/249GRmUsU6jI9Orm6krMWvOrsfXfWsyOKY6n/YwUyhcfXBZ0Zf/fTE3hzkDNgATASI7NO08EfSqamGOBfYis28nt/sl/GXcr/62/Jay6xXyL24BNKY0df9LBPfs7X6NVHKNpSsUxmuKWlKSHFrg12c5UFQ2NrEnTvJ5aIsb05xW8hJqAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o4l1b0HfsY321O8n87xO1GZuWtHHWZaG5zUiGKncWW0=; b=U+MKHu06xAmz8XYh5LbsX9W5PZ6+yQ6owU+RALyoCKcjthlLQ/WDg3yhyxmxNG59qAArr85gdDDISclNOGLmP6+hXJV+1qVAvgCtW30B0CPZzH873h3KTwrrDueGrFP+6I4LI3DawXLsxK15xHY9IOXX0Pg1CriOf0pbQQJA49M= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN1PR02MB3888.namprd02.prod.outlook.com (2603:10b6:802:24::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 11:53:23 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 11:53:23 +0000 From: "STARK, BARBARA H" To: "'Barry Leiba'" CC: "'Donald Eastlake'" , "'The IESG'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model@ietf.org'" Thread-Topic: Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWr+9mGXz5hG4j3Ue0wjxxvMzJ1qm3DEQAgABO3wCAAIaE4A== Date: Wed, 4 Nov 2020 11:53:22 +0000 Message-ID: References: <160419457047.13941.8784738161520575163@ietfa.amsl.com> <183ee01e884f4c01aa7520b9ed48b061@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.109] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15be76d9-9607-4ea1-634a-08d880b83b66 x-ms-traffictypediagnostic: SN1PR02MB3888: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Aa7a9nUaM+9QPnowN4xFq1UCeEiinCeq75bnmxrl/4gNAy2vpRHsJKrWwgFh3fYU7UCHQ5hl45adgOlSPAVj4MB7THIoe1HsmDzjJODFuBUqdAq9IyCsF7ySPwXccM0B34uGgG7OOkZBH6VBPAOB2hXTk08yOk1fzYsHIv/Tvpy2PjI/5LpjoadFbLJr/JjBUDu4Ufidi15lsQa/DJbZswlqdJukHUfeqYpRfx0YGtezx7JWjySxW+wz+ql9sNK89IdUuJi+4+m2BCY5qGikLMHO+6nMqI0b+apWS4sZvvTxnXxEakfenvK7+cAbWZXL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39850400004)(366004)(346002)(376002)(396003)(66946007)(66476007)(86362001)(316002)(64756008)(76116006)(2906002)(54906003)(66556008)(186003)(8676002)(66446008)(26005)(478600001)(5660300002)(52536014)(4326008)(33656002)(53546011)(9686003)(82202003)(6506007)(7696005)(55016002)(8936002)(71200400001)(6916009)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: HpLMV7irnpgjdCIhhIApH3q3oeyj4YUF0GuHL9f+EVo+dza6vO4u+MTtEvLLfkCdGD8sl0vWl8zhdYfJ6d0rjBofXCuZE4dqbjO+yypKHtg7Mnef9xyRprRo5llJ17DvI8ywpNLdFW+v/riNjYZ5fLMUT2s0ueZaw5b9iYqLn0KMbuVQc4sGGOuHhOThiSvLfpjkpZXOnanEMBn3gKnsLqMTd3NoW0NW0lMOiGfR1kTio7L1cHxK5DWQm/LkG3d7wQZKKGHv1dFI08juXQEFVaCH0cXw5g5k1rD1q5eNT+Id/ApiZWW8iFHUiJZCmZuD14OsjQ333qea5NnTkpVKWANpg8bOLAySHCCjgjYBZ9+2eR/pUmL7Go2YawX8HhCgmHFVuQDitKpqQAt3TSRVSOaawW0PQJvhViOFx7qHwsG0YDb15/1+OaXLsn0tX+ygigRX+FexMxuPHIJy+qx8ygRwbFDTAz9puXaxBmB12re2hJcsGz11i+VbsKufUnh44PMOQEaNgsqhoUAkjVuFAJAcRa7sXzcipJiLduniKA0irn2nkjvsvytHspbobN9EcmAhi8P1DBBOqCrDznF1Li9/DKrxnNnEir+vYWUwAVPMFFAwGQuj+iFY69NM1/rieCK+HGdY37Th1m1HOkkeqQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR02MB4512E632E24C2599484CD1FDC3EF0SN6PR02MB4512namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15be76d9-9607-4ea1-634a-08d880b83b66 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 11:53:23.0169 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C4Pc/Ft25vry+Y5pjG8PG3DT/obqsfS/MqFuIa0Q6c+wOW/4J71kilaG4Cu6B+2C X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB3888 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 11BDCCEFEBD499DA5E9E86E848F3F815725EA86D42D8C8C6857152F29D6FE03E2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_08:2020-11-04, 2020-11-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 clxscore=1015 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040088 Archived-At: Subject: Re: [babel] Barry Leiba's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 11:53:32 -0000 --_000_SN6PR02MB4512E632E24C2599484CD1FDC3EF0SN6PR02MB4512namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5kIEkgcmVhbGl6ZSB5b3UgdGhhbmtlZCBtZSB0b28gc29vbi4gSSBtaXNzZWQgdGhlIGNvbW1l bnQgdGhhdCBSRkMzMzM5IGFuZCBJU08uMTA2NDYgbmVlZGVkIHRvIGJlIG1vdmVkIGZyb20gaW5m b3JtYXRpdmUgdG8gbm9ybWF0aXZlLiBJ4oCZbGwgZG8gdGhhdCB0b28uDQpUaHggYWdhaW4sDQpC YXJiYXJhDQoNClRoYW5rcywgQmFyYmFyYS4NCg0KQmFycnkNCg0KT24gVHVlLCBOb3YgMywgMjAy MCBhdCA2OjExIFBNIFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPG1haWx0bzpiczc2 NTJAYXR0LmNvbT4+IHdyb3RlOg0KSGkgQmFycnksDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBJ J2xsIG1ha2UgYm90aCBvZiB0aGUgY2hhbmdlcyB5b3Ugc3VnZ2VzdC4NCkJhcmJhcmENCg0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj4gSnVzdCBhIGNv dXBsZSBvZiBtaW5vciBjb21tZW50cyBoZXJlOg0KPg0KPiDigJQgU2VjdGlvbiAxLjEg4oCUDQo+ IFBsZWFzZSB1c2UgdGhlIGV4YWN0IEJDUCAxNCBib2lsZXJwbGF0ZSBmcm9tIFJGQyA4MTc0Lg0K DQpJIHdpbGwgY2hhbmdlIHRvIHVzZSB0aGUgZXhhY3QgQkNQIDE0IGJvaWxlcnBsYXRlLg0KDQo+ IOKAlCBTZWN0aW9uIDEuMiDigJQNCj4gRm9yIOKAnGRhdGV0aW1l4oCdLCBJIHN1Z2dlc3QgYWRk aW5nIOKAnFNlY3Rpb24gNS424oCdIHRvIHRoZSByZWZlcmVuY2UgdG8gUkZDIDMzMzksDQo+IHRv DQo+IG1ha2UgdGhlIHNwZWNpZmljIGZvcm1hdCBlYXNpZXIgdG8gZmluZC4gIEFuZCBJIHRoaW5r IHRoZSB1c2Ugb2YgMzMzOSBpbiB0aGUNCj4gZGVmaW5pdGlvbiBvZiB0aGUgdHlwZSBtYWtlcyBp dCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UuDQoNCkkgd2lsbCBhZGQgU2VjdGlvbiA1LjYgdG8gdGhl IFJGQyAzMzM5IHJlZmVyZW5jZS4NCg0KPiBTaW1pbGFybHksIHRoZSB1c2Ugb2YgSVNPLjEwNjQ2 IHRvIGRlZmluZSDigJxzdHJpbmfigJ0gbWFrZXMgaXQgbm9ybWF0aXZlLg0KPg0KPg0K --_000_SN6PR02MB4512E632E24C2599484CD1FDC3EF0SN6PR02MB4512namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDZCMjZFLkNCQTU4RjYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVh bjwvdzpTcGVsbGluZ1N0YXRlPg0KPHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9j dW1lbnRLaW5kPg0KPHc6VHJhY2tNb3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52 ZWxvcGVWaXMvPg0KPHc6VmFsaWRhdGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZh bGlkPmZhbHNlPC93OlNhdmVJZlhNTEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFs c2U8L3c6SWdub3JlTWl4ZWRDb250ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5m YWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0K PHc6TGlkVGhlbWVPdGhlcj5FTi1VUzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lh bj5YLU5PTkU8L3c6TGlkVGhlbWVBc2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5P TkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90 RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNuYXBUb0dy aWRJbkNlbGwvPg0KPHc6V3JhcFRleHRXaXRoUHVuY3QvPg0KPHc6VXNlQXNpYW5CcmVha1J1bGVz Lz4NCjx3OkRvbnRHcm93QXV0b2ZpdC8+DQo8dzpTcGxpdFBnQnJlYWtBbmRQYXJhTWFyay8+DQo8 dzpFbmFibGVPcGVuVHlwZUtlcm5pbmcvPg0KPHc6RG9udEZsaXBNaXJyb3JJbmRlbnRzLz4NCjx3 Ok92ZXJyaWRlVGFibGVTdHlsZUhwcy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4N CjxtOm1hdGhGb250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVm b3JlIi8+DQo8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFs PSJvZmYiLz4NCjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdp biBtOnZhbD0iMCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5k ZW50IG06dmFsPSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxp bSBtOnZhbD0idW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZM b2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRl bj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxl Q291bnQ9IjM3NyI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAi IFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGlu ZyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJo ZWFkaW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5h bWU9ImhlYWRpbmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImluZGV4IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJpbmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5k ZXggOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJ0b2MgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIz OSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9j IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ik5vcm1hbCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iaGVhZGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJpbmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBv ZiBmaWd1cmVzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImZvb3Rub3RlIHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJl ZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJl ZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i bWFjcm8iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 Ikxpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iTGlzdCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJC b2R5IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxp c3QgQ29udGludWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikxpc3QgQ29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRl ciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlv biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJv ZHkgVGV4dCBGaXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZp cnN0IEluZGVudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5 IFRleHQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IkJsb2NrIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRy dWUiIE5hbWU9IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IkUtbWFpbCBTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9y bSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFj cm9ueW0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IkhUTUwgS2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0 ZWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFi bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiBzdWJqZWN0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ik5vIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iT3V0bGluZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2lt cGxlIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iVGFibGUgU2ltcGxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUg Q2xhc3NpYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i VGFibGUgQ2xhc3NpYyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbG9yZnVsIDEi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENv bHVtbnMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIENvbHVtbnMgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIEdyaWQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDMiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRh YmxlIEdyaWQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IEdyaWQgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDEiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExp c3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgTGlzdCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3Qg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDciLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg TmFtZT0iVGFibGUgTGlzdCA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVj dHMgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIENvbnRlbXBvcmFyeSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBFbGVnYW50 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFByb2Zlc3Npb25hbCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBTdWJ0bGUgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBT dWJ0bGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBXZWIgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJUYWJsZSBXZWIgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCYWxsb29uIFRl eHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9 IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBOYW1lPSJQbGFjZWhvbGRlciBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vIFNwYWNpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0 IFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEi IE5hbWU9IkxpZ2h0IExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlk IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9 IkRhcmsgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hh ZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNo YWRpbmcgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IE5hbWU9IlJldmlzaW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM0IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJMaXN0IFBhcmFncmFwaCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i UXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzAiIFFG b3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUXVvdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1 bSBHcmlkIDEgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9 IkRhcmsgTGlzdCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBB Y2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIg TmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlz dCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFt ZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJM aWdodCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2Vu dCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1l PSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAzIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlz dCAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9 IkNvbG9yZnVsIExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcg QWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEi IE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1l ZGl1bSBMaXN0IDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5h bWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGlu ZyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBB Y2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdy aWQgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1 bCBTaGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2Vu dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1l PSJMaWdodCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2Vu dCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1l PSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJN ZWRpdW0gR3JpZCAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9 IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDYiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdy aWQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i MTkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iSW50 ZW5zZSBFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i SW50ZW5zZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzMiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkJvb2sgVGl0bGUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzciIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJUT0MgSGVhZGluZyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MSIgTmFtZT0iUGxhaW4gVGFibGUgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MiIgTmFtZT0iUGxh aW4gVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 MyIgTmFtZT0iUGxhaW4gVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NCIgTmFtZT0iUGxhaW4gVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NSIgTmFtZT0iUGxhaW4gVGFibGUgNSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MCIgTmFtZT0iR3JpZCBUYWJsZSBM aWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFt ZT0iR3JpZCBUYWJsZSAxIExpZ2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlk IFRhYmxlIDUgRGFyayIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQg VGFibGUgMSBMaWdodCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5h bWU9IkdyaWQgVGFibGUgNCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRh YmxlIDEgTGlnaHQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1l PSJHcmlkIFRhYmxlIDQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxl IDYgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJs ZSAxIExpZ2h0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0i R3JpZCBUYWJsZSA0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2 IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg MSBMaWdodCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikdy aWQgVGFibGUgNCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEg TGlnaHQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlk IFRhYmxlIDQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29s b3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExp Z2h0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBU YWJsZSA0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9y ZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdo dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFi bGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9 Ikxpc3QgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNj ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h bWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50 IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9 Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l PSJMaXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAy Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJM aXN0IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlz dCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i TGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3Qg VGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxp c3QgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3Qg VGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRh YmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA1Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0 IFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRh YmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJs ZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBU YWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJs ZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik1lbnRpb24iLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iU21hcnQgSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Ikhhc2h0YWciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVW5yZXNvbHZlZCBNZW50aW9uIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlNtYXJ0IExpbmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i U21hcnQgTGluayBFcnJvciIvPg0KPC93OkxhdGVudFN0eWxlcz4NCjwveG1sPjwhW2VuZGlmXS0t PjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7DQoJ bXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnJvbWFuOw0KCW1z by1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODY5MTIxIDEx MDczMDU3MjcgMzM1NTQ0MzIgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNl dDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZh cmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU4ODgxIC0xMDczNzMyNDg1IDkgMCA1 MTEgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9y bWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLW5vc2hvdzp5 ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCXRleHQtdW5kZXJsaW5lOnNpbmdsZTt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpu bzsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t aGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVy LW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5 bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1z dHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJ bXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1h bHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJh LW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQo8L3N0eWxl PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTtt c28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPkFuZCBJIHJlYWxpemUgeW91IHRoYW5rZWQgbWUgdG9vIHNv b24uIEkgbWlzc2VkIHRoZSBjb21tZW50IHRoYXQgUkZDMzMzOSBhbmQNCiBJU08uMTA2NDYgbmVl ZGVkIHRvIGJlIG1vdmVkIGZyb20gaW5mb3JtYXRpdmUgdG8gbm9ybWF0aXZlLiBJ4oCZbGwgZG8g dGhhdCB0b28uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O21zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWls eTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+VGh4IGFnYWluLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDttc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPkJhcmJhcmE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWhhbnNpLWZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLCBCYXJi YXJhLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5CYXJyeTxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPk9uIFR1ZSwgTm92IDMsIDIwMjAgYXQgNjoxMSBQTSBTVEFSSywg QkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iPmJzNzY1MkBhdHQu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7bXNvLWJvcmRlci1sZWZ0LWFsdDpzb2xpZCAjQ0NDQ0NDIC43NXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9 IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSBCYXJy eSw8YnI+DQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBJJ2xsIG1ha2UgYm90aCBvZiB0aGUgY2hh bmdlcyB5b3Ugc3VnZ2VzdC48YnI+DQpCYXJiYXJhPGJyPg0KPGJyPg0KJmd0OyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KJmd0OyBDT01NRU5UOjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsg PGJyPg0KJmd0OyBKdXN0IGEgY291cGxlIG9mIG1pbm9yIGNvbW1lbnRzIGhlcmU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IOKAlCBTZWN0aW9uIDEuMSDigJQ8YnI+DQomZ3Q7IFBsZWFzZSB1c2UgdGhl IGV4YWN0IEJDUCAxNCBib2lsZXJwbGF0ZSBmcm9tIFJGQyA4MTc0Ljxicj4NCjxicj4NCkkgd2ls bCBjaGFuZ2UgdG8gdXNlIHRoZSBleGFjdCBCQ1AgMTQgYm9pbGVycGxhdGUuPGJyPg0KPGJyPg0K Jmd0OyDigJQgU2VjdGlvbiAxLjIg4oCUPGJyPg0KJmd0OyBGb3Ig4oCcZGF0ZXRpbWXigJ0sIEkg c3VnZ2VzdCBhZGRpbmcg4oCcU2VjdGlvbiA1LjbigJ0gdG8gdGhlIHJlZmVyZW5jZSB0byBSRkMg MzMzOSw8YnI+DQomZ3Q7IHRvPGJyPg0KJmd0OyBtYWtlIHRoZSBzcGVjaWZpYyBmb3JtYXQgZWFz aWVyIHRvIGZpbmQuJm5ic3A7IEFuZCBJIHRoaW5rIHRoZSB1c2Ugb2YgMzMzOSBpbiB0aGU8YnI+ DQomZ3Q7IGRlZmluaXRpb24gb2YgdGhlIHR5cGUgbWFrZXMgaXQgYSBub3JtYXRpdmUgcmVmZXJl bmNlLjxicj4NCjxicj4NCkkgd2lsbCBhZGQgU2VjdGlvbiA1LjYgdG8gdGhlIFJGQyAzMzM5IHJl ZmVyZW5jZS48YnI+DQo8YnI+DQomZ3Q7IFNpbWlsYXJseSwgdGhlIHVzZSBvZiBJU08uMTA2NDYg dG8gZGVmaW5lIOKAnHN0cmluZ+KAnSBtYWtlcyBpdCBub3JtYXRpdmUuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR02MB4512E632E24C2599484CD1FDC3EF0SN6PR02MB4512namp_-- From nobody Wed Nov 4 09:23:17 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB6D3A1388; Wed, 4 Nov 2020 09:23:13 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FvGd8tvLDrze; Wed, 4 Nov 2020 09:23:11 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 122D03A0E9F; Wed, 4 Nov 2020 09:23:10 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id j24so30796861ejc.11; Wed, 04 Nov 2020 09:23:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=ony5ky7z99aI/y2jMxUuTCXNwVH15S3yxcRPBrLG7Y8=; b=c36oexOw0KQKFpITSuhjtEXoc7qASlxU0D1M2TQ/ljuDn6g86Hiwr7/QX8fGzNPowg HZOv+leFQ2PpV14yWWrqbyZ/CXgif0XXvTw7i5hDqlGDhH9diZApmWWBtQOni0N7nmai zVa2tQ7ZDB+thGWuRGn3oXLV2BX/I0pz4vAol69DiU+WG3Yks1Fn07ihFfUZg39a6RxX ZeikE1BCux8tKmVQ/wvDlY4gzkHlwPCrxD9f2R+Y8BQ/URSWgYj2EQolZKCIuyK3B1fl jM4SiBvL15WThnJJZ9zpc/eYwCdAVcWbMjUTGzSbCFhyEsUSlGOOxQWBjGv5h5QYGsQG aAhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=ony5ky7z99aI/y2jMxUuTCXNwVH15S3yxcRPBrLG7Y8=; b=GApTYsxXzeXoP8DFd30nmpUaa+H6SiepB3o2UOxoWx+nh7FkoCmMLeozmxPXDDEnYz UzOcrfxP0VMwI7riYB1Bogn5Dp93nOx3/5lpNKG3dHarmighYRJ2L0OyjUw4oIbtQxQp N3Y6xsXmbgGfUVHXnDPNuAp2nYDmCb53ed91UL1wR+9DC1wgqhl+IEWGICEvUeyLVFOn 6u3EJyGP1LD85ZytxiuOIDTcLlfVfQ1Cpo/PdOPx3f0U6AWFTrmmUyfi73+y2exN6AAM yTbZ3R8u8pYGvghcNinl62p+UCIGCJHKzFcs4dwe2TWeKRZtP4EY+9qC05N9NxYnr/aD 8K0Q== X-Gm-Message-State: AOAM531C4nSbDp/2kecXi2jgCemuGCvvsYUwNpEhHO5GAz7QkA4fl1Ah 4PYjbqTK/ILjqPIUzk0GIqMsp+N4bPJr7OF1bNssIbDsRxI= X-Google-Smtp-Source: ABdhPJwD3mg71sSxb/wWmjzV/t4Aq/hB6ukMPCuibWB0FmkU+H3T2xAt5rgv+vHKMN5LNxoLaznDAnfLT1IIYCidroY= X-Received: by 2002:a17:907:2166:: with SMTP id rl6mr14464265ejb.61.1604510589267; Wed, 04 Nov 2020 09:23:09 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 4 Nov 2020 12:23:08 -0500 From: Alvaro Retana In-Reply-To: <87d00ujerf.fsf@toke.dk> References: <160441631177.15161.14360810315064872038@ietfa.amsl.com> <87d00ujerf.fsf@toke.dk> MIME-Version: 1.0 Date: Wed, 4 Nov 2020 12:23:08 -0500 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , The IESG Cc: draft-ietf-babel-source-specific@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 17:23:13 -0000 On November 3, 2020 at 4:45:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: Toke: Hi! > Alvaro Retana via Datatracker writes: > ... > > Still, it shows how easy it is to define a policy that may not result > > in the expected behavior because of the destination-first operation. > > Please add some guidance on the advertisements and how they may > > interact in the routing table. > > > > Note that what I'm asking for may just be a good example of what to do/ > > not to do. rfc8678/=C2=A75 presents an example of how the forwarding ta= ble is > > constructed based on a set of routes -- something like that would be > > great! > > Since your concern seems to be related to a particular example of what > the source-specific extension can be used for, mentioned in the > introduction, I'm not sure I see how it would improve the document to > write a whole bunch of text addressing this particular operational > concern? I mean, the section you're quoting the example from (section 4) > literally says that the choice of dest first / source first is arbitrary > and all that is required is that it is consistent, before then going > ahead and spelling out the choice. The choice may have been arbitrary, but =C2=A74 explicitly requires destination-first: "A Babel implementation MUST choose routing table entries by using the so-called destination-first ordering..." Note that I am not questioning the choice, I'm just asking for more details= . > One small change in the introduction that may make this clearer, was to > amend this sentence in the third paragraph of the introduction: > > "When using > this technique in a network connected to multiple providers, every > host is assigned multiple addresses, one per provider." > > to read something like: > > "When using > this technique in a network connected to multiple providers, every > host is assigned multiple addresses, one per provider, and each edge > router exports a default route with a source prefix corresponding to > the prefix delegated from its upstream." That is not a bad change. =C2=A0However, my concern is not just about the multihomed case, but about the general handling of advertisements into the routing table. > > (b) How is the source address selected by the host? > > [...] > > > Even though this document is about Babel and not the host, I would > > like to see a (short) discussion about how the host is expected to > > behave (or what it needs to consider) in light of the > > destination-first operation. > > Juliusz can correct me if I'm wrong here, but I believe this is left out > because it really doesn't matter. The host can pick source addresses > however it likes, and packets will make their way to the right upstream > (in the multi-homing scenario). If it doesn't matter, I would like to understand why. The multihomed case with 2 default routes is straight forward -- but how would it work in a more complex case (=C2=A74.4/rfc8678, for example) where a specific source address is expected? =C2=A0Or is this use case not supported? Thanks! Alvaro. From nobody Wed Nov 4 09:46:20 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2B3A13B1; Wed, 4 Nov 2020 09:46:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160451197790.28880.17597785068103610213@ietfa.amsl.com> Date: Wed, 04 Nov 2020 09:46:17 -0800 Archived-At: Subject: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 17:46:18 -0000 Robert Wilton has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I support Ben's discuss regarding reusing the terminology from NMDA. I think that the document should have a normative reference to RFC 8342, and probably explain that in some places the information model is using the same concepts of configuration and operational data separation described in NMDA. I also support Alvaro's question about whether the source-routing component should be included. This is just a comment, and I'm not proposing that you change tack, but I have to confess that I question how beneficial publishing an Information Model really is. I understand that the goal here is to be able to publish two different data models, one based on YANG and other based on BBF's [TR-181]. But what we end up with is an information model defined in a custom ad hoc language, which will naturally necessitate for the YANG and TR-181 models to be generated by hand, and for all three models to be kept up to date and consistent with each other. Hence, I wonder whether retrospectively it would have been better to just define the YANG model in IETF and ask BBF to use that as source reference to construct the TR-181 model from, ideally as a programmatic conversion, or failing that by hand. At least that way there are only two things to keep in sync rather than three. Regards, Rob From nobody Wed Nov 4 10:24:05 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613643A1447; Wed, 4 Nov 2020 10:24:03 -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 eg_9NQX_-we1; Wed, 4 Nov 2020 10:24:01 -0800 (PST) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 4CE9B3A1430; Wed, 4 Nov 2020 10:23:53 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id h6so17283028pgk.4; Wed, 04 Nov 2020 10:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vOxQGnqTDTMez3TxKmeqrBAMJkbB0puzJvex7XYr+d0=; b=rYUT7gQFoYNrmcnGNEt5OELRpi4NVCy+dWGnq/70qRe3oj9ITGoLQ6NSrmHm03VaCk 0H6/yvwmw4jVJGoMTBCFGXYeAy3XGJGjfhXMsV7upsOEhEPkHKhYde8QqUOMX4Adyk3Z kfEjC5j3sLy5SmudXV/0ykdDrmzyyxho5Xlu8XOKKWo/9wb5WQ8Zm7L444nu0cvucWju SOy/g4A/2cYWL/5qmnBWjgMpbJ74yIgkzZVvSQYhbQVJo8NwojHLiavL7xTfKguBS56q Yjwd2qhaQIpBHVhUbpWhCTiIDZAfmdmrhOONzgfKMZcuQJFPLmt7NnQz2iOZHt3Iigr6 iPZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vOxQGnqTDTMez3TxKmeqrBAMJkbB0puzJvex7XYr+d0=; b=gjsdEuri8mmQwG6iPDI7FX984lkRiGfv0AojaRx/7Wc1F9o4ZCau4py/nY//W8mtXi N3RBpxg+nNggkjjdMZk3xlslwwBir0r2NGYFjWXsbKCjAXHklNLLdk7b0pTjq9MJEpiY pMUVmPoqdhHZU6rTIOsHQTyc7ubg3FEtYWslzJZaOnHfS2DASBfez4x7AWQIYaQMmlNn NPAyot8DeOCLZ25HZhT5BxLiFhnGjX9yC5pEK+eILxQoOYLc/Y+sEGuB7NOrENqUfjm6 DNcsAFTGDVEDVR4OL+XoNevP7oxp24gMIob3cbPRAK8D9Z0k5N5ptSYv4ArVt+JTatUC eVDg== X-Gm-Message-State: AOAM531tJ2BhWhVCj3Zo1IcAm1eaCc2bIJqQrMJ+5o/SocUMh8+T3DZs +4B0VCzPfGl+M6iQjUxHpmw= X-Google-Smtp-Source: ABdhPJw7V4/rBSn5C/dXmprYxg1W5L0GRwS+3kl7M4v82MwRHWffcq2EhySbpeR7nrXZmRLWPkcr6g== X-Received: by 2002:a17:90b:3798:: with SMTP id mz24mr5421926pjb.46.1604514232896; Wed, 04 Nov 2020 10:23:52 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:10d0:46a6:2615:2565? ([2601:647:5600:5020:10d0:46a6:2615:2565]) by smtp.gmail.com with ESMTPSA id i10sm2807447pjz.44.2020.11.04.10.23.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Nov 2020 10:23:52 -0800 (PST) From: Mahesh Jethanandani Message-Id: <0CA8EA3A-4BB0-46EF-8FAC-D11B846852B4@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5E68C2C4-37B2-4254-8597-092998CC8E1D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 4 Nov 2020 10:23:50 -0800 In-Reply-To: <160451197790.28880.17597785068103610213@ietfa.amsl.com> Cc: The IESG , draft-ietf-babel-information-model@ietf.org, babel-chairs@ietf.org, Babel at IETF , Donald Eastlake To: Robert Wilton References: <160451197790.28880.17597785068103610213@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 18:24:03 -0000 --Apple-Mail=_5E68C2C4-37B2-4254-8597-092998CC8E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rob, > On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker = wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-babel-information-model-11: No Objection >=20 > 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.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for this document. >=20 > I support Ben's discuss regarding reusing the terminology from NMDA. = I think > that the document should have a normative reference to RFC 8342, and = probably > explain that in some places the information model is using the same = concepts of > configuration and operational data separation described in NMDA. While I am not against a reference to the terminology from NMDA in the = information model, (BTW, I am ignorant on what it means for an = informational draft to have a normative reference), I am not sure = whether it needs to normative or whether it can be informative. By = making it normative, are we making this information model more YANG = specific? Could the reference to NMDA be normative in the YANG model of = this information model (which the YANG model already does)? Thanks. >=20 > I also support Alvaro's question about whether the source-routing = component > should be included. >=20 > This is just a comment, and I'm not proposing that you change tack, = but I have > to confess that I question how beneficial publishing an Information = Model > really is. I understand that the goal here is to be able to publish = two > different data models, one based on YANG and other based on BBF's = [TR-181]. =20 > But what we end up with is an information model defined in a custom ad = hoc > language, which will naturally necessitate for the YANG and TR-181 = models to be > generated by hand, and for all three models to be kept up to date and > consistent with each other. Hence, I wonder whether retrospectively = it would > have been better to just define the YANG model in IETF and ask BBF to = use that > as source reference to construct the TR-181 model from, ideally as a > programmatic conversion, or failing that by hand. At least that way = there are > only two things to keep in sync rather than three. >=20 > Regards, > Rob >=20 >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5E68C2C4-37B2-4254-8597-092998CC8E1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Rob,

On Nov 4, 2020, at 9:46 AM, Robert Wilton via = Datatracker <noreply@ietf.org> wrote:

Robert= Wilton has entered the following ballot position for
draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-m= odel/



---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

Thank you for this document.

I support Ben's discuss regarding reusing the = terminology from NMDA.  I think
that the document = should have a normative reference to RFC 8342, and probably
explain that in some places the information model is using = the same concepts of
configuration and operational data = separation described in NMDA.

While I am = not against a reference to the terminology from NMDA in the information = model, (BTW, I am ignorant on what it means for an informational draft = to have a normative reference), I am not sure whether it needs to = normative or whether it can be informative. By making it normative, are = we making this information model more YANG specific? Could the reference = to NMDA be normative in the YANG model of this information model =  (which the YANG model already does)?

Thanks.


I = also support Alvaro's question about whether the source-routing = component
should be included.

This is just a comment, and I'm not proposing that you change = tack, but I have
to confess that I question how beneficial = publishing an Information Model
really is.  I = understand that the goal here is to be able to publish two
different data models,  one based on YANG and other = based on BBF's [TR-181].   
But what we end up = with is an information model defined in a custom ad hoc
language, which will naturally necessitate for the YANG and = TR-181 models to be
generated by hand, and for all three = models to be kept up to date and
consistent with each = other.  Hence, I wonder whether retrospectively it would
have been better to just define the YANG model in IETF and = ask BBF to use that
as source reference to construct the = TR-181 model from, ideally as a
programmatic conversion, = or failing that by hand.  At least that way there are
only two things to keep in sync rather than three.

Regards,
Rob




Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_5E68C2C4-37B2-4254-8597-092998CC8E1D-- From nobody Wed Nov 4 15:34:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DE93A1163; Wed, 4 Nov 2020 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 pRfwBsSflBLJ; Wed, 4 Nov 2020 15:34:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B3D8A3A1162; Wed, 4 Nov 2020 15:34:15 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A4NYCMR013055; Wed, 4 Nov 2020 18:34:15 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 34ke5bgs36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 18:34:14 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4NYD7O025242; Wed, 4 Nov 2020 18:34:13 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4NY878025163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 18:34:08 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 04FA4403072D; Wed, 4 Nov 2020 23:34:08 +0000 (GMT) Received: from MISOUT7MSGED1DB.ITServices.sbc.com (unknown [135.66.184.185]) by zlp27126.vci.att.com (Service) with ESMTPS id CA7E2403072B; Wed, 4 Nov 2020 23:34:07 +0000 (GMT) Received: from MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) by MISOUT7MSGED1DB.ITServices.sbc.com (135.66.184.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 18:34:07 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 18:34:07 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.168) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 18:34:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fy2kka+oD3KGOgBUAPuSjqRrZwfktN26DaHIyknNiu4ZOQTHoMmaZVwcyL6LXuc4/ZKVIV1GmHAU3wgloEtSGswptAKLWjT5mlYKXUgso0xcc8KQWfbgzZwNj7h1tUsjwtN9PDPgSNyUOVDrF7mzGLQQGkHA4659/qEFhR26OnCqoLeYcNZJxtd3b51gQV9d458AlN0PuIOeTbhYLPA2x8SetFp118K6wqlne+4YzF6yf4FbibPn/lNIEcS/arKs4w2BTZKMxzy7FinTILyGzZOjePguyAXvvauZumhiEIxLbB2OWaTH3o6+WGLNJ1BoNNZA10oBzpItvWym61hNhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsMXCoS3BR6le2MGkHwqYOdVqJuG/HIVtAYe+uYKokQ=; b=mzlmc80e1P1ihW5BALol9oYLDoRE1ue+ux5+azwQgHj7kt4S09Y8Pl4Xj+XJxAxqXZUDjtu/Lo/MlnaszoU4pkMNPj1d8cYSSE5gdb4X9PWNMqeJdOrh00/sog3w9oY4wg7OQJRD5LR3BN2gWQbHbV/FeKRvF4L8hKgML03/+vAOhCj43R10j8/Nhfs4vmdm9sOTHtE+2oyDlXLFth5bb59wSLlHjuCCtS+p8Fqb/+sqOBPT0eH+0BI7SQanUO3+BpZEHjsq3Oat7kPteZVuQanfyXnAKnRmqucbWezDZaqvDTlAzJmQlocEVCz8SMHUiWxV8V6MAwxWdfy1UfDI9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsMXCoS3BR6le2MGkHwqYOdVqJuG/HIVtAYe+uYKokQ=; b=WUg58/GsSYj10E86OmXHZ19OGiiYmt76pVCKmkaEdOS1mWB5EhyYAK0VsQ+5i8HWhQ+o1TCY0xBbF1+tNHRg/CfNz7n47WTzoLJUCcraE0E8B1RyRKEY3GO0ImkmpJWpRR2YRvx2s+MhpR6K5HJEelGixx5g+/PjKhwnXPLemVU= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5471.namprd02.prod.outlook.com (2603:10b6:805:df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 23:34:04 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:34:04 +0000 From: "STARK, BARBARA H" To: "'Valery Smyslov'" , "'secdir@ietf.org'" CC: "'last-call@ietf.org'" , "'babel@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" Thread-Topic: Secdir last call review of draft-ietf-babel-information-model-11 Thread-Index: AQHWq6fzcO41VWb3pEKu2D6snc0rJ6m1Uycw Date: Wed, 4 Nov 2020 23:34:04 +0000 Message-ID: References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> In-Reply-To: <160372407981.20077.17795340180313190981@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: smyslov.net; dkim=none (message not signed) header.d=none;smyslov.net; dmarc=none action=none header.from=att.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [144.160.96.109] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84d45a03-f794-4b61-ec3d-08d8811a1dd7 x-ms-traffictypediagnostic: SN6PR02MB5471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ts2wsHl29zdpSLeoe/T24647hNkQ2HbRCUxZkAn3Kp9UIhJH0EdzFOgmtRQZJgkX64O7ggQEf948y+CGmiTlqRSj1cjTvBM3ZzY/xgrV/5haaLJVrDQncBPnRFNDnOVqjg/JAy2XqPaBkU7ZSkdgbPCQ8/DOTizTQoNxPRh3PeDWStSxWJ2iANJ6U8p7PR7R3/t6tELwfnETXzB86fWBWmF8YW9wWYcXu3TQ2eWLyCSFthYe71aytZT2J4SqE8mEOyIyrbaU4DGDFNBiSCbLx70O5+gO7DySNzKxZSYgX7/i4KGg2DngAYYoB74z9fDHx1G/OEGg4KuXyE0W+o8IAChZcaPnOQKa83MdI/5JMIXqOYubo0+J+cgBIb0EF/tF x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(136003)(376002)(26005)(186003)(54906003)(478600001)(7696005)(110136005)(83380400001)(8936002)(6506007)(55016002)(64756008)(66446008)(33656002)(82202003)(4326008)(2906002)(8676002)(66556008)(66476007)(71200400001)(30864003)(76116006)(9686003)(86362001)(5660300002)(52536014)(316002)(66946007)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: JPlj+GCqsLt/nUqzoNtnNTc1sFiWJ4zLuVQ192oqiBQZsZSaREr8FVOEE99H7w93+4aLaDtHmXv4XV+sa8v1Uba+hIBWSi2SUfbT0Rh9pwH3RH0VqVRpUzN0bPZAmcNMcntmA01HLJQeb6yAM7nkCTQ8Jucs9DBATSs/ixst005YABMxy9j0aU01GNVBLLQ050JPsss3q+0LhEVgmgJ5WDFYFpDftHmqSj6OAnr1HvxM8dDnDHLJXC6/6nRyQswq9eqkqOredBgPjWVzgUVrM/LvcLsXd9rJ3W3nRGbGdHzU+bYvmCDGRzzRkpaKa7M+Y8St8dKM/MoJm/WnZjcelRwub+GYymeUEcSkwvQmku0DwnRZMa39DljPe6CPLP/Aefymo7TBazG5M3IRgmIF1RqiO0NiFGiq4gy5mgUEDT12JxZSZ7P7rRQeLhsZEMBskUmhawBTU7yf5r7qZusG+bN3e5IaIvGLOSIG3YQ7enBAmYGOaEcyGFlEdf6wKc5TaqB6rNw9Vr5rm4E3Bx9syHq/PH87zdU3bTFzhskMzOke/FNbVp2G7mVdklJ43dkK8/bMhcc8oIc3eNrODJAnp7A6onzlQkTX+DIv0WEI6YXdz9vr+rrV3/eexKoMRfcwTpbEaVu5XtSNXHFuOA8KwA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84d45a03-f794-4b61-ec3d-08d8811a1dd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:34:04.1388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jMrt3QpZY8ngt+E61ZmOPl4mHcmCdRhEWlSRW5FGHd+vmQdSIx3PzlZ+WmoRO0+U X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5471 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 8387F2C5F1336A4A2ED0D865C29BAF259D599D1CF0D878C5129CC7EA680A1E852 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_17:2020-11-04, 2020-11-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 malwarescore=0 bulkscore=0 suspectscore=0 impostorscore=0 mlxlogscore=999 spamscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 clxscore=1011 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040168 Archived-At: Subject: Re: [babel] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 23:34:18 -0000 SGkgVmFsZXJ5LA0KVGhhbmtzIGZvciB5b3VyIHJldmlldy4gVGFraW5nIGludG8gYWNjb3VudCBK dWxpdXN6JyByZXNwb25zZSB0byB5b3VyIGVtYWlsLCBJJ20gcHJvcG9zaW5nIHRoZSBmb2xsb3dp bmcgcmVzb2x1dGlvbnMuIEZvciB0aGUgZmlyc3QgaXNzdWUgcmFpc2VkLCBJJ20gZGlzYWdyZWVp bmcgc2xpZ2h0bHkgd2l0aCBKdWxpdXN6LCBzbyB0aGF0IG1heSBuZWVkIGZ1cnRoZXIgZGlzY3Vz c2lvbi4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBkaXNhZ3JlZS4gSSd2ZSBjb3BpZWQgSnVs aXVzeicgcmVzcG9uc2VzIGhlcmUsIHNvIEkgY2FuIGluY2x1ZGUgbXkgcmVzcG9uc2VzIHRvIHlv dXIgY29tcGxldGUgZmVlZGJhY2sgYW5kIGhpcyBpbiBvbmUgZW1haWwuDQpSb21hbiBzcGVjaWZp Y2FsbHkgbWVudGlvbmVkIGhlIGFncmVlZCB3aXRoIHlvdXIgInJlY29tbWVuZGF0aW9ucyBhYm91 dCBwcmVjaXNlIGxhbmd1YWdlIGFyb3VuZCB0aGUgbmFtZXMgb2YgdGhlIHBhcmFtZXRlcnMiLiBJ IHRoaW5rIHBlcmhhcHMgdGhpcyB3YXMgaW4gcmVmZXJlbmNlIHRvIGl0ZW0gNCB1bmRlciBuaXRz PyBJIGRpZG4ndCBjb21wbGV0ZWx5IGFncmVlIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbiwgc28g SSdkIGFwcHJlY2lhdGUgc29tZSBhZGRpdGlvbmFsIGRpc2N1c3Npb24gb24gdGhhdC4NClRoeCwN CkJhcmJhcmENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gUmV2aWV3ZXI6 IFZhbGVyeSBTbXlzbG92DQo+IFJldmlldyByZXN1bHQ6IEhhcyBJc3N1ZXMNCj4gDQo+IEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9y YXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWlu ZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KPiBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYQ0KPiBkaXJlY3Rv cnMuDQo+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdCBsaWtlIGFueQ0KPiBvdGhlcg0KPiBsYXN0IGNhbGwgY29tbWVudHMuDQo+ IA0KPiBUaGUgZG9jdW1lbnQgZGVmaW5lcyBhbiBpbmZvcm1hdGlvbmFsIG1vZGVsIGZvciBCYWJl bCByb3V0aW5nIHByb3RvY29sLg0KPiBUaGlzDQo+IGluZm9ybWF0aW9uYWwgbW9kZWwgY2FuIGJl IHVzZWQgYXMgYSBiYXNpcyBmb3IgY3JlYXRpbmcgdmFyaW91cyBkYXRhIG1vZGVscw0KPiAoZS5n LiBZQU5HKS4gVGhlIGRvY3VtZW50IGlzIHByb3Blcmx5IHN0cnVjdHVyZWQgYW5kIHdlbGwgd3Jp dHRlbiwgaG93ZXZlcg0KPiBJIHRoaW5rIHRoYXQgaXQgaGFzIHNvbWUgaXNzdWVzIGNvbmNlcm5l ZCB3aXRoIHNlY3VyaXR5Lg0KPiANCj4gSXNzdWVzLg0KPiANCj4gMS4gU2VjdGlvbiAzLjE6DQo+ IA0KPiAgICBiYWJlbC1tYWMtYWxnb3JpdGhtczogIExpc3Qgb2Ygc3VwcG9ydGVkIE1BQyBjb21w dXRhdGlvbiBhbGdvcml0aG1zLg0KPiAgICAgICBQb3NzaWJsZSB2YWx1ZXMgaW5jbHVkZSAiSE1B Qy1TSEEyNTYiLCAiQkxBS0UycyIuDQo+IA0KPiBCTEFLRTJzIGNhbiBwcm9kdWNlIE1BQ3Mgb2Yg ZGlmZmVyZW50IHNpemVzIGZyb20gMSB0byAzMiBieXRlcyBhbmQgdGhlDQo+IGRlc2lyZWQNCj4g c2l6ZSBvZiB0aGUgTUFDIGlzIGEgcGFyYW1ldGVyIGZvciBpdC4gV2hlcmUgdGhlIHNpemUgb2Yg TUFDIGlzIHNwZWNpZmllZD8gRm9yDQo+IEhNQUMgd2l0aCBTSEEyNTYgSSBjYW4gYXQgbGVhc3Qg aW1hZ2luZSB0aGF0IGZ1bGwgMjU2IGJpdHMgb3V0cHV0IGlzIHVzZWQgYXMgYQ0KPiBNQUMuLi4N Cg0KSnVsaXVzeiBzYWlkOg0KPiBSaWdodC4gIFRoZSBpbnRlbnQgaXMgdGhhdCBCbGFrZTJzIGlz IHVzZWQgd2l0aCAzMi1vY3RldCBrZXlzIGFuZCAxNi1vY3RldA0KPiBoYXNoZXMgKGNvbGxpc2lv bi1yZXNpc3RhbmNlIGlzIG5vdCBhIGNvbmNlcm4gZm9yIEJhYmVsLU1BQyB3aGlsZQ0KPiBkaWN0 aW9uYXJ5IGF0dGFja3MgYXJlKS4gIEJhcmJhcmEsIEkgdGhpbmsgdGhhdCB5b3Ugc2hvdWxkIGV4 cGxpY2l0bHkNCj4gc3RhdGUgdGhhdCBCbGFrZTJzIGltcGxpZXMgMTI4LWJpdCBoYXNoZXMuICAo WW91IG1heSBhbHNvIGNvbnNpZGVyDQo+IHJlbmFtaW5nIEJMQUtFMnMgdG8gQkxBS0Uycy0xMjgu KQ0KDQpUaGUgZGVmaW5lZCB2YWx1ZXMgZm9yIGJhYmVsLW1hYy1hbGdvcml0aG1zIGNvbWUgZGly ZWN0bHkgZnJvbSBkcmFmdC1pZXRmLWJhYmVsLWhtYWMuIFRoZSBkZWZpbmVkIHZhbHVlIG5hbWVz IHNob3VsZCBtYXAgY2xvc2VseSB0byB0aGUgbmFtZXMgdXNlZCBmb3IgdGhlIGFsZ29yaXRobXMg aW4gaW4gdGhhdCBkcmFmdCAtLSB3aGljaCB0aGV5IGN1cnJlbnRseSBkby4gDQoNCklmIGl0IG5l ZWRzIHRvIGJlIGV4cGxpY2l0bHkgc3RhdGVkIHNvbWV3aGVyZSB0aGF0IGFuIGltcGxlbWVudGF0 aW9uIG9mIGRyYWZ0LWlldGYtYmFiZWwtaG1hYyB3aXRoIEJMQUtFMnMgb3V0cHV0cyAxMjgtYml0 IE1BQ3MsIHRoZW4gZHJhZnQtaWV0Zi1iYWJlbC1obWFjICh3aGljaCB3YXMgYWxyZWFkeSBzdWJt aXR0ZWQgZm9yIHB1YmxpY2F0aW9uKSB3b3VsZCBiZSB0aGUgY29ycmVjdCBwbGFjZSB0byBzYXkg dGhhdC4gVGhlIGluZm9ybWF0aW9uIG1vZGVsIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UsIHVubGVz cyB0aGVyZSdzIHNvbWUgZXhwZWN0YXRpb24gZm9yIHRoZSBzaXplIHRvIGJlIGNvbmZpZ3VyYWJs ZSBvciByZXBvcnRhYmxlLiBJJ20gbm90IHNlZWluZyBhbnkgcmVxdWVzdCBmb3IgdGhlIE1BQyBz aXplIHRvIGJlIGNvbmZpZ3VyZWQgb3IgcmVwb3J0ZWQgdmlhIHRoZSBpbmZvcm1hdGlvbiBtb2Rl bC4gDQoNCkknbSBwcm9wb3Npbmcgbm8gY2hhbmdlIHRvIHRoZSBkZWZpbmVkIHZhbHVlcyBvZiBi YWJlbC1tYWMtYWxnb3JpdGhtcyBpbiBvcmRlciB0byBtYWludGFpbiBjb21wbGV0ZSBjb25zaXN0 ZW5jeSB3aXRoIHRoZSBuYW1lcyB1c2VkIGluIGRyYWZ0LWlldGYtYmFiZWwtaG1hYy0xMi4NCg0K PiAyLiBTZWN0aW9uIDMuOToNCj4gDQo+ICAgIGJhYmVsLWNlcnQtdGVzdDogIEFuIG9wZXJhdGlv biB0aGF0IGFsbG93cyBhIGhhc2ggb2YgdGhlIHByb3ZpZGVkDQo+ICAgICAgIGlucHV0IHN0cmlu ZyB0byBiZSBjcmVhdGVkIHVzaW5nIHRoZSBjZXJ0aWZpY2F0ZSBwdWJsaWMga2V5IGFuZA0KPiAg ICAgICB0aGUgU0hBLTI1NiBoYXNoIGFsZ29yaXRobS4gIElucHV0IHRvIHRoaXMgb3BlcmF0aW9u IGlzIGEgYmluYXJ5DQo+ICAgICAgIHN0cmluZy4gIFRoZSBvdXRwdXQgb2YgdGhpcyBvcGVyYXRp b24gaXMgdGhlIHJlc3VsdGluZyBoYXNoLCBhcyBhDQo+ICAgICAgIGJpbmFyeSBzdHJpbmcuDQo+ IA0KPiBJIGZhaWxlZCB0byB1bmRlcnN0YW5kIHdoYXQgdGhpcyBvcGVyYXRpb24gc2hvdWxkIGRv LiBMaXRlcmFsbHkgcmVhZGluZyBpdCBpcw0KPiBpbnRlbmRlZCB0byBwcm9kdWNlIFNIQTItMjU2 IGhhc2ggb2YgcHVibGljIGtleSBhbmQgc29tZSBhcmJpdHJhcnkgc3RyaW5nDQo+IChjb25jYXRl bmF0ZWQ/IGluIHdoYXQgb3JkZXI/KS4gQnV0IHRoZW4gSSBmYWlsZWQgdG8gdW5kZXJzdGFuZCB0 aGUgcHVycG9zZQ0KPiBvZg0KPiB0aGlzIHRlc3QuIEkgd291bGQgaGF2ZSB1bmRlcnN0b29kIGlm IHRoaXMgb3BlcmF0aW9uIHByb3ZpZGVzIHNpZ25pbmcgb2YgdGhlDQo+IGFyYml0cmFyeSBzdHJp bmcgdXNpbmcgcHJpdmF0ZSBrZXkgYW5kIFNIQTItMjU2IGFzIGEgaGFzaCBmdW5jdGlvbiAoc2lt aWxhcmx5DQo+IHRvIGJhYmVsLW1hYy1rZXktdGVzdCksIGJ1dCBpdCBpbiBub3Qgd2hhdCBpcyB3 cml0dGVuLi4uDQoNCk9uZSBvZiB0aGUgbW9zdCBjb21tb24gcHJvYmxlbXMgaW4gY29uZmlndXJp bmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBpcyBpbiB0aGUgZm9ybWF0IG9mIHRoZSBpbnB1dCBrZXkg KGhleCwgQVNDSUksIGJhc2U2NCwgaGFzaGluZyB0aGF0IG9jY3VycyB0byBjcmVhdGUgImFjdHVh bCBrZXkiLCBldGMuKS4gV2hlbiBhIHNlY3VyaXR5IG1lY2hhbmlzbSBmYWlscyB0byB3b3JrLCBp dCBpcyBpbXBvcnRhbnQgZm9yIHVzZXJzIG9yIGRldmljZSBtYW5hZ2VycyB0byBiZSBhYmxlIHRv IHRyb3VibGUtc2hvb3QgdGhpcyBzcGVjaWZpYyBwb2ludCBvZiBmYWlsdXJlLiBUaGlzIHRlc3Qg YWxsb3dzIHRoZSB1c2VyL21hbmFnZXIgdG8gc2VlIGlmIHdoYXQgdGhpcyBkZXZpY2UgdGhpbmtz IHRoZSBNQUMgc2hvdWxkIGJlIGlzIHRoZSBzYW1lIGFzIHdoYXQgYW5vdGhlciBkZXZpY2UgdGhp bmtzIHRoZSBNQUMgc2hvdWxkIGJlIG9yIGlzIHRoZSBzYW1lIGFzIHRoZSBNQUMgYmVpbmcgc2Vu dCBvbiB0aGUgd2lyZS4gTWFueSBJU1BzIGhhdmUgYnVpbHQgYSB0ZXN0IGxpa2UgdGhpcyBpbnRv IHRoZWlyIElTUC1zdXBwbGllZCBDRSByb3V0ZXJzIChpbnZva2VkIHVzaW5nIHRoZSBUUi0wNjkg cHJvdG9jb2wgYW5kIFRSLTE4MSBkYXRhIG1vZGVsKSB0byB0ZXN0IHZhcmlvdXMgc3RvcmVkIGtl eSB2YWx1ZXMuIEl0IGhhcyBwcm92ZW4gdXNlZnVsLg0KDQo+IDMuIFNlY3Rpb24gNSAoU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMpOg0KPiANCj4gSSB0aGluayB0aGF0IHRleHQgYWJvdXQga2V5cyAo dGhlaXIgbGVuZ3RoIGFuZCBwcm9wZXJ0aWVzKSBuZWVkcyBzb21lDQo+IGV4cGFuc2lvbi4gRmly c3QsIHRoZXJlIGFyZSBubyBhbnkgUkZDMjExOSB3b3JkcyBkaXNjb3VyYWdpbmcgdXNpbmcgc2hv cnQNCj4gYW5kDQo+IHdlYWsga2V5cyAodGhlcmUgaXMgc29tZSB0ZXh0LCBidXQgd2l0aG91dCBS RkMyMTE5IHdvcmRzIGFuZCB3aXRoIG5vDQo+IHJlZmVyZW5jZXMNCj4gaXQncyBqdXN0IGhhbmQg d2F2aW5nKS4gTm90ZSwgdGhhdCBkcmFmdC1pZXRmLWJhYmVsLWhtYWMtMTIgaGFzIHNvbWUgdGV4 dA0KPiBhYm91dA0KPiB0aGUgcHJvcGVydGllcyBvZiB0aGUga2V5cywgc28gSSBiZWxpZXZlIGF0 IGxlYXN0IGl0IG11c3QgYmUgcmVmZXJlbmNlZCBoZXJlLiBJDQo+IGFsc28gc3VzcGVjdCB0aGF0 IGV4cGxpY2l0bHkgYWxsb3dpbmcgemVyby1sZW5ndGggYW5kIHNob3J0IGtleXMgd2lsbCBsZWFk IHRvDQo+IHNpdHVhdGlvbnMgd2hlbiBzb21lIG5ldHdvcmsgb3BlcmF0b3JzIHdpbGwgdXNlIHRo ZW0gKGJlY2F1c2UgdGhleSBhcmUNCj4gbm90DQo+IHByb2hpYml0ZWQpLCB0aHVzIHN1YnZlcnRp bmcgc2VjdXJpdHkgcHJvcGVydGllcyBvZiBNQUMuLi4NCg0KVGhhbmtzLiBJJ2xsIGFkZCBhIHJl ZmVyZW5jZSB0byBkcmFmdC1pZXRmLWJhYmVsLWhtYWMgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu DQoNClplcm8gbGVuZ3RoIGFuZCBzaG9ydCBrZXlzIHdlcmUgZGlzY3Vzc2VkIG9uIHRoZSBtYWls aW5nIGxpc3QuIFRoZSBncm91cCBjb25zaWRlcmVkIGl0IGFwcHJvcHJpYXRlIHRvDQphbGxvdyBj b25maWd1cmF0aW9uIG9mIHplcm8tbGVuZ3RoIGtleXMgZm9yIHRlc3RpbmcgYnV0IHRvIGFkdmlz ZSBwZW9wbGUgdG8gZm9sbG93IGJlc3QNCmN1cnJlbnQgcHJhY3RpY2VzLiBJIGZpbmQgdGhlIHVz ZSBvZiBub3JtYXRpdmUgbGFuZ3VhZ2UgdG8gYXR0ZW1wdCB0byBjb250cm9sIHRoZSBiZWhhdmlv ciBvZiANCmEgaG9tZSBuZXR3b3JrIG93bmVyIChmb3IgZXhhbXBsZSkgb3Igc29tZW9uZSBzZXR0 aW5nIHVwIGFuIGluZm9ybWFsIGFkIGhvYyBtZXNoDQpuZXR3b3JrIChmb3IgZXhhbXBsZSkgdG8g YmUgb2RkLiBJTU8sIHRoZSBJRVRGIHNob3VsZCBub3Qgc2VlayB0byBjb250cm9sDQp0aGUgY2hv aWNlcyBvZiBwZW9wbGUgcHV0dGluZyB0b2dldGhlciBzdWNoIHJlbGF0aXZlbHkgc21hbGwtc2Nh bGUgbmV0d29ya3MgdGhyb3VnaCANCnRoZSB1c2Ugb2Ygc3Ryb25nIG5vcm1hdGl2ZSBsYW5ndWFn ZSBpbiBhbiBpbmZvcm1hdGlvbiBtb2RlbCBzcGVjaWZpY2F0aW9uLiBJdCdzIA0KaW1wb3NzaWJs ZSB0byBlbmZvcmNlIGFuZCBzdWNoIHBlb3BsZSBwcmV0dHkgbXVjaCBuZXZlciByZWFkIFJGQ3Mu DQoNCklmIHRoZXJlIGlzIGEgc3Ryb25nIGRlc2lyZSBmb3Igc29tZSBzb3J0IG9mIG5vcm1hdGl2 ZSBsYW5ndWFnZSwgdGhlbiBJIGNvdWxkIHN1Z2dlc3QNCk9MRA0KICAgTUFDIGtleXMgYXJlIGFs bG93ZWQgdG8gYmUgYXMgc2hvcnQgYXMgemVyby1sZW5ndGguICBUaGlzIGlzIHVzZWZ1bA0KICAg Zm9yIHRlc3RpbmcuICBOZXR3b3JrIG9wZXJhdG9ycyBhcmUgYWR2aXNlZCB0byBmb2xsb3cgY3Vy cmVudCBiZXN0DQogICBwcmFjdGljZXMgZm9yIGtleSBsZW5ndGggYW5kIGdlbmVyYXRpb24gb2Yg a2V5cyByZWxhdGVkIHRvIHRoZSBNQUMNCiAgIGFsZ29yaXRobSBhc3NvY2lhdGVkIHdpdGggdGhl IGtleS4gIFNob3J0IChhbmQgemVyby1sZW5ndGgpIGtleXMgYW5kDQogICBrZXlzIHRoYXQgbWFr ZSB1c2Ugb2Ygb25seSBhbHBoYW51bWVyaWMgY2hhcmFjdGVycyBhcmUgaGlnaGx5DQogICBzdXNj ZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBhdHRhY2tzLg0KTkVXDQogICBNQUMga2V5cyBhcmUgYWxs b3dlZCB0byBiZSBhcyBzaG9ydCBhcyB6ZXJvLWxlbmd0aC4gIFRoaXMgaXMgdXNlZnVsDQogICBm b3IgdGVzdGluZy4gIE5ldHdvcmsgb3BlcmF0b3JzIGFyZSBSRUNPTU1FTkRFRCB0byBmb2xsb3cg Y3VycmVudCBiZXN0DQogICBwcmFjdGljZXMgZm9yIGtleSBsZW5ndGggYW5kIGdlbmVyYXRpb24g b2Yga2V5cyByZWxhdGVkIHRvIHRoZSBNQUMNCiAgIGFsZ29yaXRobSBhc3NvY2lhdGVkIHdpdGgg dGhlIGtleS4gIFNob3J0IChhbmQgemVyby1sZW5ndGgpIGtleXMgYW5kDQogICBrZXlzIHRoYXQg bWFrZSB1c2Ugb2Ygb25seSBhbHBoYW51bWVyaWMgY2hhcmFjdGVycyBhcmUgaGlnaGx5DQogICBz dXNjZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBhdHRhY2tzLiBTZWUgdGhlIFNlY3VyaXR5IENvbnNp ZGVyYXRpb25zDQogIHNlY3Rpb24gb2YgW0lELmRyYWZ0LWlldGYtYmFiZWwtaG1hY10gZm9yIGFk ZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgDQogIHJlbGF0ZWQgdG8gTUFDIGtleXMuDQoNCj4gTml0 cy4NCj4gDQo+IDEuIFNlY3Rpb24gMSAoSW50cm9kdWN0aW9uKToNCj4gDQo+ICAgIFtJLUQuaWV0 Zi1iYWJlbC1obWFjXSBkZWZpbmVzIGENCj4gICAgc2VjdXJpdHkgbWVjaGFuaXNtIHRoYXQgYWxs b3dzIEJhYmVsIHBhY2tldHMgdG8gYmUgY3J5cHRvZ3JhcGhpY2FsbHkNCj4gICAgYXV0aGVudGlj YXRlZCwgYW5kIFtJLUQuaWV0Zi1iYWJlbC1kdGxzXSBkZWZpbmVzIGEgc2VjdXJpdHkgbWVjaGFu aXNtDQo+ICAgIHRoYXQgYWxsb3dzIEJhYmVsIHBhY2tldHMgdG8gYmUgZW5jcnlwdGVkLg0KPiAN Cj4gRFRMUyBwcm92aWRlcyBib3RoIGNvbmZpZGVudGlhbGl0eSBhbmQgYXV0aGVudGljYXRpb24g b2YgZGF0YSwgc28gdG8gYmUNCj4gZm9ybWFsbHkgY29ycmVjdCwgcGxlYXNlIGFkZCAiYm90aCBh dXRoZW50aWNhdGVkIGFuZCIgYmVmb3JlICJlbmNyeXB0ZWQiLg0KDQpUaGFuayB5b3UuIEkgd2ls bCBtYWtlIHRoaXMgY2hhbmdlLg0KIA0KPiAyLiBTZWN0aW9uIDIgKE92ZXJ2aWV3KSBhdCB0aGUg dmVyeSBlbmQ6DQo+IA0KPiAgICBOb3RlIHRoYXQgdGhpcyBvdmVydmlldyBpcyBpbnRlbmRlZCBz aW1wbHkgdG8gYmUgaW5mb3JtYXRpdmUgYW5kIGlzDQo+ICAgIG5vdCBub3JtYXRpdmUuICBJZiB0 aGVyZSBpcyBhbnkgZGlzY3JlcGFuY3kgYmV0d2VlbiB0aGlzIG92ZXJ2aWV3IGFuZA0KPiAgICB0 aGUgZGV0YWlsZWQgaW5mb3JtYXRpb24gbW9kZWwgZGVmaW5pdGlvbnMgaW4gc3Vic2VxdWVudCBz ZWN0aW9ucywNCj4gICAgdGhlIGVycm9yIGlzIGluIHRoaXMgb3ZlcnZpZXcuDQo+IA0KPiBUaGlz IHBocmFzZSBtYWtlcyBtZSBwdXp6bGVkLiBUaGUgdHJlZS1saWtlIGRlc2NyaXB0aW9uIG9mIHRo ZSBpbmZvcm1hdGlvbg0KPiBtb2RlbCBpbiB0aGUgT3ZlcnZpZXcgaXMgdmVyeSB1c2VmdWwsIGhv d2V2ZXIgdGhpcyBwaHJhc2Ugc2VlbXMgdG8NCj4gZGlzY291cmFnZQ0KPiB1c2luZyBpdCwgYmVj YXVzZSBhdXRob3JzIGFyZSBub3Qgc3VyZSBpdCBpcyBjb3JyZWN0LiBJIHRoaW5rIGl0IHdvdWxk IGJlDQo+IGJldHRlciBmb3IgcmVhZGVycyBpZiBhdXRob3JzIGRvdWJsZSBjaGVjayB0aGF0IG5v IGRpc2NyZXBhbmN5IGV4aXN0cw0KPiBiZXR3ZWVuDQo+IHRoZSBvdmVydmlldyBhbmQgdGhlIHN1 YnNlcXVlbnQgZGV0YWlsZWQgZGVzY3JpcHRpb24gYW5kIHJlbW92ZSB0aGlzDQo+IHBocmFzZS4N Cg0KVGhlIGF1dGhvcnMgaGF2ZSBkb3VibGUtIGFuZCB0cmlwbGUtY2hlY2tlZCwgYnV0IGh1bWFu IGVycm9yIGlzIHN0aWxsIHBvc3NpYmxlLCBzaW5jZSB0aGVzZSB3ZXJlIG5vdCBhdXRvLWdlbmVy YXRlZCAobGlrZSBZQU5HIGRvZXMpLiBXaGVuZXZlciByZWR1bmRhbnQgaW5mb3JtYXRpb24gaXMg cHJlc2VudGVkLCBpdCBpcyBjcml0aWNhbCB0aGF0IGl0IGJlIG5vcm1hdGl2ZSBpbiBvbmx5IG9u ZSBwbGFjZS4gVGhpcyBsYW5ndWFnZSBtYWtlcyBpdCBjbGVhciB3aGljaCBpcyBub3JtYXRpdmUg YW5kIHdoYXQgdG8gZG8gaW4gdGhlIGNhc2Ugb2YgZGlzY3JlcGFuY2llcy4gSSBwcm9wb3NlIG5v IGNoYW5nZS4gSWYgdGhlcmUgaXMgYSBzdHJvbmcgcHVzaCB0byByZW1vdmUgdGhpcyBsYW5ndWFn ZSwgdGhlbiBJIGJlbGlldmUgdGhlIGNvcnJlY3QgYXBwcm9hY2ggd291bGQgYmUgdG8gcmVtb3Zl IHRoZSBlbnRpcmUgc2VjdGlvbiAocmVtb3ZlIHRoZSByZWR1bmRhbmN5KSByYXRoZXIgdGhhbiB0 byBhbGxvdyBjb25mdXNpb24gaWYgdGhlcmUgaXMgYW4gZXJyb3IuIEJ1dCBwZW9wbGUgaGF2ZSBm b3VuZCB0aGlzIHNlY3Rpb24gdXNlZnVsLCBzbyBJIHdvdWxkIHByZWZlciB0byBsZWF2ZSBpdCBh cyBpcy4NCiANCj4gMy4gU2VjdGlvbiAzLjM6DQo+IA0KPiAgICBiYWJlbC1tYWMtdmVyaWZ5ICBB IEJvb2xlYW4gZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgTUFDIGhhc2hlcyBpbg0KPiAgICAgICBp bmNvbWluZyBCYWJlbCBwYWNrZXRzIGFyZSByZXF1aXJlZCB0byBiZSBwcmVzZW50IGFuZCBhcmUN Cj4gICAgICAgdmVyaWZpZWQuICBJZiB0aGlzIHBhcmFtZXRlciBpcyAidHJ1ZSIsIGluY29taW5n IHBhY2tldHMgYXJlDQo+ICAgICAgIHJlcXVpcmVkIHRvIGhhdmUgYSB2YWxpZCBNQUMgaGFzaC4g IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UNCj4gICAgICAgdG8gZXhwb3NlIHRoaXMgcGFy YW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+IA0KPiAiTUFDIGhhc2hlcyIgaXMgc3RyYW5n ZSB3b3JkaW5nLCAiTUFDIHZhbHVlcyIgb3IganVzdCAiTUFDcyIgYXJlIGJldHRlciBpbg0KPiBt eQ0KPiBvcGluaW9uLg0KDQpUaGFuayB5b3UuIEknbGwgY2hhbmdlIGl0IHRvIE1BQy4NCg0KPiA0 LiBTZWN0aW9uIDMuODoNCj4gDQo+ICAgIGJhYmVsLW1hYy1rZXktdXNlLXNpZ246ICBJbmRpY2F0 ZXMgd2hldGhlciB0aGlzIGtleSB2YWx1ZSBpcyB1c2VkIHRvDQo+ICAgICAgIHNpZ24gc2VudCBC YWJlbCBwYWNrZXRzLiAgU2VudCBwYWNrZXRzIGFyZSBzaWduZWQgdXNpbmcgdGhpcyBrZXkNCj4g ICAgICAgaWYgdGhlIHZhbHVlIGlzICJ0cnVlIi4gIElmIHRoZSB2YWx1ZSBpcyAiZmFsc2UiLCB0 aGlzIGtleSBpcyBub3QNCj4gICAgICAgdXNlZCB0byBzaWduIHNlbnQgQmFiZWwgcGFja2V0cy4g IEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UgdG8NCj4gICAgICAgZXhwb3NlIHRoaXMgcGFy YW1ldGVyIGFzIHJlYWQtb25seSAoInJvIikuDQo+IA0KPiAiU2lnbiIgaXMgbm90IGEgZ29vZCB3 b3JkIHdoZW4geW91IGRlc2NyaWJlIHN5bW1ldHJpYyBrZXkgb3BlcmF0aW9ucw0KPiAod2hpY2gN Cj4gY29tcHV0aW5nIE1BQyBiZWxvbmdzIHRvKS4gQWx0aG91Z2ggaXQgaXMgb2Z0ZW4gdXNlZCBp bmZvcm1hbGx5LCBJIHRoaW5rIHRoYXQNCj4gUkZDIHNob3VsZCBiZSBtb3JlIG1ldGljdWxvdXMg aW4gc2VsZWN0aW5nIHdvcmRzLiBJJ2QgcmF0aGVyIHJlcGxhY2UgaXQgd2l0aA0KPiAiY29tcHV0 ZSBNQUMiIGFuZCByZW5hbWUgdGhlIGVudHJ5IHRvIGJhYmVsLW1hYy1rZXktdXNlLWNvbXB1dGUg b3INCj4gYmFiZWwtbWFjLWtleS11c2UtbWFjIChpZiBpdCBpcyBwb3NzaWJsZSkuIE5vdGUsIHRo YXQgdXNpbmcgInZlcmlmeSBNQUMiIGlzIE9LLg0KDQpJJ3ZlIGJlZW4gdGhpbmtpbmcgdGhyb3Vn aCB0aGlzLiBJIGNhbid0IHNwZWFrIHRvIHRoZSBpbmZvcm1hbCBuYXR1cmUgb2YgInNpZ24iLCBi dXQgSSBjYW4gc2F5IHRoYXQgc2ltcGx5IHJlcGxhY2luZyAic2lnbiIgd2l0aCAiY29tcHV0ZSIg b3IgIm1hYyIgd291bGRuJ3QgY29udmV5IGNvcnJlY3RseSB3aGF0IHRoaXMgcGFyYW1ldGVyIGlz IGFib3V0LiBUaGlzIHBhcmFtZXRlciBpcyBwcmltYXJpbHkgY29uY2VybmVkIHdpdGggd2hldGhl ciBvciBub3QgYSBNQUMgaXMgaW5jbHVkZWQgaW4gdGhlIHNlbnQgcGFja2V0LiBUaGUgc2VuZGlu ZyBpcyB0aGUgY3JpdGljYWwgcGllY2UsIGFuZCBub3QgdGhlIGNvbXB1dGluZyAoaXQncyBwb3Nz aWJsZSB0byBjb21wdXRlIHRoZSBNQUMgd2l0aG91dCBzZW5kaW5nIGl0OyBhIE1BQyBpbiBhIHNl bnQgcGFja2V0IGlzIGFzc3VtZWQgdG8gaGF2ZSBiZWVuIGNvbXB1dGVkKS4gSSBjb3VsZCBjaGFu Z2UgdGhlIGRlc2NyaXB0aW9uIHRvOg0KICAgICAgIEluZGljYXRlcyB3aGV0aGVyIHRoaXMga2V5 IHZhbHVlIGlzIHVzZWQgdG8gY29tcHV0ZSBhIE1BQyBhbmQgaW5jbHVkZSB0aGF0IE1BQyBpbiB0 aGUNCiAgICAgICBzZW50IEJhYmVsIHBhY2tldC4gIEEgTUFDIGZvciBzZW50IHBhY2tldHMgaXMg Y29tcHV0ZWQgdXNpbmcgdGhpcyBrZXkNCiAgICAgICBpZiB0aGUgdmFsdWUgaXMgInRydWUiLiAg SWYgdGhlIHZhbHVlIGlzICJmYWxzZSIsIHRoaXMga2V5IGlzIG5vdA0KICAgICAgIHVzZWQgdG8g Y29tcHV0ZSBhIE1BQyB0byBpbmNsdWRlIGluIHNlbnQgQmFiZWwgcGFja2V0cy4gIEFuIGltcGxl bWVudGF0aW9uIE1BWSBjaG9vc2UgdG8NCiAgICAgICBleHBvc2UgdGhpcyBwYXJhbWV0ZXIgYXMg cmVhZC1vbmx5ICgicm8iKQ0KDQpCdXQgSSBzdHJ1Z2dsZSB3aXRoIHRoZSBwcm9wb3NlZCBwYXJh bWV0ZXIgcmVuYW1pbmcuIEkgc3Ryb25nbHkgYmVsaWV2ZSB0aGUgbmFtZSBzaG91bGQgY29uY2lz ZWx5IGRlc2NyaWJlIHRoYXQgdGhlIEJvb2xlYW4gdmFsdWUgaW5kaWNhdGVzIHdoZXRoZXIgb3Ig bm90IHRvIGluY2x1ZGUgYSBNQUMgaW4gdGhlIHNlbnQgcGFja2V0LiBUaGUgdGVybSAic2lnbiIg aXMgb25lIEkndmUgY29tbW9ubHkgc2VlbiB0byBpbmRpY2F0ZSB0aGF0IGEgTUFDIGlzIGluY2x1 ZGVkIGluIHRoZSBzZW50IHBhY2tldC4gSSdtIG5vdCBhd2FyZSBvZiBhIGRpZmZlcmVudCwgc2lt aWxhcmx5IHNob3J0IHdvcmQuICJDb21wdXRlIiBhbmQgIm1hYyIgZG8gbm90IGNvbnZleSB0aGUg c2VuZGluZyBhc3BlY3QuIEFuZCBzZW5kaW5nIGlzIHZlcnkgYXN5bW1ldHJpYy4NCiANCj4gNS4g U2VjdGlvbiAzLjg6DQo+IA0KPiAgICBiYWJlbC1tYWMta2V5LXZhbHVlOg0KPiAgICAgICAgLi4u DQo+ICAgICAgIFRoaXMgdmFsdWUgaXMgb2YgYSBsZW5ndGggc3VpdGFibGUgZm9yIHRoZSBhc3Nv Y2lhdGVkIGJhYmVsLW1hYy1rZXktDQo+ICAgICAgIGFsZ29yaXRobS4gIElmIHRoZSBhbGdvcml0 aG0gaXMgYmFzZWQgb24gdGhlIEhNQUMgY29uc3RydWN0aW9uDQo+ICAgICAgIFtSRkMyMTA0XSwg dGhlIGxlbmd0aCBNVVNUIGJlIGJldHdlZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQo+ ICAgICAgIHVuZGVybHlpbmcgaGFzaCBpbmNsdXNpdmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxv Y2sgc2l6ZSBpcyA2NA0KPiAgICAgICBieXRlcyBhcyBkZXNjcmliZWQgaW4gW1JGQzQ4NjhdKS4g IElmIHRoZSBhbGdvcml0aG0gaXMgIkJMQUtFMnMiLA0KPiAgICAgICB0aGUgbGVuZ3RoIE1VU1Qg YmUgYmV0d2VlbiAwIGFuZCAzMiBieXRlcyBpbmNsdXNpdmUsIGFzIGRlc2NyaWJlZA0KPiAgICAg ICBpbiBbUkZDNzY5M10uDQo+IA0KPiBJIHdvbmRlciBvZiB0aGUgcmF0aW9uYWxlIGZvciBpbXBv c2luZyB0aGUgYWJvdmUgcmVzdHJpY3Rpb25zIG9uIEhNQUMga2V5DQo+IGxlbmd0aC4gSE1BQyBj YW4gdXNlIGtleXMgb2YgYW55IGxlbmd0aCwgYnV0IGlmIHRoZSBrZXkgaXMgZ3JlYXRlciB0aGFu IGJsb2NrDQo+IHNpemUgb2YgdW5kZXJseWluZyBoYXNoIGZ1bmN0aW9uLCB0aGVuIGl0J3MgZmly c3QgaGFzaGVkIChzbWFsbCBwZXJmb3JtYW5jZQ0KPiBwZW5hbHR5KS4gU28gSSBpbWFnaW5lIHRo YXQgdGhlIHJhdGlvbmFsZSBpcyB0byBhdm9pZCB0aGlzIHBlbmFsdHkuIEhvd2V2ZXIsIGFzDQo+ IFJGQzIxMDQgc3RhdGVzLCBrZXkgc2l6ZXMgZ3JlYXRlciB0aGFuIG91dHB1dCBsZW5ndGggb2Yg dGhlIHVuZGVybHlpbmcgaGFzaA0KPiBmdW5jdGlvbiAoMzIgYnl0ZXMgaW4gY2FzZSBvZiBTSEEy LTI1Nikgd291bGQgbm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdGhlDQo+IGZ1bmN0aW9uIHN0 cmVuZ3RoLCBzbyBpdCdzIGp1c3QgYSB3YXN0ZSBvZiBzcGFjZS4gU2VlIGFsc28gSXNzdWUgMyBh Ym92ZS4NCg0KSnVsaXVzeiBzYWlkOg0KPiBUaGlzIHdhcyBkaXNjdXNzZWQgYXQgbGVuZ3RoIG9u IHRoZSBtYWlsaW5nIGxpc3QuICBJdCdzIG5vdCBhYm91dA0KPiBwZXJmb3JtYW5jZSwgaXQncyBh Ym91dCBtYWtpbmcgaXQgbW9yZSBkaWZmaWN1bHQgdG8gdXNlIGFuIHVuc2FmZQ0KPiBwcm9jZWR1 cmUgZm9yIGdlbmVyYXRpbmcga2V5cy4NCj4gDQo+IFNpbmNlIEJhYmVsLU1BQyBpcyB2dWxuZXJh YmxlIHRvIGRpY3Rpb25hcnkgYXR0YWNrcywgdGhlIGtleSBtdXN0IGVpdGhlcg0KPiBiZSBkcmF3 biByYW5kb21seSBvciBnZW5lcmF0ZWQgdXNpbmcgYSBwcm9jZWR1cmUgdGhhdCBpcyBoYXJkZW5l ZCBhZ2FpbnN0DQo+IHN1Y2ggYXR0YWNrcyAoc2NyeXB0LCBldGMuKS4gIEFwcGx5aW5nIHRoZSBw cm9jZWR1cmUgZGVzY3JpYmVkIGluIFJGQyAyMTA0DQo+IHRvIGEgdXNlci1wcm92aWRlZCBwYXNz cGhyYXNlIGlzIG5vdCBzYWZlLCBhbmQgdGhlcmVmb3JlIHdlIHRyeSB0byBtYWtlIGl0DQo+IGRp ZmZpY3VsdCBmb3IgYSBuYWl2ZSB1c2VyIHRvIGRvIHNvLg0KPiANCj4gSSBhbSBvcHBvc2VkIHRv IHB1dHRpbmcgdGhlIFJGQyAyMTA0IGhhc2hpbmcgcHJvY2VkdXJlIGluIHRoZSBpbmZvcm1hdGlv bg0KPiBtb2RlbC4gIERvaW5nIHNvIHdvdWxkIGJlIGEgZGlzc2VydmljZSB0byBvdXIgdXNlcnMu DQoNCkluIGFkZGl0aW9uIHRvIHRoZSByYXRpb25hbGUgSnVsaXVzeiBtZW50aW9uZWQsIHdlIChi YWJlbCBXRykgYWxzbyBub3RlZCB0aGF0IGltcGxlbWVudGVycw0Kb2YgdGhlIGJhYmVsIE1BQyBm dW5jdGlvbiB3ZXJlIHVzaW5nIGV4aXN0aW5nIGxpYnJhcmllcyBmb3IgdGhlIEhNQUMtU0hBMjU2 IGFsZ29yaXRobS4NClRoZSB1c2VyIGludGVyZmFjZSAoVUkpIHRoYXQgYWNjZXB0ZWQgbWFudWFs IGtleSBlbnRyeSB3YXMgYWxzbyBmcm9tIGFuIGV4aXN0aW5nIGxpYnJhcnkuIFdoZW4NCnRoZSBz YW1lIGxvbmdlciBzdHJpbmdzIHdlcmUgZW50ZXJlZCBpbnRvIGRpZmZlcmVudCBVSXMgb2YgdGhl IGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMsIHRoZXNlDQpzdHJpbmdzIHdlcmUgdHJlYXRlZCBk aWZmZXJlbnRseSBhbmQgcmVzdWx0ZWQgaW4gbm9uLWludGVyb3BlcmFiaWxpdHkuIFRoZSAiYWN0 dWFsIGtleSIgKHVzaW5nDQpSRkMgMjEwNCB3b3JkcykgZW5kZWQgdXAgZGlmZmVyZW50LiBSZXF1 aXJpbmcgZW50ZXJlZCBrZXlzIHRvIGJlIGRpcmVjdGx5IHVzYWJsZSBhcyAiYWN0dWFsDQprZXlz IiBzb2x2ZWQgdGhpcyBwcm9ibGVtLiBCVFcsIEkgaGF2ZSBjb25zaWRlcmVkIFVJcyBmb3IgZGly ZWN0IG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24NCnRvIGVmZmVjdGl2ZWx5IGJlIGltcGxl bWVudGF0aW9ucyBvZiB0aGUgaW5mb3JtYXRpb24gbW9kZWwuIA0KDQpJIHJlY29tbWVuZCBubyBj aGFuZ2VzIHRvIHRoaXMgdGV4dC4NCiANCj4gNi4gICAgU2VjdGlvbiAzLjg6DQo+IA0KPiAgICBi YWJlbC1tYWMta2V5LXRlc3Q6ICBBbiBvcGVyYXRpb24gdGhhdCBhbGxvd3MgdGhlIE1BQyBrZXkg YW5kIGhhc2gNCj4gICAgICAgYWxnb3JpdGhtIHRvIGJlIHRlc3RlZCB0byBzZWUgaWYgdGhleSBw cm9kdWNlIGFuIGV4cGVjdGVkIG91dGNvbWUuDQo+ICAgICAgIElucHV0IHRvIHRoaXMgb3BlcmF0 aW9uIGlzIGEgYmluYXJ5IHN0cmluZy4gIFRoZSBpbXBsZW1lbnRhdGlvbiBpcw0KPiAgICAgICBl eHBlY3RlZCB0byBjcmVhdGUgYSBoYXNoIG9mIHRoaXMgc3RyaW5nIHVzaW5nIHRoZSBiYWJlbC1t YWMta2V5LQ0KPiAgICAgICB2YWx1ZSBhbmQgdGhlIGJhYmVsLW1hYy1rZXktYWxnb3JpdGhtLiAg VGhlIG91dHB1dCBvZiB0aGlzDQo+ICAgICAgIG9wZXJhdGlvbiBpcyB0aGUgcmVzdWx0aW5nIGhh c2gsIGFzIGEgYmluYXJ5IHN0cmluZy4NCj4gDQo+IFRoZSB0ZXh0IG1peGVzIHVwIHdvcmRzICJo YXNoIiBhbmQgIk1BQyIuIE1BQyBpcyBub3QgYSBoYXNoIChldmVuIGlmIE1BQw0KPiBhbGdvcml0 aG0gaXMgb2Z0ZW4gYmFzZWQgb24gaGFzaCBmdW5jdGlvbikuIEFzIHdpdGggbXkgcHJldmlvdXMg Z3J1bnQsIEknZCBsaWtlDQo+IFJGQyB0byBiZSBtb3JlIG1ldGljdWxvdXMgaW4gc2VsZWN0aW5n IHdvcmRzLiBQbGVhc2UsIGF2b2lkIHVzaW5nICJoYXNoIg0KPiBoZXJlLg0KDQpJZiBJIHVuZGVy c3RhbmQsIHRoZSBzdWdnZXN0aW9uIGlzIHRvIHJld29yZCBhczoNCiAgIGJhYmVsLW1hYy1rZXkt dGVzdDogIEFuIG9wZXJhdGlvbiB0aGF0IGFsbG93cyB0aGUgTUFDIGtleSBhbmQgTUFDDQogICAg ICBhbGdvcml0aG0gdG8gYmUgdGVzdGVkIHRvIHNlZSBpZiB0aGV5IHByb2R1Y2UgYW4gZXhwZWN0 ZWQgb3V0Y29tZS4NCiAgICAgIElucHV0IHRvIHRoaXMgb3BlcmF0aW9uIGlzIGEgYmluYXJ5IHN0 cmluZy4gIFRoZSBpbXBsZW1lbnRhdGlvbiBpcw0KICAgICAgZXhwZWN0ZWQgdG8gY3JlYXRlIGEg TUFDIG9mIHRoaXMgc3RyaW5nIHVzaW5nIHRoZSBiYWJlbC1tYWMta2V5LQ0KICAgICAgdmFsdWUg YW5kIHRoZSBiYWJlbC1tYWMta2V5LWFsZ29yaXRobS4gIFRoZSBvdXRwdXQgb2YgdGhpcw0KICAg ICAgb3BlcmF0aW9uIGlzIHRoZSByZXN1bHRpbmcgTUFDLCBhcyBhIGJpbmFyeSBzdHJpbmcuDQoN CklmIHRoaXMgaXMgcmlnaHQsIEknbGwgbWFrZSB0aGF0IGNoYW5nZS4NCg0KPiA3LiBTZWN0aW9u IDUgKFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKToNCj4gDQo+ICAgIC4uLiBUaGlzIG1vZGVsIHJl cXVpcmVzIHRoYXQgcHJpdmF0ZSBrZXlzIG5ldmVyIGJlDQo+ICAgIGV4cG9zZWQuICBUaGUgQmFi ZWwgc2VjdXJpdHkgbWVjaGFuaXNtcyB0aGF0IG1ha2UgdXNlIG9mIHRoZXNlDQo+ICAgIGNyZWRl bnRpYWxzIChlLmcuLCBbSS1ELmlldGYtYmFiZWwtZHRsc10sIFtJLUQuaWV0Zi1iYWJlbC1obWFj XSkNCj4gICAgaWRlbnRpZnkgd2hhdCBjcmVkZW50aWFscyBjYW4gYmUgdXNlZCB3aXRoIHRob3Nl IG1lY2hhbmlzbXMuDQo+IA0KPiBQbGVhc2UgYWRkICJhbmQgTUFDIGtleXMiIGFmdGVyICJwcml2 YXRlIGtleXMiIHNpbmNlIGZvcm1hbGx5IHByaXZhdGUga2V5cw0KPiBhcmUNCj4gb25seSBkZWZp bmVkIGZvciBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeS4NCg0KVGhhbmsgeW91LiBJJ2xsIG1ha2Ug dGhpcyBjaGFuZ2UuDQogDQo+IDguIFNlY3Rpb24gNSAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMp Og0KPiANCj4gICAgTUFDIGtleXMgYXJlIGFsbG93ZWQgdG8gYmUgYXMgc2hvcnQgYXMgemVyby1s ZW5ndGguICBUaGlzIGlzIHVzZWZ1bA0KPiAgICBmb3IgdGVzdGluZy4NCj4gDQo+IEkgd29uZGVy IHdoYXQncyBiZW5lZml0IG9mIGFsbG93aW5nIHplcm8tbGVuZ3RoIGtleXMgZm9yIHRlc3Rpbmcg cHVycG9zZXMuDQo+IFdoYXQNCj4gaXMgaW50ZW5kZWQgdG8gYmUgdGVzdGVkIGluIHRoaXMgY2Fz ZT8gSW1wbGVtZW50YXRpb24gb2YgTUFDPyBJcyBpdCByZWFsbHkNCj4gbmVlZGVkIG91dHNpZGUg dGVzdCBsYWI/IEFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCkFzIHdpdGggdGhlIC10ZXN0IGFj dGlvbnMsIHRoaXMgYWxsb3dzIHNvbWVvbmUgdG8gZGlhZ25vc2Ugd2hldGhlciBhIHByb2JsZW0g dGhleSBhcmUgaGF2aW5nIGlzIHdpdGggdGhlIGZvcm1hdHRpbmcgDQpvZiB0aGUgaW5wdXQga2V5 IChoZXgsIHBhZGRlZCwgQVNDSUksIGJhc2U2NCwgZXRjLikuIFRoaXMgaXMgYnkgZmFyIG9uZSBv ZiB0aGUgbW9zdCBjb21tb24gcHJvYmxlbXMgd2hlbiBhdHRlbXB0aW5nIHRvDQpnZXQgZGlmZmVy ZW50IGltcGxlbWVudGF0aW9ucyB0byBpbnRlcm9wZXJhdGUuDQoNCj4gOS4gU2VjdGlvbiA1IChT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyk6DQo+IA0KPiAgICAgU2hvcnQgKGFuZCB6ZXJvLWxlbmd0 aCkga2V5cyBhbmQNCj4gICAga2V5cyB0aGF0IG1ha2UgdXNlIG9mIG9ubHkgYWxwaGFudW1lcmlj IGNoYXJhY3RlcnMgYXJlIGhpZ2hseQ0KPiAgICBzdXNjZXB0aWJsZSB0byBicnV0ZSBmb3JjZSBh dHRhY2tzLg0KPiANCj4gRm9ybWFsbHksIGJydXRlIGZvcmNlIGF0dGFjayB3aXRoIHplcm8tbGVu Z3RoIGtleXMgaXMgbm90IGRlZmluZWQsIHNpbmNlIHRoZXJlDQo+IGlzIG5vIGtleSB0byBmaW5k IGFuZCBhbGwgaXMgaW4gY2xlYXIuDQoNCkp1bGl1c3ogc2FpZDoNCj4gVGhlIGtleSBsZW5ndGgg aXMgbm90IGNhcnJpZWQgaW4gdGhlIGNsZWFyIGJ5IHRoZSBwcm90b2NvbC4gIEd1ZXNzaW5nIHRo ZQ0KPiBrZXkgbGVuZ3RoIHJlcXVpcmVzIGEgYnJ1dGUtZm9yY2UgYXR0YWNrLCBldmVuIHdoZW4g aXQgaXMgemVyby4NCg0KSSBwcm9wb3NlIG5vIGNoYW5nZS4gDQoNCj4gQ29tbWVudHMuDQo+IA0K PiAxLiBUaGUgZG9jdW1lbnQgY29udGFpbnMgYW4gZW50cnkgaW4gdGhlIEluZm9ybWF0aW9uYWwg bW9kZWwgZGVmaW5pbmcgd2hpY2gNCj4gaGFzaCBmdW5jdGlvbnMgY2FuIGJlIHVzZWQgd2l0aCBI TUFDIGF1dGhlbnRpY2F0aW9uLiBIb3dldmVyLCB0aGVyZSBpcyBubw0KPiBjb3JyZXNwb25kaW5n IGVudHJ5IG9mIHdoaWNoIGNpcGhlcnN1aXRlcyBjYW4gYmUgdXNlZCB3aXRoIERUTFMuIElzIGl0 IHVwIHRvDQo+IERUTFMgbGlicmFyeSB0byBzZWxlY3QgY2lwaGVyc3VpdGVzPw0KDQpKdWxpdXN6 IHNhaWQ6DQo+IFllcy4gIEJhYmVsLURUTFMgaXMgaW50ZW5kZWQgdG8gaW5oZXJpdCB0aGUgc2Vj dXJpdHkgcHJvcGVydGllcyBvZiB0aGUNCj4gc3lzdGVtJ3MgRFRMUyBsaWJyYXJ5LiAgSWYgdGhl IERUTFMgbGlicmFyeSBpcyB1bnNhZmUsIHRoZW4gQmFiZWwtRFRMUw0KPiBtdXN0IG5vdCBiZSB1 c2VkIHVudGlsIHRoZSBsaWJyYXJ5IGlzIGZpeGVkLg0K From nobody Wed Nov 4 15:36:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEB73A117D; Wed, 4 Nov 2020 15:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 SjKecHcyArqo; Wed, 4 Nov 2020 15:36:08 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 D00E83A1166; Wed, 4 Nov 2020 15:36:08 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0A4NXffC018933; Wed, 4 Nov 2020 18:36:06 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 34m2dx4g8c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 18:36:05 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4Na4qX025469; Wed, 4 Nov 2020 18:36:04 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4Na1GU025454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 18:36:01 -0500 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id 6198240145B2; Wed, 4 Nov 2020 23:36:01 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (unknown [135.50.89.96]) by zlp30483.vci.att.com (Service) with ESMTPS id 35A0940145AF; Wed, 4 Nov 2020 23:36:01 +0000 (GMT) Received: from GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 18:36:00 -0500 Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1DE.ITServices.sbc.com (135.50.89.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 18:36:00 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 18:35:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=auB17KR7dMZpQITq8p3Krs2UM6Dqfgrr79lGg+Q27nOl5eB3/PAxpngL1yZRPyzI1mOgGIUQAci+tCSNv1T7NP0szOoDwBQya9zjw2UnhFT9gxy3avLdmtQfnbSC22JEOdDwRUqX5K+yR48qgITwordpL2HdpQ0+APplx8OpNnGtsxWow2p5k9uYRhtKWsK6j5OReXw7WicZRWgoQIh5K1WALJDCmxc2YqGlElAhTAdvIMtepp6JEjKo2EIQ5a8PalEhQ5EwfKEJuqsM/RD1FBG6SlEdd36rJESbreeqhqrcgingFdc1QPjC7p8snmqU8zoGKv3DpIy9xIkTsLOmLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AqK/GZgD5fpct+xudWySwwXuJ0FtVmRbDw+f9l4ru44=; b=Z5W7tumX0eky1x+iGbTMoOVgmeWH+Pd5ZM6LnRjGVU1NrL7dsVXnw/vn8fAU7MLDe7MJOmRiwq0g+oa8xUCJi3tAXKcj89n30gUPFF359PuJYg/96XZkZS8WcEdCfu6hJHvdjtGeMwDEH3z/RQno4hIndmP3PXE+xA40n7YEkTLGmhrblT/HZPS774MoQ32sE3xnvP+cItBVIM+B09Yw9JmLjJfxPQXnz9wB/NRMA1KpTLfvpYXK+qbrZGF1IKviyLuxnjh8rqwmlssYdiPMlTcg3IXNqIheI7trH9+AjoSOCVNuD54mcMvRQZ2IdxaNCykNCB1slQnqOfQrPN9YHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AqK/GZgD5fpct+xudWySwwXuJ0FtVmRbDw+f9l4ru44=; b=p4B07HvV+ko6YZ0qCPl8w7Vn5H7G9PyE2tW9uE/n2AILSozI7vRGFTS1lTEQ+jxHP8ZMq5qlKR2D+vasRNBqLQ4Sm3t6Rodh/EE/96xmvbdM0gI12sJRsrMXHEbK7s1iZjtlvmwEkuxzGsOpTzF/iWpwMIGGp3PiOB6/o578Sc8= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5471.namprd02.prod.outlook.com (2603:10b6:805:df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 23:35:50 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:35:50 +0000 From: "STARK, BARBARA H" To: "'Roman Danyliw'" , "'The IESG'" CC: "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'Donald Eastlake'" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWsUZg7R3CwOamn0mBtMrHTAE5sKm3CtQA Date: Wed, 4 Nov 2020 23:35:50 +0000 Message-ID: References: <160434187993.1575.17754543317504078999@ietfa.amsl.com> In-Reply-To: <160434187993.1575.17754543317504078999@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=att.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [144.160.96.109] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba234ce5-4b03-40f0-e16b-08d8811a5d37 x-ms-traffictypediagnostic: SN6PR02MB5471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RZF84/Te3TZF3eEWzoUBAT675Ng64g6hj7fuyyxUFn8l9dhzJuMSB3fPevM9lrE22/vONhuTtTGIIH0PX3ue00BdYdI98GSVBsWS7utE7AOahYQSFO76BU4FXjwchFaHtzz+FeFrjTJAwelfUq1A4CLaoxZjwZTUJZC9+ZJyTRpfS1dB0ThtKsReNnlFeaLBYktyrYNloREa9mYfVjCZ90cPD5uuBrCM8BbIXfK5BQalfzNL9sCU1h3Of/2K86akgjPZQaGvBzgqyq+y73XOjlCoiJ7frXono+pGpmbR5kB7zAL19qlGMo+cbHYsTRPZG3wmaseelK8aE8sNCFa9GA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(396003)(346002)(136003)(376002)(26005)(186003)(54906003)(478600001)(66574015)(7696005)(110136005)(83380400001)(8936002)(6506007)(55016002)(64756008)(66446008)(33656002)(82202003)(4326008)(2906002)(8676002)(66556008)(66476007)(71200400001)(76116006)(9686003)(86362001)(5660300002)(52536014)(316002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fTz4nQlkV0RAo+TKosifv0+/r2GPDxdch/zPHVlRbChifGBk+yjhXosvtstRkplowL+QTJbdS9pv/RwlyMXihBUq2Fd9ok2NJSBtgSAYbaSdOZBuEql0cf/pg/JNjuUjNEv4DeOhl4sWD7H5KzVOKySXstA1pwoeBeVhsYRmSkpJvohfGeinGZEIIDPMdWip7vfb/rwos5CHrWwvWtOyPKb35dqGzaOIwFwyVd3u8ldT+oHES2Kh8LmzOYdWd0rT6OBSz/LIunjF/RN8XrCFeBFpasBOPcy0CZT7gt+GGYRhPW6YKBRtBzv6XHjHK3gEANIu1ILU4KFK8Og/R70/AX8S069n+tPQ7r11BzEXRLc+eMON9KtrTP/jSBPaenR2Bw3m7S2yvnyLcXNyEa4OwuImOqdiuQXYRjZFBdLNxPq9Dm9Fcgx6KG/AtKaWtO5JzO4tmYUCyd01Be+fXoXRcoGHPo4H2tJwAsSgQZ2Z/NCOMjf51QqPsQs/v+TGYru3olPFSIKVBYux54U/BUPvrYI32MZi4ov9lUmu2QhvFcjcgWV/rZoixRn9FzXgrX3n0qY7sqNk4dqMdJ4KFn15UzpebqysFNa7QhbiUFD+NK9v/K1+gABZgDxlV6+zjHIBeHykT2QTcA4AEnPQj6oi4Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba234ce5-4b03-40f0-e16b-08d8811a5d37 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:35:50.5201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8U7hfLGCLa5P0jUqbAGf/6nzY7oJBKxpw6OH8hM3vMSqSV0dlBYfNum/xxznC3+T X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5471 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 9D0E6CC031A78EEEE2E2E0D45F5CDE7D750A479CAC4CB6EDAD7244233326595A2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_17:2020-11-04, 2020-11-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 priorityscore=1501 clxscore=1015 spamscore=0 lowpriorityscore=0 phishscore=0 malwarescore=0 impostorscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040168 Archived-At: Subject: Re: [babel] Roman Danyliw's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 23:36:11 -0000 SGkgUm9tYW4sDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3IChhbmQgVmFsZXJ5J3MsIHdoaWNoIEkn dmUganVzdCBzZW50IGEgcmVwbHkgdG8pLg0KSW4gbXkgcmVwbHkgdG8gVmFsZXJ5LCBJIGluZGlj YXRlZCB0aGF0IEkgZGlkbid0IHF1aXRlIGFncmVlIHdpdGggdGhlIHByb3Bvc2VkIHBhcmFtZXRl ciBuYW1lIGNoYW5nZXMgKHdoaWNoIHlvdSBzYWlkIHlvdSBkaWQgYWdyZWUgd2l0aCkuIFNvIHRo YXQgbWF5IG5lZWQgZnVydGhlciBkaXNjdXNzaW9uLg0KVGhhbmtzIGFnYWluLA0KQmFyYmFyYQ0K IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRo YW5rIHlvdSBmb3IgdGhlIFNFQ0RJUiByZXZpZXcgZnJvbSBWYWxlcnkgU215c2xvdi4gIFBsZWFz ZSByZXZpZXcgYW5kDQo+IHJlc3BvbmQNCj4gdG8gdGhlIHJlbWFpbmluZyBpdGVtcy4gIEluIHBh cnRpY3VsYXIsIEkgY29uY3VyIHdpdGggdGhlIHJlY29tbWVuZGF0aW9ucw0KPiBhYm91dA0KPiBw cmVjaXNlIGxhbmd1YWdlIGFyb3VuZCB0aGUgbmFtZXMgb2YgdGhlIHBhcmFtZXRlcnMuDQo+IA0K PiBTZWN0aW9uIDMuMS4gIGJhYmVsLWltcGxlbWVudGF0aW9uLXZlcnNpb24uICBJcyB0aGVyZSBh bnkgZ3VpZGFuY2Ugb24gdGhlDQo+IGZvcm1hdCBvZiB0aGlzIHN0cmluZyAob3IgaXMgaXQgZnJl ZSBmb3JtIGxpa2UgYSBTZXJ2ZXI6IGluIEhUVFApPw0KDQpJdCBpcyBmcmVlLWZvcm0uIEVhY2gg aW1wbGVtZW50YXRpb24gbWF5IGNob29zZSBpdHMgb3duIHZlcnNpb24gbmFtaW5nIGNvbnZlbnRp b24uDQoNCj4gU2VjdGlvbiAzLjEuICBiYWJlbC1tZXRyaWMtY29tcC1hbGdvcml0aG1zLCBiYWJl bC1tYWMtYWxnb3JpdGhtcywNCj4gYmFiZWwtZHRscy1jZXJ0LXR5cGVzLiAgSXMgdGhlcmUgYW55 IGd1aWRhbmNlIHRvIHByb3ZpZGUgb24gdGhlIGRlbGltaXRlcg0KPiBiZXR3ZWVuIGEgbGlzdCBv ZiB2YWx1ZXMsIG9yIGlzIHRoYXQgZXhwbGljaXRseSBhIGRhdGEgbW9kZWwgaXNzdWU/DQoNClRo YXQgaXMgZXhwbGljaXRseSBhIGRhdGEgbW9kZWwgaXNzdWUuIEJCRiBUUi0xODEgZG9lcyBpdCBk aWZmZXJlbnRseSBmcm9tIFlBTkcuDQoNCj4gU2VjdGlvbiAzLjEuIGJhYmVsLXNlY3VyaXR5LXN1 cHBvcnRlZCwgYmFiZWwtbWFjLWFsZ29yaXRobXMsDQo+IGJhYmVsLWR0bHMtY2VydC10eXBlcy4g IENvbnNpZGVyIHByb3ZpZGluZyBjaXRhdGlvbnMgb24g4oCcTUFD4oCdIGFuZCDigJxEVExT4oCd Ow0KPiBhbmQNCj4g4oCcSE1BQy1TSEEyNTbigJ0gYW5kIOKAnEJMQUtFMnPigJ07IGFuZCDigJxY LjUwOeKAnSBhbmQg4oCcUmF3UHVibGljS2V54oCdIChqdXN0IGxpa2UNCj4gd2FzIGRvbmUNCj4g Zm9yIGJhYmVsLW1ldHJpYy1jb21wLWFsZ29yaXRobXMpLg0KDQpGb3IgTUFDLCBITUFDLVNIQTI1 NiwgYW5kIEJMQUtFMnMgSSB3aWxsIGluY2x1ZGUgcmVmZXJlbmNlIHRvIElELmRyYWZ0LWlldGYt YmFiZWwtaG1hYw0KRm9yIERUTFMsIFguNTA5LCBhbmQgUmF3UHVibGljS2V5IEkgd2lsbCBpbmNs dWRlIHJlZmVyZW5jZSB0byBJRC5kcmFmdC1pZXRmLWJhYmVsLWR0bHMNClRoZXNlIGFyZSB0aGUg ZHJhZnRzIHRoYXQgZGVmaW5lIHRoZXNlIHRlcm1zIGluIHRoZSBjb250ZXh0IG9mIEJhYmVsIGFu ZCBwcm92aWRlIGZ1cnRoZXINCnJlZmVyZW5jZXMgdG8gdGhlIHNwZWNpZmljYXRpb25zIHRoYXQg bW9yZSBjb21wbGV0ZWx5IGRlZmluZSB0aGVtLg0KDQo+IFNlY3Rpb24gMy44LiAgYmFiZWwtbWFj LWtleS12YWx1ZS4NCj4gDQo+IElmIHRoZSBhbGdvcml0aG0gaXMgYmFzZWQgb24gdGhlIEhNQUMg Y29uc3RydWN0aW9uDQo+ICAgICAgIFtSRkMyMTA0XSwgdGhlIGxlbmd0aCBNVVNUIGJlIGJldHdl ZW4gMCBhbmQgdGhlIGJsb2NrIHNpemUgb2YgdGhlDQo+ICAgICAgIHVuZGVybHlpbmcgaGFzaCBp bmNsdXNpdmUgKHdoZXJlICJITUFDLVNIQTI1NiIgYmxvY2sgc2l6ZSBpcyA2NA0KPiAgICAgICBi eXRlcyBhcyBkZXNjcmliZWQgaW4gW1JGQzQ4NjhdKS4gIElmIHRoZSBhbGdvcml0aG0gaXMgIkJM QUtFMnMiLA0KPiAgICAgICB0aGUgbGVuZ3RoIE1VU1QgYmUgYmV0d2VlbiAwIGFuZCAzMiBieXRl cyBpbmNsdXNpdmUsIGFzIGRlc2NyaWJlZA0KPiAgICAgICBpbiBbUkZDNzY5M10uDQo+IA0KPiBJ IHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgd2FzIGFuIGluZm9ybWF0aW9uIG1v ZGVsIHRvIGVuY29kZQ0KPiBnZW5lcmljDQo+IEJhYmVsIHByb3RvY29sIHBhcmFtZXRlciBhbmQg dGhhdCB0aGUgdW5kZXJseWluZyBwcm90b2NvbCBkb2N1bWVudHMgZnVsbHkNCj4gc3BlY2lmaWVk IHRoZSBub3JtYXRpdmUgYmVoYXZpb3IuICBIb3dldmVyLCB0aGlzIGd1aWRhbmNlIGFwcGVhcnMg dG8gYmUNCj4gaW50cm9kdWNpbmcgbW9yZSByZXN0cmljdGl2ZSBjb25maWd1cmF0aW9uIGd1aWRh bmNlIG5vdCBmb3VuZCBpbg0KPiBkcmFmdC1pZXRmLWJhYmVsLWhtYWMgbWFraW5nIHRoaXMgZG9j dW1lbnQgYW4gaW5mb3JtYXRpb24gbW9kZWwgKyBwcm9maWxlLg0KPiBXYXMNCj4gdGhpcyBpbnRl bnRpb25hbD8NCg0KUGVyIFJGQzIxMDQgU2VjdGlvbiAyLCAiVGhlIGF1dGhlbnRpY2F0aW9uIGtl eSBLIGNhbiBiZSBvZiBhbnkgbGVuZ3RoIHVwIHRvIEIsIHRoZQ0KICAgYmxvY2sgbGVuZ3RoIG9m IHRoZSBoYXNoIGZ1bmN0aW9uLiAgQXBwbGljYXRpb25zIHRoYXQgdXNlIGtleXMgbG9uZ2VyDQog ICB0aGFuIEIgYnl0ZXMgd2lsbCBmaXJzdCBoYXNoIHRoZSBrZXkgdXNpbmcgSCBhbmQgdGhlbiB1 c2UgdGhlDQogICByZXN1bHRhbnQgTCBieXRlIHN0cmluZyBhcyB0aGUgYWN0dWFsIGtleSB0byBI TUFDLiIgDQpXaGVuIGNvbXBhcmluZyBpbXBsZW1lbnRhdGlvbnMgb2YgYmFiZWwtaG1hYyB3aXRo IEhNQUMtU0hBMjU2LCB0aGUgV0cgZGlzY292ZXJlZCB2YXJpYWJpbGl0eQ0KaW4gdGhlICJhY3R1 YWwga2V5IiB0aGF0IHJlc3VsdGVkIGZyb20gdXNpbmcga2V5cyBsb25nZXIgdGhhbiBCIGJ5dGVz LiBUaGUgY2F1c2UNCm9mIHRoZSB2YXJpYWJpbGl0eSB3YXMgaW4gdGhlIHVzZXIgaW50ZXJmYWNl IGFjY2VwdGluZyB0aGUgaW5wdXQgc3RyaW5nLCBhbmQgbm90IGluIHRoZSBhY3R1YWwNCmJhYmVs LWhtYWMgaW1wbGVtZW50YXRpb24uIFN0YW5kYXJkIGxpYnJhcnkgZnVuY3Rpb25zIHdlcmUgYmVp bmcgdXNlZCBmb3IgSE1BQyBhbGdvcml0aG0gYW5kDQpmb3IgdGhlIFVJIGFsbG93aW5nIGtleSBl bnRyeS4gU2luY2UgdGhlIHVzZXIgaW50ZXJmYWNlIGlzIGVmZmVjdGl2ZWx5IGFuIGluc3RhbnRp YXRpb24NCm9mIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCwgdGhlIGdyb3VwIGFncmVlZCB0aGF0IHRo ZSBpbmZvcm1hdGlvbiBtb2RlbCBzaG91bGQNCmltcG9zZSBhIHJlc3RyaWN0aW9uIG9uIHRoZSBp bnB1dCBzdHJpbmcgdGhhdCBndWFyYW50ZWVkIGludGVyb3BlcmFiaWxpdHkgYnkgZW5zdXJpbmcN CnRoZSBwcm92aWRlZCBzdHJpbmcgZGlkIG5vdCBoYXZlIHRvIGJlIGhhc2hlZCB0byBjYWxjdWxh dGUgdGhlICJhY3R1YWwga2V5Ii4gDQoNClBlciBzZWN0aW9uIDIuMSBpbiBSRkMgNzY5MywgS2V5 IEJ5dGVzIGZvciBCTEFLRTJzIGFyZSAiMCA8PSBrayA8PSAzMiIuIFNpbmNlIHRoaXMNCmlzIHRo ZSBrZXkgbGVuZ3RoIHNwZWNpZmllZCBieSB0aGUgQkxBS0UycyBSRkMsIHRoZSBpbmZvcm1hdGlv biBtb2RlbCBpcyBpbXBvc2luZw0KZXhhY3RseSB0aGlzIGxlbmd0aCByZXN0cmljdGlvbiBvbiB0 aGUga2V5IGlucHV0IHBhcmFtZXRlci4gUkZDIDc2OTMgaXMgbm9ybWF0aXZlDQp0byBkcmFmdC1p ZXRmLWJhYmVsLWhtYWMuDQoNCj4gU2VjdGlvbiAzLjggYW5kIDMuOS4gIGJhYmVsLW1hYy1rZXkt dGVzdCBhbmQgYmFiZWwtY2VydC10ZXN0LiAgSXQgd291bGQgYmUNCj4gdXNlZnVsIHRvIGV4cGxh aW4gdGhlIHVzZSBjYXNlIGZvciB0aGlzIHRlc3RpbmcgQVBJLg0KDQpPbmUgb2YgdGhlIG1vc3Qg Y29tbW9uIHByb2JsZW1zIGluIGNvbmZpZ3VyaW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMgaXMgaW4g dGhlIGZvcm1hdCBvZiB0aGUgaW5wdXQga2V5IChoZXgsIEFTQ0lJLCBiYXNlNjQsIGV0Yy4pLiBX aGVuIGEgc2VjdXJpdHkgbWVjaGFuaXNtIGZhaWxzIHRvIHdvcmssIGl0IGlzIGltcG9ydGFudCBm b3IgdXNlcnMgdG8gYmUgYWJsZSB0byB0cm91YmxlLXNob290IHRoaXMgc3BlY2lmaWMgcG9pbnQg b2YgZmFpbHVyZS4gVGhpcyB0ZXN0IGFsbG93cyB0aGUgdXNlciB0byBzZWUgaWYgd2hhdCB0aGlz IGRldmljZSB0aGluayB0aGUgaGFzaCBzaG91bGQgYmUgaXMgdGhlIHNhbWUgYXMgd2hhdCBhbm90 aGVyIGRldmljZSB0aGlua3MgdGhlIGhhc2ggc2hvdWxkIGJlIG9yIGlzIHRoZSBzYW1lIGFzIHRo ZSBoYXNoIGJlaW5nIHNlbnQgb24gdGhlIHdpcmUuIE1hbnkgSVNQcyBoYXZlIGJ1aWx0IGEgdGVz dCBsaWtlIHRoaXMgaW50byB0aGVpciBJU1Atc3VwcGxpZWQgQ0Ugcm91dGVycyAoaW52b2tlZCB1 c2luZyB0aGUgVFItMDY5IHByb3RvY29sIGFuZCBUUi0xODEgZGF0YSBtb2RlbCkuDQoNCj4gU2Vj dGlvbiA1LiAgTm90ZSB0aGF0IG9wZXJhdGlvbnMgYXJlIGFsc28gZXhwb3NlZCBpbiB0aGUgaW5m b3JtYXRpb24gbW9kZWwuDQo+IA0KPiBPTEQNCj4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgc2V0 IG9mIGluZm9ybWF0aW9uIG1vZGVsIG9iamVjdHMgYW5kDQo+ICAgIHBhcmFtZXRlcnMgdGhhdCBt YXkgYmUgZXhwb3NlZCB0byBiZSB2aXNpYmxlIGZyb20gb3RoZXIgZGV2aWNlcw0KPiANCj4gTkVX DQo+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIHNldCBvZiBpbmZvcm1hdGlvbiBtb2RlbCBvYmpl Y3RzLCAgICBwYXJhbWV0ZXJzLCBhbmQNCj4gb3BlcmF0aW9ucyB0aGF0IG1heSBiZSBleHBvc2Vk IHRvIGJlIHZpc2libGUgZnJvbSBvdGhlciBkZXZpY2VzDQoNCkknbGwgbWFrZSB0aGlzIGNoYW5n ZS4NCg0KPiBTZWN0aW9uIDUuICBQZXI6DQo+IA0KPiBNQUMga2V5cyBhcmUgYWxsb3dlZCB0byBi ZSBhcyBzaG9ydCBhcyB6ZXJvLWxlbmd0aC4gIFRoaXMgaXMgdXNlZnVsDQo+ICAgZm9yIHRlc3Rp bmcuICBOZXR3b3JrIG9wZXJhdG9ycyBhcmUgYWR2aXNlZCB0byBmb2xsb3cgY3VycmVudCBiZXN0 DQo+ICAgcHJhY3RpY2VzIGZvciBrZXkgbGVuZ3RoIGFuZCBnZW5lcmF0aW9uIG9mIGtleXMgcmVs YXRlZCB0byB0aGUgTUFDDQo+ICAgYWxnb3JpdGhtIGFzc29jaWF0ZWQgd2l0aCB0aGUga2V5LiAg U2hvcnQgKGFuZCB6ZXJvLWxlbmd0aCkga2V5cyBhbmQNCj4gICBrZXlzIHRoYXQgbWFrZSB1c2Ug b2Ygb25seSBhbHBoYW51bWVyaWMgY2hhcmFjdGVycyBhcmUgaGlnaGx5DQo+ICAgc3VzY2VwdGli bGUgdG8gYnJ1dGUgZm9yY2UgYXR0YWNrcy4NCj4gDQo+IEFkZCBjbGFyaWZ5aW5nIHRleHQgdGhh dCB0aGUgaW5mb3JtYXRpb24gbW9kZWwgZXhwbGljaXRseSBlbmFibGVzIHRoaXMgYnJ1dGUNCj4g Zm9yY2UgYXR0YWNrIHdoZXJlIG1vc3Qgb2YgdGhlIHdvcmtsb2FkIGlzIHB1c2hlZCBvbnRvIHRo ZSBzZXJ2ZXIgKHNpbmNlIGl0DQo+IGNvbXB1dGVzIHRoZSBoYXNoKS4gIEFsc28gYWRkIGEgbWl0 aWdhdGlvbi4gIFBlcmhhcHMgc29tZXRoaW5nIGxpa2Ug4oCcVGhpcw0KPiBpbmZvcm1hdGlvbiBt b2RlbCBwcm92aWRlcyBhbiBvcmFjbGUgdmlhIHRoZSBiYWJlbC1tYWMta2V5LXRlc3Qgb3BlcmF0 aW9uDQo+IHRoYXQNCj4gd291bGQgZW5hYmxlIHN1Y2ggYSBicnV0ZSBmb3JjZSBhdHRhY2suICBP cGVyYXRvcnMgU0hPVUxEIHJhdGUgbGltaXQgYWNjZXNzDQo+IHRvDQo+IHRoaXMgb3BlcmF0aW9u LuKAnQ0KDQpJJ20gc3RydWdnbGluZyB3aXRoIHRoaXMgY29tbWVudCBpbiBzZXZlcmFsIHdheXMu DQogLSBJbiBtb3N0IGV4cGVjdGVkIGluc3RhbnRpYXRpb25zIG9mIHRoZSBpbmZvcm1hdGlvbiBt b2RlbCAoYSB1c2VyIGludGVyZmFjZSwgQkJGIFRSLTE4MSwgWUFORyksDQphbmQgaW4gdGhlIGNv bnRleHQgb2YgdGhlIHByb3RvY29scyB0aGF0IHRyYW5zcG9ydCBhbmQgaW50ZXJwcmV0IHRoZXNl IGRhdGEgbW9kZWxzIChIVFRQUywNClRSLTA2OS9UUi0zNjksIE5FVENPTkYvUkVTVENPTkYpLCAi b3BlcmF0b3JzIiBoYXZlIGxpdHRsZSB0byBubyBhYmlsaXR5IHRvIHJhdGUgbGltaXQNCnNwZWNp ZmljIG9wZXJhdGlvbnMgLS0gdW5sZXNzIHRoZXkgYXJlIHRoZSBhY3R1YWwgaW1wbGVtZW50ZXJz IG9mIHRoZSBtYW5hZ2VtZW50IHByb3RvY29scy4NCkluIHRoZSBjb250ZXh0IG9mLCBmb3IgZXhh bXBsZSwgYSBwZXJzb24gY29uZmlndXJpbmcgdGhlaXIgb3duIGhvbWUgbmV0d29yaywgdGhlIA0K b25seSB3YXkgdGhlICJvcGVyYXRvciIgcmF0ZSBsaW1pdHMgdGhpcyBpcyBieSBkZWNpZGluZyBo b3cgZnJlcXVlbnRseSB0aGV5IHB1c2ggdGhlIGJ1dHRvbi4NCklmIGFuIElTUCBpcyBtYW5hZ2lu ZyB0aGUgaG9tZSBuZXR3b3JrIHJvdXRlciB2aWEgVFItMDY5L1RSLTM2OSwgaXQncyB1bmxpa2Vs eSB0aGUgSVNQDQpjYW4gcmF0ZSBsaW1pdCB0aHJvdWdoIGFueSBtZWFucyBvdGhlciB0aGFuIGNv ZGUgaW1wbGVtZW50YXRpb24uIElmIHJhdGUgbGltaXRpbmcgaXMgdG8NCmJlIGRvbmUgdmlhIHRo ZSBpbXBsZW1lbnRhdGlvbiwgdGhlbiB0aGUgYWR2aWNlIHNob3VsZCB0YXJnZXQgaW1wbGVtZW50 ZXJzLiBJdCdzIGNvbW1vbg0KZm9yIG1hbmFnZWQgZGV2aWNlcyB0byByYXRlIGxpbWl0IGV4ZWN1 dGlvbiBvZiB2YXJpb3VzIG9wZXJhdGlvbnMuDQotIEhhdmluZyBhY2Nlc3MgdG8gdGhpcyBvcGVy YXRpb24gaW1wbGllcyB0aGUgcGVyc29uIGhhcyBwZXJtaXNzaW9uIHRvIG1hbmFnZSB0aGUgcm91 dGVyLg0KSWYgc29tZW9uZSBoYXMgcGVybWlzc2lvbiB0byBtYW5hZ2UgdGhlIHJvdXRlciAoYW5k IHBlcm1pc3Npb24gdG8gaW52b2tlIHRoaXMgb3BlcmF0aW9uKQ0KYW5kIHJlYWxseSB3YW50cyB0 byBzZWUgd2hhdCBoYXBwZW5zIGlmIHRoZXkgcmVwZWF0ZWRseSBwdXNoIHRoZSBidXR0b24sIEkn bSBub3Qgc3VyZSBJIA0KYWdyZWUgdGhhdCBJRVRGIHNob3VsZCBiZSBzdWdnZXN0aW5nIHRoaXMg cGVyc29uIHNob3VsZCBkbyB0aGluZ3MgdG8gcmF0ZSBsaW1pdCB0aGVpciBwZXJzb25hbA0KYWNj ZXNzIHRvIHRoaXMgZnVuY3Rpb24uIA0KLSBJIGRvbid0IGNvbXBsZXRlbHkgdW5kZXJzdGFuZCAi dGhlIHdvcmtsb2FkIGlzIHB1c2hlZCBvbnRvIHRoZSBzZXJ2ZXIgKHNpbmNlIGl0DQpjb21wdXRl cyB0aGUgaGFzaCkiLiBCYWJlbCBoYXMgbm8gc2VydmVycy4gSW4gTkVUQ09ORi9SRVNUQ09ORiBt b2RlbCwgSSB0aGluayB0aGUNCm1hbmFnZWQgZGV2aWNlIGlzIHJlZmVycmVkIHRvIGFzIHRoZSBz ZXJ2ZXI/IEknbSBub3QgYSBORVRDT05GL1JFU1RDT05GIGV4cGVydC4NCkJ1dCBpcyB0aGF0IHRo ZSBzZXJ2ZXIgeW91J3JlIHRoaW5raW5nIG9mPyANCkluIEJCRiBwcm90b2NvbHMsIHRoZXJlJ3Mg bm90IGEgc3Ryb25nIGNsaWVudC9zZXJ2ZXINCmNvbmNlcHQsIGFuZCBtb3JlIGp1c3QgIm1hbmFn ZWQgZGV2aWNlIiBhbmQgIm1hbmFnZW1lbnQgc3lzdGVtIiBvciAiQWdlbnQiIGFuZCAiQ29udHJv bGxlciIuDQpCdXQgaWYgSSBhc3N1bWUgInNlcnZlciIgaXMgcmVmZXJyaW5nIHRvIHRoZSAibWFu YWdlZCByb3V0ZXIiLCB0aGVuIEkgdGhpbmsgeW91ciBwb2ludCBpcyB0aGF0DQp0aGlzIHRlc3Qg cmVxdWlyZXMgdGhlIG1hbmFnZWQgcm91dGVyIHRvIGNvbXB1dGUgYSBNQUMgZXZlcnkgdGltZSB0 aGUgdGVzdCBpcyBydW4gKHdoaWNoDQpjYW4gaW1wYWN0IHJvdXRlciBwZXJmb3JtYW5jZSwgZXNw ZWNpYWxseSBpZiB0aGUgdGVzdCBpcyByZXBlYXRlZGx5IGludm9rZWQpLiA/DQpJZiB0aGUgZ29h bCBpcyB0byBkZXRlcm1pbmUgdGhlIGtleSBieSBicnV0ZSBmb3JjZSwgSSB3b3VsZCB0aGluayB0 aGV5IHdvdWxkIHByaW1hcmlseSBuZWVkDQphIHBvd2VyZnVsIHN5c3RlbSB0aGF0IGNvdWxkIGNv bXB1dGUgTUFDcyBmb3IgYSBrbm93biBpbnB1dCBzdHJpbmcgdXNpbmcgaXRlcmF0aXZlIGtleSB2 YWx1ZQ0KZ3Vlc3Nlcy4gSXQgc2hvdWxkIG9ubHkgcmVxdWlyZSBhIHNpbmdsZSBjb21wdXRhdGlv biBvZiB0aGUgTUFDIGZvciB0aGF0IGlucHV0IHN0cmluZyBmcm9tIHRoZSANCnJvdXRlci4gT25j ZSB0aGUgcG93ZXJmdWwgc3lzdGVtIGhhcyBhIG1hdGNoLCBwZXJoYXBzIHRoZSBhdHRhY2tlciB3 b3VsZCB3YW50IHRvIHRyeSBhDQpkaWZmZXJlbnQgaW5wdXQgc3RyaW5nIHdpdGggdG8gc2VlIGlm IHRoZSBNQUMgZm9yIHRoYXQgYWxzbyBtYXRjaGVzLCB1c2luZyBpdHMgZ3Vlc3NlZCBrZXkuDQpC dXQgSSBkb24ndCBzZWUgdXNpbmcgdGhpcyB0ZXN0IHRvIGJlIGFuIGVmZmljaWVudCBicnV0ZSBm b3JjZSBtZWNoYW5pc20sIHNpbmNlIHRoZSBhdHRhY2tlciB3b3VsZA0Kc3RpbGwgaGF2ZSB0byBj b21wdXRlIGEgTUFDIG9uIHRoZWlyIGVuZCAoZm9yIGNvbXBhcmlzb24pIHdpdGggZWFjaCB0ZXN0 LiBJdCB3b3VsZCBiZSBhbHdheXMgYmUNCnNsb3dlciB0aGFuIGp1c3QgdXNpbmcgdGhlIG91dHB1 dCBvZiBhIHNpbmdsZSB0ZXN0IHRvIGl0ZXJhdGUgYWdhaW5zdC4NCk9mIGNvdXJzZSwgaWYgdGhl IGF0dGFja2VyIGNhbiBjYXB0dXJlIEJhYmVsIHBhY2tldHMgb24gdGhlIHdpcmUgd2l0aCBNQUNz LCB0aGlzIHdvdWxkIHByb3ZpZGUgdGhlbQ0Kd2l0aCBlcXVhbGx5IHVzYWJsZSBzYW1wbGVzIHRv IGl0ZXJhdGUgYWdhaW5zdC4NClNvIEkgZG9uJ3QgcmVhbGx5IHNlZSB0aGUgcG90ZW50aWFsIHRo cmVhdCBmcm9tIHJlcGVhdGVkIGV4ZWN1dGlvbiBvZiB0ZXN0cyBhcyBiZWluZyBhIGJydXRlIGZv cmNlIGF0dGFjaywgDQpidXQgcmF0aGVyIGEgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrLiANCkJ1 dCBJJ20gbm8gc2VjdXJpdHkgZXhwZXJ0LCBzbyBtYXliZSBJJ20ganVzdCBub3QgdW5kZXJzdGFu ZGluZyBob3cgdGhlc2UgdGhpbmdzIHdvcmsuIEFyZSANCm11bHRpcGxlIE1BQyBzYW1wbGVzIG5l ZWRlZCAoY29tcHV0ZWQgZnJvbSBkaWZmZXJlbnQgaW5wdXQgc3RyaW5ncykgZm9yIGEgc3VjY2Vz c2Z1bCBicnV0ZSBmb3JjZQ0KYXR0YWNrPyBJZiBzbywgaG93IG1hbnkgYXJlIG5lZWRlZD8NCg0K SSBhZ3JlZSB0aGF0IHRoZXJlIGNvdWxkIGJlIGEgc3RhdGVtZW50IGFib3V0IGltcGFjdHMgb2Yg TUFDDQpjb21wdXRhdGlvbiB0byBkZXZpY2UgcGVyZm9ybWFuY2UgdGhhdCBjb3VsZCBzZXJpb3Vz bHkgaW1wYWN0IHRoZSBhYmlsaXR5IG9mIHRoZSANCnJvdXRlciB0byByb3V0ZSwgDQphbmQgdGhh dCBCYWJlbCBpbmZvcm1hdGlvbiBtb2RlbCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHJhdGUgbGlt aXQgdGhlIGV4ZWN1dGlvbg0Kb2YgdGhpcyB0ZXN0LiANCg0KQnV0IEkgdGhpbmsgdGhlIG5vcm1h dGl2ZSBzdGF0ZW1lbnQgdGFyZ2V0aW5nIGltcGxlbWVudGVycyB3b3VsZCBiZSBiZXR0ZXIgDQpw bGFjZWQgaW4gdGhlIHBhcmFtZXRlciBkZXNjcmlwdGlvbi4NCg0KSSBwcm9wb3NlLCBpbiB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiwgYWRkICAoYWZ0ZXIgcGFyYWdyYXBoIG9u IGtleSANCmV4cG9zdXJlKToNCiJUaGUgYmFiZWwtbWFjLWtleS10ZXN0IG9wZXJhdGlvbiByZXF1 aXJlcyB0aGUgZGV2aWNlIHRvIGNvbXB1dGUgdGhlIE1BQw0KZXZlcnkgdGltZSBpdCBpcyBleGVj dXRlZC4gSWYgdGhpcyBvcGVyYXRpb24gaXMgZXhlY3V0ZWQgZnJlcXVlbnRseSwgaXQgY291bGQg ZGVncmFkZQ0KdGhlIGRldmljZSBwZXJmb3JtYW5jZSBhbmQgZWZmZWN0aXZlbHkgYWN0IGFzIGEg RGVuaWFsIG9mIFNlcnZpY2UgYXR0YWNrLiBUaGlzIGlzIHRoZSANCnJlYXNvbiB0aGlzIHBhcmFt ZXRlcidzIGRlc2NyaXB0aW9uIHJlY29tbWVuZHMgcmF0ZSBsaW1pdGluZyBleGVjdXRpb24NCm9m IHRoZSBvcGVyYXRpb24uIg0KDQpJbiB0aGUgYmFiZWwtbWFjLWtleS10ZXN0IGRlc2NyaXB0aW9u IGFkZCAiVGhlIGltcGxlbWVudGF0aW9uIFNIT1VMRCByYXRlDQpsaW1pdCBleGVjdXRpb24gb2Yg dGhpcyBvcGVyYXRpb24gdG8gYXZvaWQgZGVncmFkaW5nIHJvdXRlciBwZXJmb3JtYW5jZS4iDQoN Ci0gDQoNCg== From nobody Wed Nov 4 15:43:10 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501373A116E; Wed, 4 Nov 2020 15:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=att.onmicrosoft.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 2NdJus4BE2wq; Wed, 4 Nov 2020 15:43:07 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 57CEE3A1168; Wed, 4 Nov 2020 15:43:07 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A4NYs3b015566; Wed, 4 Nov 2020 18:43:06 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 34m085g7qv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 18:43:05 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4Nh4bA004140; Wed, 4 Nov 2020 18:43:04 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A4NgxCp004083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 18:42:59 -0500 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 67AD24016D7F; Wed, 4 Nov 2020 23:42:59 +0000 (GMT) Received: from GAALPA1MSGEX1BD.ITServices.sbc.com (unknown [135.50.89.105]) by zlp30487.vci.att.com (Service) with ESMTPS id 4D22C4016D82; Wed, 4 Nov 2020 23:42:59 +0000 (GMT) Received: from GAALPA1MSGEX1DB.ITServices.sbc.com (135.50.89.115) by GAALPA1MSGEX1BD.ITServices.sbc.com (135.50.89.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 18:42:38 -0500 Received: from GAALPA1MSGETA01.tmg.ad.att.com (144.160.249.126) by GAALPA1MSGEX1DB.ITServices.sbc.com (135.50.89.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 18:42:38 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.106) by edgeal1.exch.att.com (144.160.249.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 18:42:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZUrTdNpINpeP6HQrTeXTKr6CBCncCxvKJp7JZnYKu5aJP6qxOzxa30icgdR3TmBOJqo/ppXPl7/+oF1+yukuaxzn1ErY0kkbzvE4e2Pu6JB+d5GFPMTFJbxHVROAlm4skyQDWV5iZXB3oQq2nl+wsqmKHJgjWKtI6tJzU9Fciw5YsNH+/Wd+HYkZ+/pgi/Zbr6XR39RxMcikqfGOPV26sE9i/F+fhubEhbn6aje1uYvHZ5PkED68DY1RQQZas6vdxLafO37+z1UF5UlVMACqQ/2R4vGWT4IeDVm/MabdXT326ieag2ASowE3SRsQC3Z2EwxhIr281M6gPKTkFosizw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=peA6ZlwF+2haoMDPjFLsfskpgvMxUDVS2jZUUNjWKLU=; b=S8LPzAlz+6QyKGZC54Zw0UizqI/HlAPxfU/jmAFyB7LUhDjwzlNI5qrqhAoYBt9wX/HE2ACYjKHrgMDNmnnMlXyQMovpHk9J7XYxj3k3DkUhfXhQ30Hq3skNDHwIx25bzDELyo7qXauNPHCSZwIjs5POOR+zbH/GfoDWYeqAG2bXZOOfe5xpJi4PnU9VCJTu6f6M8xd2l8+9TltOZ0sjx3IM4rKC5qTWCWNqkbJhylJd+kzP2XC4prL9fFt9zoUu7NcinboSrUp9IMJYfYKVQ6T6cKyI4RqQrD93rWf6f7XvY1Fp3VQZm5ctNldEDK+isf0QCfFcVg0Q4k4wKhwZbQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=peA6ZlwF+2haoMDPjFLsfskpgvMxUDVS2jZUUNjWKLU=; b=DgJ00lv1zY+hDKB8ezdysM9PGP6MWJ1fxdbl+fRKKdzo3PgAPjxoBC+1oBIGjPC4uUFhUf0ZJbPAb2ENIloOGiIhQxe9y6SJrqTXRUl9vwTGq77laCsfOXI8p63AA/d3EttPIpxYzmcRnnbAAGcRUb2yqUq7hpUbjhWrEhbPvp8= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5471.namprd02.prod.outlook.com (2603:10b6:805:df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 4 Nov 2020 23:42:31 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Wed, 4 Nov 2020 23:42:31 +0000 From: "STARK, BARBARA H" To: =?utf-8?B?J0FudG9uaW4gRMOpY2ltbyc=?= , "'last-call@ietf.org'" , "'draft-ietf-babel-information-model.all@ietf.org'" , "'babel@ietf.org'" Thread-Topic: [babel] Last Call: , naming inconsistencies Thread-Index: AQHWq6CT/5N1+3233kaoJnBjzifPvam1UW5wgANe0zA= Date: Wed, 4 Nov 2020 23:42:31 +0000 Message-ID: References: <20201026140147.19834-1-antonin.decimo@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.109] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d3b31ed-3ad4-4ff0-1092-08d8811b4c04 x-ms-traffictypediagnostic: SN6PR02MB5471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oHDzG209ys2OlCVCrXWhuuTGForSNguZFmB7Ioid2jv9jbTFGPu21jLhmQArox/LWYjwEbfYs6VvLUOXMe6wazu6mcSC/nETI++AdrcPn2Uy16KATwU1kECFBrEpS2D2SO3wCUcxl6kwr81URrox1Pc59pFwU7A9Kd4+8ZnWftUWdonv+DnX2g52EJnk3hwsSgfES4Hhj5yxQZh+/Mk37NQcwfMNUWxqFYEAbL5BAGF2slmr9VRkZy2k+8ZXBouL2kgf445/TjO5O+CXKF/b92X6NZaiFlg8JG6kuNXrhwtNIe1Vf9MjgKGsfKrUHeuXcgWjQwAJmmqNDTfAPPqdHhaW1hn/sF55S/eIKm1fXJ8TG04R8apzhZN06sEIeJsy x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(136003)(346002)(39860400002)(366004)(76116006)(66556008)(66476007)(71200400001)(9686003)(86362001)(55016002)(64756008)(66446008)(33656002)(82202003)(2906002)(8676002)(316002)(66946007)(5660300002)(52536014)(66574015)(26005)(186003)(478600001)(8936002)(6506007)(83380400001)(110136005)(7696005)(53546011)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SbbqlQyqc9rB56K0v1C1jccGF64pfU4HPpzvqRPEV/uzvChhGEmKHAcV5dlpwptD9b7/hb1IykAkv4DngG8lF+LTaxTlhPfZqwEqQpKYcCDLiZvmgnfX/K1ZcfjYydylmP1Xk4vkuclae7MlKpH4VWfgsL1/qbDFVDwd2vrCZ4/XSnOks5jSRpAbAoBScRyNYtiDkdbCCMQ3C0r+RSAVfyZcUT4JCuQtGOC6iygQuG3xMTqJJIbaOhrNJbe0HMG+Gu08AXkhP/yNNPyumn17t2pr4woaTeBf367uBlD/Q+w2vjgFTxUC7u4bPSjSomkszmv/Kd/nVPrbTvcU8yKj8NepL/Qd3svCMy89dI1aC7p4lqWLvBjt2FOEfMHG/kQwtet9/O4NfCtVCAEe0OpBy4vhU8bKAoCTrjwE9hec6mTi7GLlh2Gzlknn1KkfmYZumttyCA5HnjIhCOJ7iY3I9a8LU43D52nDC+BPyA5Xxpm3drolKqnFKWSnw07J6LHVqXvmpWYiKFptIxssznT4n1iONC1Gzs2Z927pIUPhKdf+ujfLenylo8TS36BYt3yF/t6xxN07U1SaO/mnIj09Y2nfFeSwr25Hl95C/6O1a54OK/Znr1mqceHK/vdp01XCw5DXZUgT5mmVdVG7iJDkrw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d3b31ed-3ad4-4ff0-1092-08d8811b4c04 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 23:42:31.1790 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: l7RGci090mqoPQJjzN+90XtzRtoV7L31npxm5gRA/vqFDk+J1Gg0O6G3F5O1P8ij X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5471 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 8C65A494C71B67CD4E1FEBC7AC85D9B85208DBE27233044C573209597745FBFA2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-04_17:2020-11-04, 2020-11-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 malwarescore=0 suspectscore=0 priorityscore=1501 adultscore=0 spamscore=0 mlxscore=0 bulkscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011040168 Archived-At: Subject: Re: [babel] Last Call: , naming inconsistencies X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 23:43:09 -0000 VGhhbmsgeW91IEFudG9uaW4sIGZvciBoZWxwaW5nIG1lIChpbiBhIHByaXZhdGUgZW1haWwgZXhj aGFuZ2UpIGlkZW50aWZ5IG1vcmUgb2YgdGhlc2UgaW5jb25zaXN0ZW5jaWVzLiBUaGlzIGlzIHRo ZSBhZGRpdGlvbmFsIHNldCB3ZSBpZGVudGlmaWVkOg0KDQpPTEQNCiAgIH0gYmFiZWwtbWFjLW9i ajsNCk5FVw0KICAgfSBiYWJlbC1tYWMta2V5LXNldC1vYmo7DQoNCk9MRA0KICAgYmFiZWwtbWFj LWRlZmF1bHQtYXBwbHk6ICBBIEJvb2xlYW4gZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgdGhpcw0K ICAgICAgYmFiZWwtbWFjIGluc3RhbmNlIGlzIGFwcGxpZWQgdG8gYWxsIG5ldyBiYWJlbC1pbnRl cmZhY2UNCk5FVw0KICAgYmFiZWwtbWFjLWRlZmF1bHQtYXBwbHk6ICBBIEJvb2xlYW4gZmxhZyBp bmRpY2F0aW5nIHdoZXRoZXIgdGhpcw0KICAgICAgb2JqZWN0IGluc3RhbmNlIGlzIGFwcGxpZWQg dG8gYWxsIG5ldyBiYWJlbC1pbnRlcmZhY2UNCg0KT0xEDQogICAgICBpbmNsdWRpbmcgaXQgaW4g dGhlIGJhYmVsLWludGVyZmFjZS1tYWMta2V5cyBsaXN0LiAgSWYgImZhbHNlIiwNCk5FVw0KICAg ICAgaW5jbHVkaW5nIGl0IGluIHRoZSBiYWJlbC1pZi1tYWMta2V5LXNldHMgbGlzdC4gIElmICJm YWxzZSIsDQoNCk9MRA0KICAgYmFiZWwtZHRscy1kZWZhdWx0LWFwcGx5OiAgQSBCb29sZWFuIGZs YWcgaW5kaWNhdGluZyB3aGV0aGVyIHRoaXMNCiAgICAgIGJhYmVsLWR0bHMgaW5zdGFuY2UgaXMg YXBwbGllZCB0byBhbGwgbmV3IGJhYmVsLWludGVyZmFjZQ0KTkVXDQogICBiYWJlbC1kdGxzLWRl ZmF1bHQtYXBwbHk6ICBBIEJvb2xlYW4gZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgdGhpcw0KICAg ICAgb2JqZWN0IGluc3RhbmNlIGlzIGFwcGxpZWQgdG8gYWxsIG5ldyBiYWJlbC1pbnRlcmZhY2UN Cg0KQmFyYmFyYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNUQVJL LCBCQVJCQVJBIEgNCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwMiwgMjAyMCAyOjE1IFBNDQo+ IFRvOiAnQW50b25pbiBEw6ljaW1vJyA8YW50b25pbi5kZWNpbW9AZ21haWwuY29tPjsgJ2xhc3Qt Y2FsbEBpZXRmLm9yZycgPGxhc3QtDQo+IGNhbGxAaWV0Zi5vcmc+OyAnZHJhZnQtaWV0Zi1iYWJl bC1pbmZvcm1hdGlvbi1tb2RlbC5hbGxAaWV0Zi5vcmcnIDxkcmFmdC1pZXRmLQ0KPiBiYWJlbC1p bmZvcm1hdGlvbi1tb2RlbC5hbGxAaWV0Zi5vcmc+OyAnYmFiZWxAaWV0Zi5vcmcnIDxiYWJlbEBp ZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtiYWJlbF0gTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1i YWJlbC1pbmZvcm1hdGlvbi1tb2RlbC0xMS50eHQ+LA0KPiBuYW1pbmcgaW5jb25zaXN0ZW5jaWVz DQo+IA0KPiBIaSBBbnRvbmluLA0KPiBUaGFua3MgYWdhaW4uIEkgc2VlIGluIHRoaXMgZW1haWwg dGhhdCwgaW4gYWRkaXRpb24gdG8gdGhlIHByZXZpb3VzIDIgZXJyb3JzDQo+IHJlbGF0ZWQgdG8g bWFjLWtleS1zZXRzLCB5b3UgaW5jbHVkZSBjb3JyZWN0aW9ucyBmb3IgU2VjdGlvbiAyOg0KPiAN Cj4gLSAgICstLSByb3V0ZXItaWQNCj4gLSAgICstLSBzZWxmLXNlcW5vDQo+IA0KPiArICAgKy0t IGJhYmVsLXNlbGYtcm91dGVyLWlkDQo+ICsgICArLS0gYmFiZWwtc2VsZi1zZXFubw0KPiANCj4g SSdsbCBpbmNsdWRlIHRoZXNlIGZpeGVzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+IFRoeCwNCj4g QmFyYmFyYQ0KPiANCj4gPiAtLS0NCj4gPiBEZWFyIGFsbCwNCj4gPg0KPiA+IEnigJl2ZSBmb3Vu ZCBzb21lIGluY29uc2lzdGVuY2llcyBpbiB0aGUgbmFtaW5nIG9mIHNvbWUgZmllbGRzIGluIHRo ZQ0KPiA+IEJhYmVsIEluZm9ybWF0aW9uIE1vZGVsLiBJ4oCZdmUgYWxyZWFkeSBzZW5kIG1haWxz IGFib3V0IHRoZW07IGJ1dCBJ4oCZbQ0KPiA+IGFmcmFpZCBteSBtYWlscyBtaWdodCBoYXZlIGZh bGxlbiBpbiBsaW1iby4gVGhlIGlzc3VlIGlzIG1pbm9yLg0KPiA+IEJlbG93IGlzIGEgcGF0Y2gg Zm9yIHRoZSBmaWVsZHMuDQo+ID4NCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4NCj4gPiBBbnRvbmlu DQo+ID4NCj4gPg0KPiA+ICBkcmFmdC1pZXRmLWJhYmVsLWluZm9ybWF0aW9uLW1vZGVsLm1kIHwg OCArKysrLS0tLQ0KPiA+ICAxIGZpbGUgY2hhbmdlZCwgNCBpbnNlcnRpb25zKCspLCA0IGRlbGV0 aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyYWZ0LWlldGYtYmFiZWwtaW5mb3JtYXRp b24tbW9kZWwubWQgYi9kcmFmdC1pZXRmLWJhYmVsLQ0KPiA+IGluZm9ybWF0aW9uLW1vZGVsLm1k DQo+ID4gaW5kZXggNzk5MGI3YS4uMTU4ODc5NyAxMDA2NDQNCj4gPiAtLS0gYS9kcmFmdC1pZXRm LWJhYmVsLWluZm9ybWF0aW9uLW1vZGVsLm1kDQo+ID4gKysrIGIvZHJhZnQtaWV0Zi1iYWJlbC1p bmZvcm1hdGlvbi1tb2RlbC5tZA0KPiA+IEBAIC0xNzksOCArMTc5LDggQEAgVGhlIEluZm9ybWF0 aW9uIE1vZGVsIGlzIGhpZXJhcmNoaWNhbGx5IHN0cnVjdHVyZWQNCj4gYXMNCj4gPiBmb2xsb3dz Og0KPiA+ICArLS0gYmFiZWwtaW5mb3JtYXRpb24NCj4gPg0KPiA+ICAgICArLS0gYmFiZWwtaW1w bGVtZW50YXRpb24tdmVyc2lvbg0KPiA+DQo+ID4gICAgICstLSBiYWJlbC1lbmFibGUNCj4gPg0K PiA+IC0gICArLS0gcm91dGVyLWlkDQo+ID4NCj4gPiAtICAgKy0tIHNlbGYtc2Vxbm8NCj4gPg0K PiA+ICsgICArLS0gYmFiZWwtc2VsZi1yb3V0ZXItaWQNCj4gPg0KPiA+ICsgICArLS0gYmFiZWwt c2VsZi1zZXFubw0KPiA+DQo+ID4gICAgICstLSBiYWJlbC1tZXRyaWMtY29tcC1hbGdvcml0aG1z DQo+ID4NCj4gPiAgICAgKy0tIGJhYmVsLXNlY3VyaXR5LXN1cHBvcnRlZA0KPiA+DQo+ID4gICAg ICstLSBiYWJlbC1tYWMtYWxnb3JpdGhtcw0KPiA+DQo+ID4gQEAgLTUzNCw3ICs1MzQsNyBAQCBi YWJlbC1tYWMtZW5hYmxlOg0KPiA+ICAgIEFuIGltcGxlbWVudGF0aW9uIE1BWSBjaG9vc2UNCj4g Pg0KPiA+ICAgIHRvIGV4cG9zZSB0aGlzIHBhcmFtZXRlciBhcyByZWFkLW9ubHkgKCJybyIpLg0K PiA+DQo+ID4NCj4gPg0KPiA+IC1iYWJlbC1pZi1tYWMta2V5cy1zZXRzOg0KPiA+DQo+ID4gK2Jh YmVsLWlmLW1hYy1rZXktc2V0czoNCj4gPg0KPiA+ICA6IExpc3Qgb2YgcmVmZXJlbmNlcyB0byB0 aGUgYmFiZWwtbWFjIGVudHJpZXMgdGhhdCBhcHBseSB0byB0aGlzDQo+ID4NCj4gPiAgICBpbnRl cmZhY2UuIFdoZW4gYW4gaW50ZXJmYWNlIGluc3RhbmNlIGlzIGNyZWF0ZWQsIGFsbCBiYWJlbC1t YWMta2V5LXNldHMNCj4gPg0KPiA+ICAgIGluc3RhbmNlcyB3aXRoIGJhYmVsLW1hYy1kZWZhdWx0 LWFwcGx5ICJ0cnVlIiB3aWxsIGJlIGluY2x1ZGVkDQo+ID4NCj4gPiBAQCAtODI4LDcgKzgyOCw3 IEBAIGJhYmVsLW1hYy1kZWZhdWx0LWFwcGx5Og0KPiA+ICAgIGFwcGxpZWQgdG8gYWxsIG5ldyBi YWJlbC1pbnRlcmZhY2UgaW5zdGFuY2VzLCBieSBkZWZhdWx0Lg0KPiA+DQo+ID4gICAgSWYgInRy dWUiLCB0aGlzIGluc3RhbmNlIGlzIGFwcGxpZWQgdG8NCj4gPg0KPiA+ICAgIG5ldyBiYWJlbC1p bnRlcmZhY2VzIGluc3RhbmNlcyBhdCB0aGUgdGltZSB0aGV5IGFyZSBjcmVhdGVkLCBieSBpbmNs dWRpbmcNCj4gPg0KPiA+IC0gIGl0IGluIHRoZSBiYWJlbC1pbnRlcmZhY2UtbWFjLWtleXMgbGlz dC4NCj4gPg0KPiA+ICsgIGl0IGluIHRoZSBiYWJlbC1pZi1tYWMta2V5LXNldHMgbGlzdC4NCj4g Pg0KPiA+ICAgIElmICJmYWxzZSIsIHRoaXMgaW5zdGFuY2UgaXMgbm90IGFwcGxpZWQgdG8gbmV3 IGJhYmVsLWludGVyZmFjZXMNCj4gPg0KPiA+ICAgIGluc3RhbmNlcyB3aGVuIHRoZXkgYXJlIGNy ZWF0ZWQuDQo+ID4NCj4gPiAgICBBbiBpbXBsZW1lbnRhdGlvbiBNQVkgY2hvb3NlDQo+ID4NCj4g PiAtLQ0KPiA+IDIuMjkuMQ0KDQo= From nobody Wed Nov 4 17:24:24 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4583A1155; Wed, 4 Nov 2020 17:24:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <160453946202.22882.3587018410396865705@ietfa.amsl.com> Date: Wed, 04 Nov 2020 17:24:22 -0800 Archived-At: Subject: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 01:24:22 -0000 Martin Duke has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I am concerned about the congestion implications of this architecture. If there are P prefixes in the network, the number of TLVs exchanged potentially goes from P to P^2. Perhaps this is an unrealistic use case. But are there any safeguards in the protocol against this happening (e.g. limitations on size/freq of updates?) Or ought there to be some operational guidance to be somewhat selective about source prefixes? From nobody Wed Nov 4 19:51:01 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD51F3A1692; Wed, 4 Nov 2020 19:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 bGso4SklWNVa; Wed, 4 Nov 2020 19:50:57 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 E62723A1691; Wed, 4 Nov 2020 19:50:56 -0800 (PST) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A53ipFc027236; Wed, 4 Nov 2020 22:50:55 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 34kd6bwcxn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Nov 2020 22:50:55 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A53oshM010415; Wed, 4 Nov 2020 22:50:54 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A53oqwV010403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Nov 2020 22:50:52 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id E86B5400B57B; Thu, 5 Nov 2020 03:50:51 +0000 (GMT) Received: from MISOUT7MSGEX2CB.ITServices.sbc.com (unknown [135.66.184.206]) by zlp27128.vci.att.com (Service) with ESMTPS id D0E0D400AF73; Thu, 5 Nov 2020 03:50:51 +0000 (GMT) Received: from MISOUT7MSGEX2CA.ITServices.sbc.com (135.66.184.193) by MISOUT7MSGEX2CB.ITServices.sbc.com (135.66.184.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Wed, 4 Nov 2020 22:50:51 -0500 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2CA.ITServices.sbc.com (135.66.184.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Wed, 4 Nov 2020 22:50:51 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Wed, 4 Nov 2020 22:50:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P1hHTCip9QimhoSksLsdhABC7GtKwx7rV0I2/a6DWQbp2Bv8r/mFOGP+ARSELujY9ARdCiiGcKC+LCKYtjoCZd39De5RN4/txW8/I4UqzNdYcMhXPplRBQiqJPxLOVObfvez3gnMDRQ5/TTN1o16gwr8AxvHrJpM/DfbspVEO5ToMltalyzab1ASP8L0BJCHe81odgI/iy8v5QZdDhyQn3t1Xn7mkfd5Vp9fiK7CQ2KKQn6CIwnS/gAog9UmeyLdINmO/VFnHH9cjCKSmeCfZswgxtdhEy1WHy8nSHrxskYVmqndAnrFOTS/wQrjcqMq6MteVyvxYMtGh44vcwTFbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YuDIuN1tYHFALimRjWZlNA3z8o/L2PkMj/kP2vXlVmM=; b=Dzc6XpRJt/1vx53nIV1AUtL/pmBmQqCLKEeBCrnNkm5m1DX+iXHPtKaZsYFHWEEilyyy3vUi01dFjLgZAV8s7HX/G/TPEbiQZFruNs4lLiDQZNzv0vJ5EqV+pRJUjt9sYVMos5HqBXXBA12Qs1bjgZuvSsJZhZ6OMH2piUusHOlgVGYiFIa/2deojboMUuo5LiWc+eKupTx9Azuc+fJf0Yy7YNWDMpZ7htGJ2VhEowSrkK/23YSIXuNZ+F2ibE09b5jkSGZLUb4B0+s9vqm9hphRn6JERromud0gemUGGX+7dMqGlZlhqlJbRN4wnPx4CPh8dXXGbxbeIhI4TgIksw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YuDIuN1tYHFALimRjWZlNA3z8o/L2PkMj/kP2vXlVmM=; b=PD6hjfQy6oyNAwJnBewjsc///L7+/KJPk0rtbv+mlTH6F8m6qP7sF5UdUatDkj744w+c6GLCGY38zbdbD38cFgKAogWaN7Z5y/2S7HsSWnXRLjWa/mP1liE9l1/Wk3q3zf0sEbj2VgX/qm6G7asZjstM7+HTxlQDQ+Ovg0Y2J3A= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN4PR0201MB3407.namprd02.prod.outlook.com (2603:10b6:803:4f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.30; Thu, 5 Nov 2020 03:50:49 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 03:50:49 +0000 From: "STARK, BARBARA H" To: "'Erik Kline'" , "'The IESG'" CC: "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'Donald Eastlake'" Thread-Topic: Erik Kline's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWsnXs7K0MF6ZjSk2aid4/viyFeKm45qtw Date: Thu, 5 Nov 2020 03:50:49 +0000 Message-ID: References: <160447222149.25425.9921856923705203834@ietfa.amsl.com> In-Reply-To: <160447222149.25425.9921856923705203834@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [144.160.96.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d653f5e-9da2-4c40-a534-08d8813dfc49 x-ms-traffictypediagnostic: SN4PR0201MB3407: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jW9EGnBix5p0WqFo+lWCy3YehOXHELbYfxbUZ9lVyyenHEjNJdWgQx643CV2B3g0RcRj8UpHVmMzSLQ7k/DUAaFAHQah2/njJ/0P4geyIzmfdbssp/L8cP9vFhxljgzT/n0GJ4gFU0yS2GgieWK0H3xu4pYnPV3v/UYT7TV+37sS/e+C91la6CiLdrjLW+355DTJ0xsatQ7ZTaN3+ppg1Or3E29W3/XcvqY7XhiSCRjZ46n38cB4v0+hERaYeyMWmMdxpogcQmN77RfPmYav3U/4cNdT6E0b0i6As2/vbgsKERZwHyMz/oTUK7zlGhqDHNZtzWCo8Fk7oJInYGn71A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(39860400002)(366004)(396003)(110136005)(6506007)(9686003)(55016002)(316002)(54906003)(66446008)(186003)(26005)(5660300002)(64756008)(66946007)(76116006)(66476007)(66556008)(52536014)(8936002)(4744005)(4326008)(86362001)(2906002)(82202003)(7696005)(71200400001)(33656002)(8676002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: zf/WISrYstGKbr14JxWDivz48Xes3h7NfCzA27QueTKdetFyr4uaIEEsojDI3hUROKfOVMhu92RUEpKTIKW0fbfLk+Us+zrIqO+p2Gs1dGp1z9c6pbbeIctsLghFulwBGmj4Uj/jC6vrqtMGnbQDEsU3JpZIYjjaOSkTSB6BB9sm7IGcyauFg/87fsC7mWuUKJ6ClXmsJhNrMa5Zhqgpn1q0cJ59Y8sY/u7aOJw6cd7V2/fKQI+rv5PbfGPzUwNTEHfWYAoLTPlwclJDWJDXILXb/FgZMOuBUmLLoiLGJrjPoAx2U8kZ9kqRnfmyy1HLlkwPqJTia9cgTM7OUiwMcmX1VVO7G1HCeY6rtFdxgYFHIYrNU5JcXqJ12sSukS1zG74pnXcGFXrtUmicLCmdqZGLB60RABqH8LFRkAPyNaTE/BVy0PRxtvTWYJWvuHdP6O3m5xACRy3gTz76J0EO5AnZCFIqGCY0DE1QJPsVjGq/uVhGSORiWMuuJVRvHV1jOlXMKnxIVubUQYtrBzca9tW9u96L3M5etoSIOTn/RlavkR47iOgJtwr303tbxf4wFS0tU4k+5qdleTZrhcVaA+95YGGFtpCayq1uX1YIMALV1wfjK7oCD3pcqYjOGzBvCWFL97yrczcpa62ef7oUUg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d653f5e-9da2-4c40-a534-08d8813dfc49 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 03:50:49.7938 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kvenXPiXejyofb+OVEo/Ap2saclbtwbBmmqZmpgTt/tbNq30QckdYNe+FhPxPlrt X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0201MB3407 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 53BB82B3CF055813F08F9802FF5B1569AA52CC9010BDEB6B2768FC5F5E6ABAD02 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-05_01:2020-11-05, 2020-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 adultscore=0 mlxlogscore=843 malwarescore=0 priorityscore=1501 clxscore=1015 spamscore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011050026 Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 03:51:00 -0000 SGkgRXJpaywNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIE15IGNvbW1lbnQgaXMgYmVsb3cuDQpC YXJiYXJhDQogDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiANCj4gW1sgbml0cyBdXQ0KPiANCj4gWyBzZWN0aW9uIDMuMSBdDQo+IA0KPiAqIHMvcnVubmlu ZyBhbmQgb3BlcmF0aW9uYWwvcnVubmluZyBhbnkgb3BlcmF0aW9uYWwvPw0KDQpUaGUgcnVubmlu ZyBkYXRhc3RvcmUgYW5kIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBhcmUgZGlzdGluY3QgY29uY2Vw dHMuDQpTb21lIGRhdGEgbW9kZWxzIChsaWtlIFlBTkcpIGhhdmUgZGlzdGluY3QsIHJlcGxpY2F0 ZWQgc2V0cyBvZiBwYXJhbWV0ZXJzIGZvciB0aGVzZS4NCk90aGVycyAobGlrZSBUUi0xODEpIGRv bid0LCBhbmQgdXNlIHR3byBzZXBhcmF0ZSBwYXJhbWV0ZXJzLg0KSSBiZWxpZXZlIHRoZSAiYW5k IiBpcyBjb3JyZWN0Lg0K From nobody Wed Nov 4 20:12:59 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F38FC3A1363; Wed, 4 Nov 2020 20:12:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160454957752.16050.14365004360878554303@ietfa.amsl.com> Date: Wed, 04 Nov 2020 20:12:57 -0800 Archived-At: Subject: [babel] Erik Kline's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 04:12:58 -0000 Erik Kline has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 4 ] * Per RFC 5952 section 4.3, please s/2001:DB8/2001:db8/g From nobody Wed Nov 4 21:06:37 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 057DF3A16B7; Wed, 4 Nov 2020 21:06:35 -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-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160455279459.19842.7370627868131264527@ietfa.amsl.com> Date: Wed, 04 Nov 2020 21:06:35 -0800 Archived-At: Subject: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 05:06:35 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- What's an example of when one might deviate from the SHOULD in Section 4? From nobody Wed Nov 4 22:23:10 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 031643A0317; Wed, 4 Nov 2020 22:23:05 -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-babel-information-model@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160455738479.29698.10710227486204000135@ietfa.amsl.com> Date: Wed, 04 Nov 2020 22:23:05 -0800 Archived-At: Subject: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 06:23:05 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd writeup is more than a year old. I wonder if we should get into the habit of asking that these be refreshed before they're scheduled on telechats. Please fix the boilerplate text from BCP 14 (your Section 1.1). Lastly, +1 to Barry's comments. From nobody Wed Nov 4 23:49:06 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 068543A0A16; Wed, 4 Nov 2020 23:49:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com, david@opensourcerouting.org, as@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160456253967.7318.72519100069215705@ietfa.amsl.com> Date: Wed, 04 Nov 2020 23:49:00 -0800 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-source-specific-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 07:49:00 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). The topic of source address dependent routing is really critical for IPv6 deployment, so, I really appreciate your work on the topic Please find below one blocking DISCUSS point (trivial to fix), some non-blocking COMMENT points, and some nits. I also second Warren's DISCUSS on the lack of clarity in the section 4 example I hope that this helps to improve the document, Regards, -éric == DISCUSS == Please update IPv6 reference from RFC 2460 to RFC 8200: I told you that this was an easy to fix DISCUSS point ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == COMMENTS == Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even cited as informative reference. Same for reference to RFC 8678. -- Section 3.1 -- Is the first "prefix" the "destination prefix" in the following text? If so, then I suggest to write "destination prefix" or explain what is this "prefix": "The source table is now indexed by triples of the form (prefix, source prefix, router-id)." -- Section 4 -- May I suggest to add another example with 2 entries have the same destination prefix but different source prefixes ? -- Section 6 -- May be my lack of knowledge in Babel is the reason why I do not understand the loop avoidance description... As written in the text, a single non-source-aware router in the network could be enough to introduce loop (in specific configurations). Writing the following text appear to me as a little hand waving because how can this be ensure (I was about to file a block DISCUSS on this but I am trusting the routing AD on this topic): " Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur." -- Section 6.2 -- The last paragraph is also a little hand waving where it is assumed that network topology/configuration is specific to avoid a route starvation. -- Section 7.1 -- Should the text state the obvious by stating that the prefix (non 8 multiple) is padded with bits set to 0 on transmission and those bits are ignored on reception ? == NITS == -- Section 4 and possibly others -- Please use RFC 5952 to write IPv6 addresses. -- Section 5.2 -- Please introduce the "AE" acronym at first use (even if guessable in the context). From nobody Thu Nov 5 00:31:15 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFE93A0CED; Thu, 5 Nov 2020 00:31:12 -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, 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=smyslov.net 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 ZjB8NjI-AlW4; Thu, 5 Nov 2020 00:31:10 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 3AE383A0D7A; Thu, 5 Nov 2020 00:31:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=smyp4gkeyr/QM4VbvelMhjEzUww+uXapWogK8oE8R7A=; b=HDpyQF2mLvcKHeyjbl9ta4f0d3 MDvIrKrQMvHMJTBIjGsq/Tl8e1XK7kBuH06OAgn+g4hoj7vjBKBim4zvyJU6OqmEkf8PEQD0PN8rn YZFXUiT+FxJ2K4Vgd1XKTAesGLzejU9N1TFNrG3jcZup35qg8xthJYpRjPt+9QW+8kc4ohYWobz9b 6mUIylQga+1H5jR0gngYA/ShjzO7ucqOSDUAFaOBoPdhGgbm3nj6u0eYrdmgMmhMBLl/rfs+qV3Q9 zEkv0AKPmBLQheNmteZvFpFzRKMpcNt6NoTMw8gJyrrSQkrG9IZ0aTir8BI8NDqFf2k/8DSNrKT8b znD4/iyQ==; Received: from [93.188.44.203] (port=52799 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kaafh-0004KO-0N; Thu, 05 Nov 2020 03:31:06 -0500 From: "Valery Smyslov" To: "'STARK, BARBARA H'" , Cc: , , References: <160372407981.20077.17795340180313190981@ietfa.amsl.com> In-Reply-To: Date: Thu, 5 Nov 2020 11:30:50 +0300 Message-ID: <000c01d6b34d$fc3bf5d0$f4b3e170$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQLzl3GE/vg7EqYbxZxh9fZc9poL0gGkJUa0p3IwJ7A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [babel] Secdir last call review of draft-ietf-babel-information-model-11 X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 08:31:13 -0000 Hi Barbara, > Hi Valery, > Thanks for your review. Taking into account Juliusz' response to your email, I'm proposing the following > resolutions. For the first issue raised, I'm disagreeing slightly with Juliusz, so that may need further discussion. > Please let me know if you disagree. I've copied Juliusz' responses here, so I can include my responses to your > complete feedback and his in one email. > Roman specifically mentioned he agreed with your "recommendations about precise language around the > names of the parameters". I think perhaps this was in reference to item 4 under nits? I didn't completely agree > with your recommendation, so I'd appreciate some additional discussion on that. > Thx, > Barbara > > > -----Original Message----- > > > > Reviewer: Valery Smyslov > > Review result: Has Issues > > > > I have reviewed this document as part of the security directorate's ongoing > > effort to review all IETF documents being processed by the IESG. These > > comments were written primarily for the benefit of the security area > > directors. > > Document editors and WG chairs should treat these comments just like any > > other > > last call comments. > > > > The document defines an informational model for Babel routing protocol. > > This > > informational model can be used as a basis for creating various data models > > (e.g. YANG). The document is properly structured and well written, however > > I think that it has some issues concerned with security. > > > > Issues. > > > > 1. Section 3.1: > > > > babel-mac-algorithms: List of supported MAC computation algorithms. > > Possible values include "HMAC-SHA256", "BLAKE2s". > > > > BLAKE2s can produce MACs of different sizes from 1 to 32 bytes and the > > desired > > size of the MAC is a parameter for it. Where the size of MAC is specified? For > > HMAC with SHA256 I can at least imagine that full 256 bits output is used as a > > MAC... > > Juliusz said: > > Right. The intent is that Blake2s is used with 32-octet keys and 16-octet > > hashes (collision-resistance is not a concern for Babel-MAC while > > dictionary attacks are). Barbara, I think that you should explicitly > > state that Blake2s implies 128-bit hashes. (You may also consider > > renaming BLAKE2s to BLAKE2s-128.) > > The defined values for babel-mac-algorithms come directly from draft-ietf-babel-hmac. The defined value > names should map closely to the names used for the algorithms in in that draft -- which they currently do. > > If it needs to be explicitly stated somewhere that an implementation of draft-ietf-babel-hmac with BLAKE2s > outputs 128-bit MACs, then draft-ietf-babel-hmac (which was already submitted for publication) would be the > correct place to say that. The information model is not the right place, unless there's some expectation for the > size to be configurable or reportable. I'm not seeing any request for the MAC size to be configured or reported > via the information model. > > I'm proposing no change to the defined values of babel-mac-algorithms in order to maintain complete > consistency with the names used in draft-ietf-babel-hmac-12. My point was that the intent Juliusz mentioned (that Blake2s is used with 32-octet keys and 16-octet hashes) must be documented somewhere. If you think it must be in the draft-ietf-babel-hmac, I'm fine with this, but currently I cannot find any such requirement anywhere. > > 2. Section 3.9: > > > > babel-cert-test: An operation that allows a hash of the provided > > input string to be created using the certificate public key and > > the SHA-256 hash algorithm. Input to this operation is a binary > > string. The output of this operation is the resulting hash, as a > > binary string. > > > > I failed to understand what this operation should do. Literally reading it is > > intended to produce SHA2-256 hash of public key and some arbitrary string > > (concatenated? in what order?). But then I failed to understand the purpose > > of > > this test. I would have understood if this operation provides signing of the > > arbitrary string using private key and SHA2-256 as a hash function (similarly > > to babel-mac-key-test), but it in not what is written... > > One of the most common problems in configuring security mechanisms is in the format of the input key (hex, > ASCII, base64, hashing that occurs to create "actual key", etc.). When a security mechanism fails to work, it is > important for users or device managers to be able to trouble-shoot this specific point of failure. This test > allows the user/manager to see if what this device thinks the MAC should be is the same as what another > device thinks the MAC should be or is the same as the MAC being sent on the wire. Many ISPs have built a test > like this into their ISP-supplied CE routers (invoked using the TR-069 protocol and TR-181 data model) to test > various stored key values. It has proven useful. I'm still confused. Are we talking about MACs or about certificates for DTLS? I have no problems with text describing test for MAC keys. The text I'm having problem with is about testing certificates for DTLS. The test it describes is not clear for me: it suggests to perform SHA2-256 hash of an input string "using the certificate public key". It is unclear for me how you would use the certificate public key to produce a hash of some input string. So I believe the test should be clarified. > > 3. Section 5 (Security Considerations): > > > > I think that text about keys (their length and properties) needs some > > expansion. First, there are no any RFC2119 words discouraging using short > > and > > weak keys (there is some text, but without RFC2119 words and with no > > references > > it's just hand waving). Note, that draft-ietf-babel-hmac-12 has some text > > about > > the properties of the keys, so I believe at least it must be referenced here. I > > also suspect that explicitly allowing zero-length and short keys will lead to > > situations when some network operators will use them (because they are > > not > > prohibited), thus subverting security properties of MAC... > > Thanks. I'll add a reference to draft-ietf-babel-hmac Security Considerations. > > Zero length and short keys were discussed on the mailing list. The group considered it appropriate to > allow configuration of zero-length keys for testing but to advise people to follow best > current practices. I find the use of normative language to attempt to control the behavior of > a home network owner (for example) or someone setting up an informal ad hoc mesh > network (for example) to be odd. IMO, the IETF should not seek to control > the choices of people putting together such relatively small-scale networks through > the use of strong normative language in an information model specification. It's > impossible to enforce and such people pretty much never read RFCs. > > If there is a strong desire for some sort of normative language, then I could suggest > OLD > MAC keys are allowed to be as short as zero-length. This is useful > for testing. Network operators are advised to follow current best > practices for key length and generation of keys related to the MAC > algorithm associated with the key. Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. > NEW > MAC keys are allowed to be as short as zero-length. This is useful > for testing. Network operators are RECOMMENDED to follow current best > practices for key length and generation of keys related to the MAC > algorithm associated with the key. Short (and zero-length) keys and > keys that make use of only alphanumeric characters are highly > susceptible to brute force attacks. See the Security Considerations > section of [ID.draft-ietf-babel-hmac] for additional considerations > related to MAC keys. I would suggest additionally using "SHOULD NOT" for weak keys. How about the following new text: MAC keys are allowed to be as short as zero-length. This is useful for testing. Network operators are RECOMMENDED to follow current best practices for key length and generation of keys related to the MAC algorithm associated with the key. Short (and zero-length) keys and keys that make use of only alphanumeric characters are highly susceptible to brute force attacks and thus SHOULD NOT be used. See the Security Considerations section of [ID.draft-ietf-babel-hmac] for additional considerations related to MAC keys. (note that "SHOULD NOT" still allows people to shoot in their feet if they want to). > > Nits. > > > > 1. Section 1 (Introduction): > > > > [I-D.ietf-babel-hmac] defines a > > security mechanism that allows Babel packets to be cryptographically > > authenticated, and [I-D.ietf-babel-dtls] defines a security mechanism > > that allows Babel packets to be encrypted. > > > > DTLS provides both confidentiality and authentication of data, so to be > > formally correct, please add "both authenticated and" before "encrypted". > > Thank you. I will make this change. Thank you. > > 2. Section 2 (Overview) at the very end: > > > > Note that this overview is intended simply to be informative and is > > not normative. If there is any discrepancy between this overview and > > the detailed information model definitions in subsequent sections, > > the error is in this overview. > > > > This phrase makes me puzzled. The tree-like description of the information > > model in the Overview is very useful, however this phrase seems to > > discourage > > using it, because authors are not sure it is correct. I think it would be > > better for readers if authors double check that no discrepancy exists > > between > > the overview and the subsequent detailed description and remove this > > phrase. > > The authors have double- and triple-checked, but human error is still possible, since these were not auto- > generated (like YANG does). Whenever redundant information is presented, it is critical that it be normative in > only one place. This language makes it clear which is normative and what to do in the case of discrepancies. I > propose no change. If there is a strong push to remove this language, then I believe the correct approach > would be to remove the entire section (remove the redundancy) rather than to allow confusion if there is an > error. But people have found this section useful, so I would prefer to leave it as is. OK. > > 3. Section 3.3: > > > > babel-mac-verify A Boolean flag indicating whether MAC hashes in > > incoming Babel packets are required to be present and are > > verified. If this parameter is "true", incoming packets are > > required to have a valid MAC hash. An implementation MAY choose > > to expose this parameter as read-only ("ro"). > > > > "MAC hashes" is strange wording, "MAC values" or just "MACs" are better in > > my > > opinion. > > Thank you. I'll change it to MAC. Thanks. > > 4. Section 3.8: > > > > babel-mac-key-use-sign: Indicates whether this key value is used to > > sign sent Babel packets. Sent packets are signed using this key > > if the value is "true". If the value is "false", this key is not > > used to sign sent Babel packets. An implementation MAY choose to > > expose this parameter as read-only ("ro"). > > > > "Sign" is not a good word when you describe symmetric key operations > > (which > > computing MAC belongs to). Although it is often used informally, I think that > > RFC should be more meticulous in selecting words. I'd rather replace it with > > "compute MAC" and rename the entry to babel-mac-key-use-compute or > > babel-mac-key-use-mac (if it is possible). Note, that using "verify MAC" is OK. > > I've been thinking through this. I can't speak to the informal nature of "sign", but I can say that simply > replacing "sign" with "compute" or "mac" wouldn't convey correctly what this parameter is about. This > parameter is primarily concerned with whether or not a MAC is included in the sent packet. The sending is the > critical piece, and not the computing (it's possible to compute the MAC without sending it; a MAC in a sent > packet is assumed to have been computed). I could change the description to: > Indicates whether this key value is used to compute a MAC and include that MAC in the > sent Babel packet. A MAC for sent packets is computed using this key > if the value is "true". If the value is "false", this key is not > used to compute a MAC to include in sent Babel packets. An implementation MAY choose to > expose this parameter as read-only ("ro") I'm fine with this. > But I struggle with the proposed parameter renaming. I strongly believe the name should concisely describe > that the Boolean value indicates whether or not to include a MAC in the sent packet. The term "sign" is one > I've commonly seen to indicate that a MAC is included in the sent packet. I'm not aware of a different, > similarly short word. "Compute" and "mac" do not convey the sending aspect. And sending is very > asymmetric. How about "use"? > > 5. Section 3.8: > > > > babel-mac-key-value: > > ... > > This value is of a length suitable for the associated babel-mac-key- > > algorithm. If the algorithm is based on the HMAC construction > > [RFC2104], the length MUST be between 0 and the block size of the > > underlying hash inclusive (where "HMAC-SHA256" block size is 64 > > bytes as described in [RFC4868]). If the algorithm is "BLAKE2s", > > the length MUST be between 0 and 32 bytes inclusive, as described > > in [RFC7693]. > > > > I wonder of the rationale for imposing the above restrictions on HMAC key > > length. HMAC can use keys of any length, but if the key is greater than block > > size of underlying hash function, then it's first hashed (small performance > > penalty). So I imagine that the rationale is to avoid this penalty. However, as > > RFC2104 states, key sizes greater than output length of the underlying hash > > function (32 bytes in case of SHA2-256) would not significantly increase the > > function strength, so it's just a waste of space. See also Issue 3 above. > > Juliusz said: > > This was discussed at length on the mailing list. It's not about > > performance, it's about making it more difficult to use an unsafe > > procedure for generating keys. > > > > Since Babel-MAC is vulnerable to dictionary attacks, the key must either > > be drawn randomly or generated using a procedure that is hardened against > > such attacks (scrypt, etc.). Applying the procedure described in RFC 2104 > > to a user-provided passphrase is not safe, and therefore we try to make it > > difficult for a naive user to do so. > > > > I am opposed to putting the RFC 2104 hashing procedure in the information > > model. Doing so would be a disservice to our users. > > In addition to the rationale Juliusz mentioned, we (babel WG) also noted that implementers > of the babel MAC function were using existing libraries for the HMAC-SHA256 algorithm. > The user interface (UI) that accepted manual key entry was also from an existing library. When > the same longer strings were entered into different UIs of the different implementations, these > strings were treated differently and resulted in non-interoperability. The "actual key" (using > RFC 2104 words) ended up different. Requiring entered keys to be directly usable as "actual > keys" solved this problem. BTW, I have considered UIs for direct management and configuration > to effectively be implementations of the information model. > > I recommend no changes to this text. I can live with this if you add "SHOULD NOT" for zero-length keys in the Security Consideration (as I suggested above). > > 6. Section 3.8: > > > > babel-mac-key-test: An operation that allows the MAC key and hash > > algorithm to be tested to see if they produce an expected outcome. > > Input to this operation is a binary string. The implementation is > > expected to create a hash of this string using the babel-mac-key- > > value and the babel-mac-key-algorithm. The output of this > > operation is the resulting hash, as a binary string. > > > > The text mixes up words "hash" and "MAC". MAC is not a hash (even if MAC > > algorithm is often based on hash function). As with my previous grunt, I'd like > > RFC to be more meticulous in selecting words. Please, avoid using "hash" > > here. > > If I understand, the suggestion is to reword as: > babel-mac-key-test: An operation that allows the MAC key and MAC > algorithm to be tested to see if they produce an expected outcome. > Input to this operation is a binary string. The implementation is > expected to create a MAC of this string using the babel-mac-key- > value and the babel-mac-key-algorithm. The output of this > operation is the resulting MAC, as a binary string. > > If this is right, I'll make that change. Great, thank you. > > 7. Section 5 (Security Considerations): > > > > ... This model requires that private keys never be > > exposed. The Babel security mechanisms that make use of these > > credentials (e.g., [I-D.ietf-babel-dtls], [I-D.ietf-babel-hmac]) > > identify what credentials can be used with those mechanisms. > > > > Please add "and MAC keys" after "private keys" since formally private keys > > are > > only defined for public key cryptography. > > Thank you. I'll make this change. Thanks. > > 8. Section 5 (Security Considerations): > > > > MAC keys are allowed to be as short as zero-length. This is useful > > for testing. > > > > I wonder what's benefit of allowing zero-length keys for testing purposes. > > What > > is intended to be tested in this case? Implementation of MAC? Is it really > > needed outside test lab? Am I missing something? > > As with the -test actions, this allows someone to diagnose whether a problem they are having is with the > formatting > of the input key (hex, padded, ASCII, base64, etc.). This is by far one of the most common problems when > attempting to > get different implementations to interoperate. OK, but I'd rather still add "SHOULD NOT" for using them as I suggested above. > > 9. Section 5 (Security Considerations): > > > > Short (and zero-length) keys and > > keys that make use of only alphanumeric characters are highly > > susceptible to brute force attacks. > > > > Formally, brute force attack with zero-length keys is not defined, since there > > is no key to find and all is in clear. > > Juliusz said: > > The key length is not carried in the clear by the protocol. Guessing the > > key length requires a brute-force attack, even when it is zero. > > I propose no change. OK. > > Comments. > > > > 1. The document contains an entry in the Informational model defining which > > hash functions can be used with HMAC authentication. However, there is no > > corresponding entry of which ciphersuites can be used with DTLS. Is it up to > > DTLS library to select ciphersuites? > > Juliusz said: > > Yes. Babel-DTLS is intended to inherit the security properties of the > > system's DTLS library. If the DTLS library is unsafe, then Babel-DTLS > > must not be used until the library is fixed. Regards, Valery. From nobody Thu Nov 5 01:33:23 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4A3A172C; Thu, 5 Nov 2020 01:33:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160456880126.24423.3828288743954574173@ietfa.amsl.com> Date: Thu, 05 Nov 2020 01:33:21 -0800 Archived-At: Subject: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-babel-source-specific-07=3A_=28with_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 09:33:21 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Dear all, please accept my apologies for the wrong DISCUSS point... a copy and paste error done without enough coffee... There are NO DISCUSS point in my ballot] Thank you for the work put into this document. The document is easy to read albeit not always clear and specific (see later). The topic of source address dependent routing is really critical for IPv6 deployment, so, I really appreciate your work on the topic Please find below some non-blocking COMMENT points, and some nits. I also second Warren's DISCUSS on the lack of clarity in the section 4 example I hope that this helps to improve the document, Regards, -éric == COMMENTS == Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is an expired RTG WG adopted document and is not even cited as informative reference. Same for reference to RFC 8678. -- Section 3.1 -- Is the first "prefix" the "destination prefix" in the following text? If so, then I suggest to write "destination prefix" or explain what is this "prefix" with reference to the Bable RFC: "The source table is now indexed by triples of the form (prefix, source prefix, router-id)." -- Section 4 -- May I suggest to add another example with 2 entries have the same destination prefix but different source prefixes ? -- Section 6 -- May be my lack of knowledge in Babel is the reason why I do not understand the loop avoidance description... As written in the text, a single non-source-aware router in the network could be enough to introduce loop (in specific configurations). Writing the following text appear to me as a little hand waving because how can this be ensure (I was about to file a block DISCUSS on this but I am trusting the routing AD on this topic): " Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur." -- Section 6.2 -- The last paragraph is also a little hand waving where it is assumed that network topology/configuration is specific to avoid a route starvation. -- Section 7.1 -- Should the text state the obvious by stating that the prefix (non 8 multiple) is padded with bits set to 0 on transmission and those bits are ignored on reception ? == NITS == -- Section 4 and possibly others -- Please use RFC 5952 to write IPv6 addresses. -- Section 5.2 -- Please introduce the "AE" acronym at first use (even if guessable in the context). From nobody Thu Nov 5 03:42:54 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4A3A177B; Thu, 5 Nov 2020 03:42:52 -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, 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=toke.dk 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 NzVql12SAt6L; Thu, 5 Nov 2020 03:42:50 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 27FA03A1774; Thu, 5 Nov 2020 03:42:49 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604576566; bh=0Gmb1sTMBVytksvQbDJI7kJR0+b1l9aT4fBMUit2+ZY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=uiLGnOhixSV5vb3SsS03YQM6whTZCJn16UJUHCvCUg95H3B/6UvcjjX3qCrmlnv4q nw5mJDcFr1YhH0mdgTS7mQO2pxLt8R2OyOIydq4c/27UmTBvy+jWbTChZda4yES7au 7T2V/P3XOpUoZPS5pjGzAN4KH5x1MT8ETprnQnRDbIC0ElzbxyrsfMeNUVNXw+KQHh kK4m0OdtervoGFRt3nJvGYDqGq7oW7quoeCXPUJ0Pic85FCBjYdRu/QVhRQPqX4gqg ruwz5EINAQw39E3A/jG6Ui2eCG+RyH1zDwMKotV49KUak7fMN6FxxEiRB21/294+xu SeBRUh3kQ4OPQ== To: Murray Kucherawy , The IESG Cc: babel-chairs@ietf.org, Donald Eastlake , babel@ietf.org, draft-ietf-babel-source-specific@ietf.org In-Reply-To: <160455279459.19842.7370627868131264527@ietfa.amsl.com> References: <160455279459.19842.7370627868131264527@ietfa.amsl.com> Date: Thu, 05 Nov 2020 12:42:43 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87pn4st4gc.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 11:42:52 -0000 Murray Kucherawy via Datatracker writes: > Murray Kucherawy has entered the following ballot position for > draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > What's an example of when one might deviate from the SHOULD in Section > 4? Only thing I can think of is that if someone already implemented a disambiguation like that suggested in the second bullet, and the underlying platform then adds native support, one could conceivably continue using the disambiguation instead of switching to the native support. The Linux kernel is an example of this: in ancient times there was no native support for source-specific routing, but it was possible to use the generic policy routing mechanism to achieve this. When the native support was added, it came with a new UAPI, so a routing daemon would have to change to support it, while the old policy-based way would still work. Or maybe an implementation wants to support ancient kernels with the same code and keeps using the policy-routing based way; it would likely be somewhat painful, but in principle I suppose it could work. -Toke From nobody Thu Nov 5 03:53:29 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9913A178E; Thu, 5 Nov 2020 03:53:27 -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, 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=toke.dk 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 v9WJPVhB284L; Thu, 5 Nov 2020 03:53:25 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 29D3D3A1762; Thu, 5 Nov 2020 03:53:17 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604577195; bh=ds8NYESpwEsNTDF6lK5Oa1TYYRB4vnepdVGq17O234U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ndykGdixzWCq20eRmw7HTr8MNLo6haZ+rZvWCwSneqJ/w+6qXmVDlYLKdx+60a/Wz 5cHPnsHWSzM2dJlVJ1pRLkoHWt22khK8R/o4aZdo9Mp+1yamO7q79uhHXSKfJ+naWt +AVcj2a+tN4571tpjrux+NkJPGlBdQLj1fclWth9CSNnYI6xwXU6DEMEbyJtL8SCDD WYh0ADJ91gcKtA6DKvMxMr+9xcTbcqLsgReOCifRHct03WARCt6lyfCLBAu46dPcrk Wv6BDpJOFpHL/2gQywko9TVJeDhmB5u/WQs4rSjckoRmsM8kb8LVe97Mru8HKUVYJa IqLWA5/HFJBZg== To: Martin Duke , The IESG Cc: babel-chairs@ietf.org, d3e3e3@gmail.com, babel@ietf.org, draft-ietf-babel-source-specific@ietf.org In-Reply-To: <160453946202.22882.3587018410396865705@ietfa.amsl.com> References: <160453946202.22882.3587018410396865705@ietfa.amsl.com> Date: Thu, 05 Nov 2020 12:53:15 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k0v0t3ys.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 11:53:28 -0000 Martin Duke via Datatracker writes: > Martin Duke has entered the following ballot position for > draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I am concerned about the congestion implications of this architecture. If there > are P prefixes in the network, the number of TLVs exchanged potentially goes > from P to P^2. > > Perhaps this is an unrealistic use case. But are there any safeguards in the > protocol against this happening (e.g. limitations on size/freq of updates?) Or > ought there to be some operational guidance to be somewhat selective about > source prefixes? The way it's been used in deployments that I'm aware of, generally only default routes are distributed with a source prefix, and more specific routes internally to the network do not have source prefixes. See my reply to Alvaro for a fuller example: https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/ -Toke From nobody Thu Nov 5 04:17:23 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EE93A17AD; Thu, 5 Nov 2020 04:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CIOskoyr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M/68BdSe 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 UgmPQW3EmVkI; Thu, 5 Nov 2020 04:17:17 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A350D3A175F; Thu, 5 Nov 2020 04:17:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13243; q=dns/txt; s=iport; t=1604578636; x=1605788236; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2HmiGB0H8CffiGM4GRbSWZc/6MhJEiyc/AgQT0FbakE=; b=CIOskoyrzCVKxOA4iV+yI4EYzjaEBlXAC1mtp3nZqQ8tsoL5DjEF/h2x tc98X+VL5Bpai2/NAMOMER5r06ERSJ138N+1y5Ky6PbhRu+RJhdOeijdm 3YdQRXZzxw+bo41p2X80fYfUp1GjJjwaz3JCCsV/BpF9DB3z0ytmn4O2R o=; IronPort-PHdr: =?us-ascii?q?9a23=3AwE/6oBbUlybu/7Kw/zZgAkn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD4re4vNAzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXxYlTTpju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCCABb7KNf/4sNJK1iHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgSMvIy4HcFkvLgqHfAONUooTiX2Eb4FCgREDVAsBAQENAQEjCgI?= =?us-ascii?q?EAQGESgKCDQIlOBMCAwEBCwEBBQEBAQIBBgRxhWEMhXIBAQEEEhsTAQE3AQ8?= =?us-ascii?q?CAQgOAwQBASgHIREUCQgCBA4FCBqDBYF+TQMuAQMLpSwCgTuIaHSBNIMEAQE?= =?us-ascii?q?FgUdBgwENC4IQAwaBOIJyhHeFURuBQT+BEUOCTz6CG0ICAQIBgSYBEgEjKwm?= =?us-ascii?q?DFIIskDyCagGHV4wMkEdUCoJtiQqMbASFMYMYihKUQ55Fgm6SXgIEAgQFAg4?= =?us-ascii?q?BAQWBayNnWBEHcBWDJFAXAg2OHzeDOoUUhUR0AjYCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,453,1596499200"; d="scan'208,217";a="581172858" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2020 12:17:15 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A5CHF8p008306 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2020 12:17:15 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 06:17:14 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 06:17:14 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 5 Nov 2020 06:17:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NOvkJl/ocCj2tkYLjVKE9EVipR9lcsgTLTl06QcZaHGzDUxg4RqSHZGUl3NP+WQBDp8DO9YpW8WediY5PKL856NWdQ6V1avUvGChucRmQ4CRXqfOzyIS4rviGyYGK/V/z5Yr4FphcG7e/DwEWN9CHL2iLEUN9RY7kCeAAXvZpB2dko5Nns8Gtl0q0fgpn/6ctV5KFB9ZuG7HAkKMq6pgkaDtbFRCxHdFMVrrfI3UZWAaJFYKup2UOKim+r+ioiRIOwgDP2MriVvge5ftiPY5oOBPLDhPQtBHBbPfaZTAbOniLkCFZNG+Z/EOpFjVZ3phbMz0Rmo/oe9OTXluQO5+xA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PTY0/N8Iorm78BBr9PK4rgK7ktwQcNVWw92xbmfFbEg=; b=jcJ8S1zzbm+obYR6mF4zU9KDVu7mWLDTtxXy6hdOtVJ/zazYnPuqcA086Npkh0kPD9g/NN3tgaXqGsHcVkVs9ZIPodhXskt7p9WlAt3MG0lIWJ1+lfKWhjU04h4jT9n6HUuKNBUMUxtakBsoaLQ0Ub4e5zEpa/1Ds0c1A9nJ9qdNHDeMmVXU0OpPY/oAeqq0uQFPsX1r/9qd/ZjQ9UP3Ux2es1tYvnYzRmst5KgNVoUwxNeWijUHt86Y6F8D+ZXYqpfrYwk/hzpQ1lByrDcluisuVIn4UYY6/B3IandjVk4qN4c/m/L8D7YKBz+cLyVRoaf2cxfTxsv7TBOfsVkj1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PTY0/N8Iorm78BBr9PK4rgK7ktwQcNVWw92xbmfFbEg=; b=M/68BdSeELNVYOxUOzVBg/I6lZBlTnfKmTpKcAP2AHtYau4rC62hKQfuxoK2exMDCjcl5FzaSL5jzUa37hYZ9aG/Bp+f8kT5hni7qrSYiyKP5lo6BRxT+qLRUmteZFt+NY515DnroWIoQoGk+mt67b3U976Uq1Sg2M8zyNvr6ms= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3379.namprd11.prod.outlook.com (2603:10b6:208:6c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 5 Nov 2020 12:17:12 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 12:17:12 +0000 From: "Rob Wilton (rwilton)" To: Mahesh Jethanandani CC: The IESG , "draft-ietf-babel-information-model@ietf.org" , "babel-chairs@ietf.org" , Babel at IETF , Donald Eastlake Thread-Topic: Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWstKEauXNYVcus0S2zygoFtlS3am4SaMAgAEpNVA= Date: Thu, 5 Nov 2020 12:17:12 +0000 Message-ID: References: <160451197790.28880.17597785068103610213@ietfa.amsl.com> <0CA8EA3A-4BB0-46EF-8FAC-D11B846852B4@gmail.com> In-Reply-To: <0CA8EA3A-4BB0-46EF-8FAC-D11B846852B4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b41ac939-e901-426a-28a5-08d88184b9e0 x-ms-traffictypediagnostic: BL0PR11MB3379: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aOzE/gulQg2ZiPuiPkZbhbsDCYtDMODMB7GThQk6tfMfYQ1FSIGvSk1Wjjn0PegKlbMoDtY0a54a9qKRRDsfUX+BDOlMFcdK2KofDphfO8Kp0vsj7YPIvUIIL+DxEcSbelqXEAIQgzTKEQg3nonp5UoQl3Qty3cLX0Tt5wmuejjaWfixydsxkBWdFb4TznV+m+EbqARN3XoV1L4dYAm16HhW/GZ5WzrXxYXd25bDyHQJA/rIk4q5o1MX5J+Pvgvg6mzwlvB+ngLDfawE0Nz7YVzrEiTUqgJqa91nlkoWRvFNlQ73GQlTSX7+aq8hjbO6z3sfG2WU244Cdas8Ukq6LNArI0FfSVZoLaYwBmghfmXCfEdN1+NzsSCpuPAjwQH6PEhKvQ/DAeeAr2QYgGgyUg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(136003)(366004)(376002)(6506007)(52536014)(64756008)(7696005)(66556008)(66446008)(53546011)(478600001)(4326008)(66476007)(966005)(186003)(33656002)(2906002)(5660300002)(66946007)(26005)(9686003)(76116006)(55016002)(86362001)(8936002)(9326002)(71200400001)(21615005)(8676002)(6916009)(54906003)(166002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: v5MMa3/py6idKCBmMxgW2/ORCRKC1AqhqqU23J/nW+q4WYa+IQ2JD6JRqd3ZeXXL1yjTE99GJBDe38+DnkikFApf6ORRG+kIDGy0Bzxg/Te7R8EfXwqbwDeqvNXhV7f2MhWvcgvXSxDY6NWVkSOSC1oJQRp+24tpPBBynvmIMyvKZ+rhfEGV+rAaV6dO9dqxNBYYn5ZoPU6qqqcqPrsUvY8jUThObGHngP7IH45DyKtm2u2adPnduxANUspOheMu0JosOkbkEoibih2b8UFt/eer8LoDuENUbTDkngDkOZ6lHRFqqnDJxGpTDQjYp2Jyku8DzvcNgtT/uzm55u98T7s7cU6NXBPCYdkdY9WvMbLIjXpqB6VoalQdv7UNxAGscVhThjXtUV/RYMeUPexUhEUc9i84rBRHwKbfI9Elpsv1s8fA80KPY1wwadXUusrxhMP8/K1R+qHJJGxx3MlosRld3lpNTgbeEVbvjXNK1Hp9IbBI36zd3eueCF5+LieRAIebhaQCH8GJ7SZICE6SritP+8evvXn6g0eDV8CRzyP1AshGYjuLytvxthaAAyNHui0XfliZU6SyC/ouZEQGnrHIDzd13zCG7myx5XEjxTjOEAvqpH6T+fo37DOEGBI6jRU1xqV0rx02Josqsc07Qg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b41ac939-e901-426a-28a5-08d88184b9e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 12:17:12.6167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f6k2VDXqXid4hc2wX0ghCKF7xTLlpbcAhzfbkzoXxOwLYJpuNXx709X0CK9bK8N1zMRuu5k0Q7n0T/xjwluH2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3379 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 12:17:19 -0000 --_000_MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Making it a normative reference only means draft-ietf-babel-information-mod= el contains some text (i.e. the text about datastores) that can only be pro= perly understood by reading some of RFC 8342. Making RFC 8342 an informative reference would mean that there isn't any te= xt in draft-ietf-babel-information-model that needs RFC 8342 to properly un= derstand it, but that it contains information that may be interesting/helpf= ul to the reader. If you want RFC 8342 to only be an informative reference= (or potentially not be a reference at all), then I think that this documen= t would either need to not talk about datastores at all, or provide more de= scription about the concepts that it is ascribing to the 'enable' propertie= s in the information model. Thanks, Rob From: Mahesh Jethanandani Sent: 04 November 2020 18:24 To: Rob Wilton (rwilton) Cc: The IESG ; draft-ietf-babel-information-model@ietf.org; = babel-chairs@ietf.org; Babel at IETF ; Donald Eastlake Subject: Re: Robert Wilton's No Objection on draft-ietf-babel-information-m= odel-11: (with COMMENT) Hi Rob, On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker > wrote: Robert Wilton has entered the following ballot position for draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I support Ben's discuss regarding reusing the terminology from NMDA. I thi= nk that the document should have a normative reference to RFC 8342, and probab= ly explain that in some places the information model is using the same concept= s of configuration and operational data separation described in NMDA. While I am not against a reference to the terminology from NMDA in the info= rmation model, (BTW, I am ignorant on what it means for an informational dr= aft to have a normative reference), I am not sure whether it needs to norma= tive or whether it can be informative. By making it normative, are we makin= g this information model more YANG specific? Could the reference to NMDA be= normative in the YANG model of this information model (which the YANG mod= el already does)? Thanks. I also support Alvaro's question about whether the source-routing component should be included. This is just a comment, and I'm not proposing that you change tack, but I h= ave to confess that I question how beneficial publishing an Information Model really is. I understand that the goal here is to be able to publish two different data models, one based on YANG and other based on BBF's [TR-181]= . But what we end up with is an information model defined in a custom ad hoc language, which will naturally necessitate for the YANG and TR-181 models t= o be generated by hand, and for all three models to be kept up to date and consistent with each other. Hence, I wonder whether retrospectively it wou= ld have been better to just define the YANG model in IETF and ask BBF to use t= hat as source reference to construct the TR-181 model from, ideally as a programmatic conversion, or failing that by hand. At least that way there = are only two things to keep in sync rather than three. Regards, Rob Mahesh Jethanandani mjethanandani@gmail.com --_000_MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh= ,

&nbs= p;

Making it= a normative reference only means draft-ietf-babel-information-model contai= ns some text (i.e. the text about datastores) that can only be properly und= erstood by reading some of RFC 8342.

&nbs= p;

Making RF= C 8342 an informative reference would mean that there isn’t any text = in draft-ietf-babel-information-model that needs RFC 8342 to properly under= stand it, but that it contains information that may be interesting/helpful to the reader.  If you want RFC 8342 = to only be an informative reference (or potentially not be a reference at a= ll), then I think that this document would either need to not talk about da= tastores at all, or provide more description about the concepts that it is ascribing to the ‘enable’ proper= ties in the information model.

&nbs= p;

Thanks,

Rob<= /o:p>

&nbs= p;

&nbs= p;

From: Mahesh Jethanandani <mjethanandani@gmail.com>
Sent: 04 November 2020 18:24
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-babel-information-mod= el@ietf.org; babel-chairs@ietf.org; Babel at IETF <babel@ietf.org>; D= onald Eastlake <d3e3e3@gmail.com>
Subject: Re: Robert Wilton's No Objection on draft-ietf-babel-inform= ation-model-11: (with COMMENT)

 

Hi Rob,



On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatr= acker <noreply@ietf.org> wrot= e:

 

Robert Wilton has entered the following ballot posit= ion for
draft-ietf-babel-information-model-11: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/<= /a>



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this document.

I support Ben's discuss regarding reusing the terminology from NMDA.  = I think
that the document should have a normative reference to RFC 8342, and probab= ly
explain that in some places the information model is using the same concept= s of
configuration and operational data separation described in NMDA.=

 

While I am not against a reference to the terminolog= y from NMDA in the information model, (BTW, I am ignorant on what it means = for an informational draft to have a normative reference), I am not sure wh= ether it needs to normative or whether it can be informative. By making it normative, are we making this informat= ion model more YANG specific? Could the reference to NMDA be normative in t= he YANG model of this information model  (which the YANG model already= does)?

 

Thanks.




I also support Alvaro's question about whether the source-routing component=
should be included.

This is just a comment, and I'm not proposing that you change tack, but I h= ave
to confess that I question how beneficial publishing an Information Model really is.  I understand that the goal here is to be able to publish t= wo
different data models,  one based on YANG and other based on BBF's [TR= -181].   
But what we end up with is an information model defined in a custom ad hoc<= br> language, which will naturally necessitate for the YANG and TR-181 models t= o be
generated by hand, and for all three models to be kept up to date and
consistent with each other.  Hence, I wonder whether retrospectively i= t would
have been better to just define the YANG model in IETF and ask BBF to use t= hat
as source reference to construct the TR-181 model from, ideally as a
programmatic conversion, or failing that by hand.  At least that way t= here are
only two things to keep in sync rather than three.

Regards,
Rob


 

 

--_000_MN2PR11MB4366AAC6DB8686B0B58601ABB5EE0MN2PR11MB4366namp_-- From nobody Thu Nov 5 04:29:20 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150513A1858; Thu, 5 Nov 2020 04:29:15 -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, 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=toke.dk 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 erQIw-Hf0WUC; Thu, 5 Nov 2020 04:29:13 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 CFC9F3A1824; Thu, 5 Nov 2020 04:28:56 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604579333; bh=c2PVGo6dJZH1CJiZ/rek8czOsqANiXHn3zb8vYXl92k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ya1hZI5GqyVYDDCdMI7btMozuzfv1ZySsgzqzfVUYE8LTEQeIfixmFUToQx43yk1N 1ovVSgkBkQN6cbAIucD0dBUzmPUvPVuoT4LvctZh6ddHFweBLGlVyioDiZku5wJG44 GOlD3Hl0gpMtAIdu87AfKpYoAcWvr8pSCMz9xqExcWadYE4zn/x4CcyuNZTIaFIZmx rygWpbWTxjR2k4A0tJIT6FmkUypmNnTO0QcEmwZS03xWWQY3JZJnHMzG9Q17aTCo1h xR3Dk3Czq1QmvIv5diDo57fkyidyCZRLIF/S/Z/tQzuB9gIkE8KMZZFDpYfZD6v5k2 4jafwNRxZihfA== To: Alvaro Retana , The IESG Cc: draft-ietf-babel-source-specific@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: References: <160441631177.15161.14360810315064872038@ietfa.amsl.com> <87d00ujerf.fsf@toke.dk> Date: Thu, 05 Nov 2020 13:28:52 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h7q4t2bf.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 12:29:15 -0000 Alvaro Retana writes: > On November 3, 2020 at 4:45:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Toke: > > Hi! > > >> Alvaro Retana via Datatracker writes: >> > ... >> > Still, it shows how easy it is to define a policy that may not result >> > in the expected behavior because of the destination-first operation. >> > Please add some guidance on the advertisements and how they may >> > interact in the routing table. >> > >> > Note that what I'm asking for may just be a good example of what to do/ >> > not to do. rfc8678/=C2=A75 presents an example of how the forwarding t= able is >> > constructed based on a set of routes -- something like that would be >> > great! >> >> Since your concern seems to be related to a particular example of what >> the source-specific extension can be used for, mentioned in the >> introduction, I'm not sure I see how it would improve the document to >> write a whole bunch of text addressing this particular operational >> concern? I mean, the section you're quoting the example from (section 4) >> literally says that the choice of dest first / source first is arbitrary >> and all that is required is that it is consistent, before then going >> ahead and spelling out the choice. > > The choice may have been arbitrary, but =C2=A74 explicitly requires > destination-first: "A Babel implementation MUST choose routing table > entries by using the so-called destination-first ordering..." I read those two paragraphs in sequence as, basically, "(p1) the choice is arbitrary, (p2) so for this protocol we have chosen destination-first". As a reader and implementer this could have been done by coin toss for all I care :) > Note that I am not questioning the choice, I'm just asking for more > details. I do believe the choice was, in fact, not done by coin toss, but I'll let Juliusz chime in here as I'm not sure I'm able to explain it myself... >> One small change in the introduction that may make this clearer, was to >> amend this sentence in the third paragraph of the introduction: >> >> "When using >> this technique in a network connected to multiple providers, every >> host is assigned multiple addresses, one per provider." >> >> to read something like: >> >> "When using >> this technique in a network connected to multiple providers, every >> host is assigned multiple addresses, one per provider, and each edge >> router exports a default route with a source prefix corresponding to >> the prefix delegated from its upstream." > > That is not a bad change. =C2=A0However, my concern is not just about the > multihomed case, but about the general handling of advertisements into > the routing table. Ah, so what you're saying is that you want the draft to spell out *how* to achieve this (from s4): "a routing table entry R1 is preferred to a routing table entry R2 when either R1's destination prefix is more specific than R2's, or the destination prefixes are equal and R1's source prefix is more specific than R2's." IDK, that seems a bit like an implementation detail that should be left up to the implementer (RFC8678 is *long*, and the kind of document that really makes my eyes glaze over, so I guess this is a taste thing?). I'll let the draft authors answer what they think is appropriate here... >> > (b) How is the source address selected by the host? >> >> [...] >> >> > Even though this document is about Babel and not the host, I would >> > like to see a (short) discussion about how the host is expected to >> > behave (or what it needs to consider) in light of the >> > destination-first operation. >> >> Juliusz can correct me if I'm wrong here, but I believe this is left out >> because it really doesn't matter. The host can pick source addresses >> however it likes, and packets will make their way to the right upstream >> (in the multi-homing scenario). > > If it doesn't matter, I would like to understand why. > > The multihomed case with 2 default routes is straight forward -- but > how would it work in a more complex case (=C2=A74.4/rfc8678, for example) > where a specific source address is expected? =C2=A0Or is this use case not > supported? I see nothing about the topology in RFC8678/=C2=A74.4 that could not be implemented with Babel source-specific routing. SERb2 could just advertise '2001:db8:0:6666::/64 from 2001:db8:0:b000::/52', and the forwarding plane would do the right thing, in that only packets with the matching source and destination prefix would make it to the H61 host. A host on the local network would have to pick the right source prefix according to the policy, but whether it does that by trial and error or by some out of band discovery mechanism really doesn't matter as far as Babel is concerned, and I would consider this out of scope for this draft... -Toke From nobody Thu Nov 5 05:08:34 2020 Return-Path: X-Original-To: babel@ietf.org Delivered-To: babel@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C5F3A1075; Thu, 5 Nov 2020 05:08:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , d3e3e3@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160458171308.17244.3373983961712478100@ietfa.amsl.com> Date: Thu, 05 Nov 2020 05:08:33 -0800 Archived-At: Subject: [babel] Robert Wilton's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 13:08:33 -0000 Robert Wilton has entered the following ballot position for draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Please see the comment below for further description. My specific discuss issue relates to clarifying the indexes of the 'source' and 'route' tables to indicate whether they are replacing the 'prefix-len' elements of the existing 3 tuple indexes, or adding additional elements to the existing index, effectively making them 5 tuple indexes. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Caveat, I'm not familiar with the Babel routing protocol, and I might be getting the wrong end of the stick. In some ways I found the content and concepts of this document easy to understand, but the choice of particular terminology made is hard for me to know for sure that I am correctly interpreting this document. In particular, I am confused between the definition of "source", "destination prefix" and "source prefix" between this document and draft-ietf-babel-rfc6126bis. I might be completely confused, but my understanding is that what is called the "destination prefix" in this document, is effectively what is referred to as the "source" in draft-ietf-babel-rfc6126bis (e.g., in the Route Table in section 3.2.5), that also happens to be a prefix. Is that right? A further confusion is that this draft seems to sometimes describes prefixes differently from how they are described in the Babel RFC that it is extending. E.g., it seems that in some cases the prefix-length is implicitly part of the prefix, and in other cases it is described as a separate element (e.g., in the 'source' and 'route' table indexes). Specifically: 3.1. The Source Table Every Babel node maintains a source table, as described in [BABEL] Section 3.2.5. A source-specific Babel node extends this table with the following field: o The source prefix specifying the source address of packets to which this entry applies. The source table is now indexed by triples of the form (prefix, source prefix, router-id). According to 3.2.5 of draft-ietf-babel-rfc6126bis, the table is already index by a triple, i.e. prefix, prefix-len, router-id. Is the intention of this document to remove prefix-len as one of the keys to the index? I presume not, and that the new table is really indexed by a 5-tuple, i.e., adding source-prefix and source-prefix length to the existing keys. Note that the route entry contains a source (see sections 2 and 3.2.5 of [BABEL]) which itself contains a source prefix. These are two very different concepts that should not be confused. Should this reference be to 3.2.6? It may be helpful to expand on what the original "source" in a route entry means to avoid any confusion. If my understanding is right, then I think that this document would greatly benefit from being very clear on the differences in terminology and probably be very specific about what they mean in the context of this document. Regards, Rob From nobody Thu Nov 5 05:16:26 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570B03A10F7; Thu, 5 Nov 2020 05:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 ci3d8WmyNhvY; Thu, 5 Nov 2020 05:16:23 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 0AF0F3A10F6; Thu, 5 Nov 2020 05:16:22 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A5DFEBL013361; Thu, 5 Nov 2020 08:16:22 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 34kwv4xvbj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Nov 2020 08:16:21 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A5DGKfg030241; Thu, 5 Nov 2020 08:16:21 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [135.66.87.31]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A5DGG4n030162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Nov 2020 08:16:16 -0500 Received: from zlp27127.vci.att.com (zlp27127.vci.att.com [127.0.0.1]) by zlp27127.vci.att.com (Service) with ESMTP id B01C9400B574; Thu, 5 Nov 2020 13:16:16 +0000 (GMT) Received: from MISOUT7MSGEX2AA.ITServices.sbc.com (unknown [135.66.184.199]) by zlp27127.vci.att.com (Service) with ESMTPS id 97222400B573; Thu, 5 Nov 2020 13:16:16 +0000 (GMT) Received: from MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) by MISOUT7MSGEX2AA.ITServices.sbc.com (135.66.184.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 5 Nov 2020 08:16:16 -0500 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Thu, 5 Nov 2020 08:16:16 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.176) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Thu, 5 Nov 2020 08:16:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofK53MvC1AF16pFCdoxWJTujTMevJfVLHPgHaIuNrZFn8U1CWQloQ4KiDPE0+yc5uSkd2rNvwGaOrBFyrsKwClnT6ZB3n3tBu/AFLMr4zaJ2jN9CxX4ZPrlAVfcZrYhg0dofzTmulhd5GcECQo0seX82ImF1JCAc+iBdpTp88ny/v3OtGH5Cyq9PuiT2pdg3x84OYInSC3UfgSq9A/k0TQRAUVqj7LL+9HomWIWc6sueeT48370CXm4zV1c0E9NdxmRKDFRdOlot3OVzCCL9DW4nNyOqSA1718+klzQNeEk5sTQC2tvjFTqHLen0QgNkfVdmibZNt5EgLY+Tw2ZSOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9KRQe5yzrz2CLIad0WJ5cl6FzAryWeiGwSKebe2WTzk=; b=jsOmyJ+dt+V9Zcc42LwyWg/maXgb3Nj0NLvIGSje3sf+aKjMDAJ6jsqenXcgp+6/1aHX5BcXYI5ZM4o6uLZD174KVLMxXa1k91CBccQWq7vc1clZiBwchFGDbioZGDd/SfLtDkRtDdLqqk4c+IDHgLpOK1ckkKdPWc15y0IoDg03OoBvJtErCQ04krJhgFyfvZiEz5wDHpg9iqzYChM6Uq9F5S0qWSEEezSfTAKyBa7lABZXU3LAQypaCxN/G3ippcZP4amdzBZOevadfQnCZyjzeQlSkYzIiDfv4ARdD2Nb6zOgFLhnvlLdbOFu2nbUdNNsV5H8SoUFltNnVkipGA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9KRQe5yzrz2CLIad0WJ5cl6FzAryWeiGwSKebe2WTzk=; b=BrjNrDIqcQljWL6RMjFglu03Y8vIV3hWxsEgri14K9EE4n0iuqWXq0wGHCuko9EvtP1mT8Jp6rDslTKL+5NSuN0Wo6DHzPMahy2No21QhXDo+J3OeCDC/SCLIVaNRoNVY7oCzTol/Y7aWuOpesgDSo9mp6SzD3fbKQiiiC4Oi0A= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SA2PR02MB7595.namprd02.prod.outlook.com (2603:10b6:806:146::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 5 Nov 2020 13:16:15 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 13:16:15 +0000 From: "STARK, BARBARA H" To: "'Erik Kline'" , "'The IESG'" CC: "'babel-chairs@ietf.org'" , "'d3e3e3@gmail.com'" , "'babel@ietf.org'" , "'draft-ietf-babel-source-specific@ietf.org'" Thread-Topic: [babel] Erik Kline's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) Thread-Index: AQHWsyoGT7jLQ31Oq0iSLPfKxC1BGam5hRZA Date: Thu, 5 Nov 2020 13:16:15 +0000 Message-ID: References: <160454957752.16050.14365004360878554303@ietfa.amsl.com> In-Reply-To: <160454957752.16050.14365004360878554303@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13e0f502-4efa-4241-a6c9-08d8818cf96f x-ms-traffictypediagnostic: SA2PR02MB7595: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eNGgfK3gtTpP9hhvBUIx+BJQZ6KXEbGOiv2h8nbJ6p6pmTSKjAyxSNPAZbp+lxExcIud9V5rr7l8V+F+5LY7dhPDCun83kuNt+XDWtX1DTYWk/57MISLQngCnraPpNm4x8jn2LIF0nEBbgg5rxQJ4CUnPW5sAJFOrC3qp/GZ1PKnOQfuZBrevm3qbJLhjoLIFDy8MnKyNMXRek3QyuHKj81tVlcnzr+2Sy8OAsku8KNwfCOzwXkOsTSr1l2GqiQGNA4uK5n7UkhpuwMIIp7yWGjh2HMidMr8vkQC7qnoYZ/ZQ6Zimlk/fmtDuERkWtIA/+kFcMlQs3lEZNnzldFrBg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(376002)(346002)(396003)(66946007)(110136005)(4326008)(7696005)(26005)(558084003)(66476007)(71200400001)(64756008)(66446008)(478600001)(82202003)(66556008)(316002)(186003)(8936002)(9686003)(6506007)(54906003)(76116006)(8676002)(86362001)(52536014)(5660300002)(2906002)(55016002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: nHZYBoVEbBXfc49CWq2Zsg8TMCAZxi0uRx0Cg1B1TmM4fLTWxmrEqHhbRUZgT336KND5drPvRL11QiJMSvG0tLlKFHEzKdPW/LyxKAk1esUkklBXYBorZCXlkLDXzOrMNrJN12Z53lOa/rJHmj7d8OJYY49B9cxLpJoD9xuJJ1Dp4kJiGmzfT0qsD6AhLltWxn0pIochMjH/yCYWxBkpq+WUbz99UlmncqcHIPJ+ekkCytZuZWb00Uy1oDz0loLLA/jzroRVpfSEKXe5Y8k9vBp2SJj5hStFcMXUDP68x+bezQZRKprlazh2L4AHeK2bahr53uT5v/XHHjk/aZDP5Glx8KkIFamfvOLjEOIMytb3GccIKvvpJWiePBLBkcI3mjF4NDl3RAgaQUiNheXhrq4dEW0esddEV8lKh0+eBoRqwRdcRz0+kG+Ogn7K6tdS9ArmwJzfSTkAeuzlGyQ0l/zaIz4rvT0c4lPRWhXwSa/nQYF/ZuuxJnIXJBGENS+mGluR4rMk3EMcgKYrduc3q65fuV6TaPcGYjQiUSlDF1l7jMVIHtiXFL+Y86jOWKM92tnHcSlKgnMRk7RTNlk8tL2DW3RdlPfRL0z9ynTZbJ3jXXzhd6o7s50txZdfvHCzsEiVQX6fU2hW55p1uHGIKg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13e0f502-4efa-4241-a6c9-08d8818cf96f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 13:16:15.2444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bUstOXqLTwVFR6OEyK82j6rwSiSQVqI1vpD103ylTwVPqgoMi3WV+k9BJhl/Czr5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR02MB7595 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: B5B56F7F5319A98DBFCA1B692CB70DAD93CCB6A01E00E01A37002610E7FA82812 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-05_07:2020-11-05, 2020-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 bulkscore=0 mlxlogscore=620 clxscore=1011 mlxscore=0 phishscore=0 priorityscore=1501 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011050089 Archived-At: Subject: Re: [babel] Erik Kline's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 13:16:24 -0000 Hi Erik, > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > [[ nits ]] >=20 > [ section 4 ] >=20 > * Per RFC 5952 section 4.3, please s/2001:DB8/2001:db8/g Thanks. I'll do this. Barbara From nobody Thu Nov 5 05:28:21 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FBF3A10E4; Thu, 5 Nov 2020 05:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 ooiBX2rroFa2; Thu, 5 Nov 2020 05:28:18 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 02DE13A10E9; Thu, 5 Nov 2020 05:28:17 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A5DPZ79033574; Thu, 5 Nov 2020 08:28:17 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 34kgk001de-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Nov 2020 08:28:16 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A5DRa2c008460; Thu, 5 Nov 2020 08:27:36 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A5DRVVr008376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Nov 2020 08:27:31 -0500 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 38C17400B57F; Thu, 5 Nov 2020 13:27:31 +0000 (GMT) Received: from GAALPA1MSGEX1CC.ITServices.sbc.com (unknown [135.50.89.110]) by zlp30485.vci.att.com (Service) with ESMTPS id 109D6400B57C; Thu, 5 Nov 2020 13:27:31 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) by GAALPA1MSGEX1CC.ITServices.sbc.com (135.50.89.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Thu, 5 Nov 2020 08:27:18 -0500 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Thu, 5 Nov 2020 08:27:18 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (104.47.46.52) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Thu, 5 Nov 2020 08:27:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZyIJqgG/FbtKvas+uh9+KNYnEgl1Qp4zVLOSukXyTJeKc1tZ+MMbLdvnqZEegrj2M6vPyHK7P4spwVj9i4K2YTE3tF8M0GTt9MQKizX+D8sM2DYvTKuvzNd8PeN8Fnpu5/jR6lS64j3B6PrO+GqvrPSmII9Tx+rf4PUQi6w79RBqLH8oVE2nr/IrcMJJ++AwC9cXbWaFhLH8V+BEWtenYbNEVBXFnk/SA7LV2RVDpS8On4dXEifgzjpm7jWc5kk0+Uuu9rXWUnawjVL3YFqx91TcIQ+W2LPXn7dakhwnt9Oqr13rVd2Z1uTjslpPIRpVvW34RdPxP0YieAvcDNfcDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ay1MvU+z82S8Jnvv/+8HWa2VNKJZYmk4fBmI/3xvoEM=; b=cAlPFYvtIDiqPVdigUex8IAqpqjKFAFASPwWKJJSJFOoZ+sCdH9h0FIDw3bgBBJcNX9eO30tR/7kGIGQ9ei42DEyuibYBBow882NYY8O451HRD7ETX65XrGfxIkj5xK32yO/Xh+qaVw1/tT4LDqmGVcA3+mk/m5rEi8XzTgnvgtcjUgXqjQyw1WqnpOQSiYl30S4HPvLul90w+Pg4RJhZG3T28U0JfqHdbsyzRiLPmwCkJC6giGQ3MCesXYN3DL8kNLeE2c7veMw/MCpzJyQukjFAzt0jrvm7iL66PvUoQSar7puzl3ii/hvivktCNsvjwbtmhZ8AfB1TiA6y764FQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ay1MvU+z82S8Jnvv/+8HWa2VNKJZYmk4fBmI/3xvoEM=; b=fEZHPoMzUIUGkM+yejjQYmyUWIJ1BgOKKa67otFIsQy8JCGZOAGYG7r/DQ9Uxd9eGb8xjFzjWD2dUHIpsd1X5gzENFowaAN7C/HY3grguBFr/MGbNNDgcRztCi+sK7sjzPZxZc/96CWWyahkPcOs/2bydM6PlYgzihMRrTG4z5A= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB5600.namprd02.prod.outlook.com (2603:10b6:805:eb::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 5 Nov 2020 13:27:09 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 13:27:09 +0000 From: "STARK, BARBARA H" To: "'Murray Kucherawy'" , "'The IESG'" CC: "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'Donald Eastlake'" Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWszwxgiaB3Txl0EuKFovNkgDhWKm5h5Hw Date: Thu, 5 Nov 2020 13:27:09 +0000 Message-ID: References: <160455738479.29698.10710227486204000135@ietfa.amsl.com> In-Reply-To: <160455738479.29698.10710227486204000135@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ddd74048-b04f-4113-bd5f-08d8818e7f78 x-ms-traffictypediagnostic: SN6PR02MB5600: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6wulVOxUgNn4peysSaZU8aePgqVa3Jr/GufkWjXNDSZR3mbAIf/QT7ixMAjJ5AZsvBwib25E6BS/iUdqe+mD9Y+OeqzZazgPqEU3kC67PR6+3EDkbsPiJegqTM4kBer9rAABUT+AvZy4GlPKyvSpZintWglGZpPlx1oo+da7fw+ttFerp9Sc+IDcVR/5DO4Nzdbmx1geTQ5+560L9RLWlK65un3xnb8FQhGLktQZvDTmLUraeaGzN549GjD/fE8ByQiOZQ5N4NAG3T1y2vCoKUJ/qvwoR72Xn5+16kuN+zWx7kb6nyBOdcH1fOK8+/rRVUCh9MgRqkIKrgcuuKK9/A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(346002)(376002)(396003)(136003)(4744005)(316002)(66446008)(66476007)(66556008)(64756008)(71200400001)(66946007)(76116006)(478600001)(8936002)(82202003)(54906003)(110136005)(4326008)(86362001)(8676002)(2906002)(52536014)(5660300002)(55016002)(186003)(7696005)(6506007)(33656002)(26005)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7V3Dp7bK78LbCSI/04qIVlUfeYMzpCDn5tR5KoX45ilBubF9cSVEI5vg03H+oNAyacpxXdMU5KukmLAmK6WtAfHAxEHSgx8HyI7ZbP0XnXXPv0XM3sfFsKGETqm6LFmIHX9SOVJTzT2edJAyrKjpyWzxGK++t34AiBp3EtHjtZv/oUSvDwKlozEKqgfWmDkMtJRMHR1nTub6sRXm0pLroyWDdBvMri11zIjxjuOnXg5+2Dun3ZgWDi1AbgA1p9yfNoUs6zOeqqtaJS2BX8M6l3BhU2sSnP4aziq0u+IFsw5BBh8hGR0BfqZk+H984ys9K/OOP//e4DbVrEgXsXL5BywYKRzJsqFf4SOqrA9qs0dJqTFNp/jWdhjDyzZhhxsQadvcl/P8w4ho+TbUZCanOGd6jbu3+Y2ca+57HmYiE72uDIBoFEh9WqSSPEdsdgnCnslnbaYo/VwwBCJKoEbs/jj7s5Bz70M0ZE81Z0cr6ZNY8BBZzFw4ar3CJkYF6FoDXEJgOs/Rfx0oWik1GGWHo2j2lAPzFt98Gux/a/F3fkFRJ2XE1LukKLRGVExkh5rsXNpwaJJS/x/vC9ZLofTnc0bZ2aiEIlVTXuGqoEuAz52Cv2L2pWAso4RTK6C7EHJL1ExnQL1tpSmPrRe16zc/rg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ddd74048-b04f-4113-bd5f-08d8818e7f78 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 13:27:09.6153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YZn9QApNJgkFmYRPNm+ouYYdkaWrDAlEnP2YHyCJ7gp8++jqDjmcQUvBXyc//HdO X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB5600 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: E2AF00B66A0E0026E36CA4C5655F97C1AF73B577A2867AE4A77A79BB10F5FF5A2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-05_07:2020-11-05, 2020-11-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 clxscore=1011 priorityscore=1501 suspectscore=0 phishscore=0 mlxlogscore=767 spamscore=0 adultscore=0 mlxscore=0 malwarescore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011050091 Archived-At: Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 13:28:20 -0000 SGkgTXVycmF5LA0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPiANCj4gVGhlIHNoZXBoZXJkIHdyaXRldXAgaXMgbW9yZSB0aGFuIGEgeWVhciBvbGQuICBJ IHdvbmRlciBpZiB3ZSBzaG91bGQgZ2V0IGludG8NCj4gdGhlIGhhYml0IG9mIGFza2luZyB0aGF0 IHRoZXNlIGJlIHJlZnJlc2hlZCBiZWZvcmUgdGhleSdyZSBzY2hlZHVsZWQgb24NCj4gdGVsZWNo YXRzLg0KPiANCj4gUGxlYXNlIGZpeCB0aGUgYm9pbGVycGxhdGUgdGV4dCBmcm9tIEJDUCAxNCAo eW91ciBTZWN0aW9uIDEuMSkuDQo+IA0KPiBMYXN0bHksICsxIHRvIEJhcnJ5J3MgY29tbWVudHMu DQoNClRoYW5rcy4gWWVzLCBJJ3ZlIGFscmVhZHkgYWdyZWVkIHRvIGFsbCBCYXJyeSdzIGNvbW1l bnRzICh3aGljaCBpbmNsdWRlZCB0aGUgQkNQIDE0IGZpeCkuDQpXaWxsIGRvLg0KQmFyYmFyYQ0K From nobody Thu Nov 5 05:39:13 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50D93A17F5; Thu, 5 Nov 2020 05:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 et0YuET72KhW; Thu, 5 Nov 2020 05:39:03 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 1224A3A17E2; Thu, 5 Nov 2020 05:38:59 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A5DcvYM002210; Thu, 5 Nov 2020 14:38:57 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 280B0AAA6B; Thu, 5 Nov 2020 14:38:57 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id bYPLoZX2kalz; Thu, 5 Nov 2020 14:38:54 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0F419AAA66; Thu, 5 Nov 2020 14:38:54 +0100 (CET) Date: Thu, 05 Nov 2020 14:38:50 +0100 Message-ID: <87h7q3app1.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: Alvaro Retana , The IESG , draft-ietf-babel-source-specific@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <87h7q4t2bf.fsf@toke.dk> References: <160441631177.15161.14360810315064872038@ietfa.amsl.com> <87d00ujerf.fsf@toke.dk> <87h7q4t2bf.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 05 Nov 2020 14:38:57 +0100 (CET) X-Miltered: at korolev with ID 5FA40071.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA40071.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA40071.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 13:39:11 -0000 > I do believe the choice was, in fact, not done by coin toss, but I'll > let Juliusz chime in here as I'm not sure I'm able to explain it myself... Please see the penultimate paragraph of Section IV.C of [SS-ROUTING]. The final authors' draft (essentially identical to the published version) is available online at http://arxiv.org/pdf/1403.0445 -- Juliusz From nobody Thu Nov 5 06:21:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE083A1220; Thu, 5 Nov 2020 06:21:05 -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, 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=toke.dk 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 bQTJWRj9pRgK; Thu, 5 Nov 2020 06:21:02 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 1E0873A1209; Thu, 5 Nov 2020 06:21:00 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604586055; bh=MicRXwM05HlvSDjpRZ5r53cfeIqaNizeFyPMxDuWx3I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bOYakzrK2ARjPRIyIkIUGyZbE1+xPIAyLQ07jUHQ6JJ5ZRf10e8fQ17kt1ip1ptDv Jbl77t2BSpYLq26OQMyECWbml2RlvgXJVcLnW5VaFl05Uk1q+/qTlp0f+eRd3N5nYq Dt6wCZYSesnbMmaYlHTKdlTgKkhI+orU0oVQB/XXlE1q7Gl1M7rnkqiyKgnUs8Ic5x WPm74AdLqcBjbjRwChxjwuyfqCuDvMCKNuV7nXJ1ix1k31qHchnotT7B/XLnangzMc MQyq4nixQ5lr5Bu1B5NhOPAxO0itcz32QS9dFt44zbMkCUGVwWYS4dfRB8VxI5IyO5 GA+rnWBGgVZDw== To: Juliusz Chroboczek Cc: Alvaro Retana , The IESG , draft-ietf-babel-source-specific@ietf.org, Donald Eastlake , babel-chairs@ietf.org, babel@ietf.org In-Reply-To: <87h7q3app1.wl-jch@irif.fr> References: <160441631177.15161.14360810315064872038@ietfa.amsl.com> <87d00ujerf.fsf@toke.dk> <87h7q4t2bf.fsf@toke.dk> <87h7q3app1.wl-jch@irif.fr> Date: Thu, 05 Nov 2020 15:20:53 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87zh3vsx4q.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 14:21:06 -0000 Juliusz Chroboczek writes: >> I do believe the choice was, in fact, not done by coin toss, but I'll >> let Juliusz chime in here as I'm not sure I'm able to explain it myself... > > Please see the penultimate paragraph of Section IV.C of [SS-ROUTING]. The > final authors' draft (essentially identical to the published version) is > available online at http://arxiv.org/pdf/1403.0445 Ah, right, obviously source-specific default routes won't work unless destination-first ordering is used... Thanks for the pointer, should have just realised that myself. -Toke From nobody Thu Nov 5 07:03:34 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3453A12AD; Thu, 5 Nov 2020 07:03:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ORJ_BZjzOh5n; Thu, 5 Nov 2020 07:03:31 -0800 (PST) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 CCA093A12C9; Thu, 5 Nov 2020 07:03:04 -0800 (PST) Received: by mail-vs1-xe33.google.com with SMTP id r14so917877vsa.13; Thu, 05 Nov 2020 07:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bxq9Ps9Ze1Z9Im1TPnMsbGRkHh2niwHg4kCWmd1TM5o=; b=JeSjEEAArxAtjF/QZVaG9fIWJ1VxwDbm2BR0ivAR34G2dBbgfrUCdDM1wElgO9e3f7 HG7cO+neh3zZUZH/UKC3D9+pw7eVTxlANviyRtwGez4U+H9cFsnr54fvXVjfWg46PWRq 80CrPfrbefEbD+rtFtoZHWQ5OhXlObp+aiOhU7BAf1TpM0GUsquWU/uc6k9Z3KVsars2 grDqbZoqdDFdJ2gZgJkcr+zSXrwdottz+hfOkeYsj+Z/d8noJcieYpmbZiRUGCqgSu3c LfM6Uxdhxd87Nv1blenpMFmQDRQ6NRMJQQfReQ/yO8eZxlF4pPydQ9tlqamkk1gRGYcq W0qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Bxq9Ps9Ze1Z9Im1TPnMsbGRkHh2niwHg4kCWmd1TM5o=; b=Fzw/qUqcELlOGiIkNLpZ0xwePL44AByXYl7ZX8xp+4Bs5ISOs9kAeJLvihvyHlCu7S yC6olMG7EwiGcyohwh7F0WkUB84QD73M0n9VUfrELDEsLnA2m369i/ZSXPQDOYMWSYzn vehxrggFFqKz4aSTW9aDhMLOQhqxL5Ztoj7lcHFMK1Pbyx2RfZGvW8ycvkX0woBD34Gb JnBNmyxV78ljbDHcw0eInhW4vErevtiD2ZI4pN3spjw0VpMO0ndauWJndVBVbD1gbl5W KGwQdNXJhdK/QlhVsozeDL1ezrLes4sCAO6Dr11yQpMuxmUOnEV1hoPjIf/I6Sz13usA CYlw== X-Gm-Message-State: AOAM532EuLVfbUrQceIsdMcDC7vXFu8cWvsv6Ul9u6KlrwjGs6ua4ixi x5d817UQUhSi7LlAwQ4+JB/GTPUKklop5GR0k0mbEMqHZRU= X-Google-Smtp-Source: ABdhPJyDgQ6ggckD/v+nR+fJ62Aqedyo0rCaVu5xHdq5A0FscbD0xoHvOQgWdnYHCvB2cnvdjqG6lM+n6h/Qno9D2AY= X-Received: by 2002:a67:c914:: with SMTP id w20mr1578118vsk.15.1604588583714; Thu, 05 Nov 2020 07:03:03 -0800 (PST) MIME-Version: 1.0 References: <160455279459.19842.7370627868131264527@ietfa.amsl.com> <87pn4st4gc.fsf@toke.dk> In-Reply-To: <87pn4st4gc.fsf@toke.dk> From: "Murray S. Kucherawy" Date: Thu, 5 Nov 2020 07:02:51 -0800 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: The IESG , babel-chairs , Donald Eastlake , Babel at IETF , draft-ietf-babel-source-specific@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b049c05b35d6471" Archived-At: Subject: Re: [babel] Murray Kucherawy's No Objection on draft-ietf-babel-source-specific-07: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 15:03:33 -0000 --0000000000008b049c05b35d6471 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for that. You might include a sentence or two suggesting this is why that's a SHOULD and not a MUST. On Thu, Nov 5, 2020 at 3:42 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Murray Kucherawy via Datatracker writes: > > > Murray Kucherawy has entered the following ballot position for > > draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > What's an example of when one might deviate from the SHOULD in Section > > 4? > > Only thing I can think of is that if someone already implemented a > disambiguation like that suggested in the second bullet, and the > underlying platform then adds native support, one could conceivably > continue using the disambiguation instead of switching to the native > support. > > The Linux kernel is an example of this: in ancient times there was no > native support for source-specific routing, but it was possible to use > the generic policy routing mechanism to achieve this. When the native > support was added, it came with a new UAPI, so a routing daemon would > have to change to support it, while the old policy-based way would still > work. Or maybe an implementation wants to support ancient kernels with > the same code and keeps using the policy-routing based way; it would > likely be somewhat painful, but in principle I suppose it could work. > > -Toke > --0000000000008b049c05b35d6471 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for that.=C2=A0 You might include a sentence or two= suggesting this is why that's a SHOULD and not a MUST.

On Thu, Nov = 5, 2020 at 3:42 AM Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> wrote:
Murray Kucherawy via Datatracker <noreply@ietf.org> writes:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-babel-source-specific-07: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/= doc/draft-ietf-babel-source-specific/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> What's an example of when one might deviate from the SHOULD in Sec= tion
> 4?

Only thing I can think of is that if someone already implemented a
disambiguation like that suggested in the second bullet, and the
underlying platform then adds native support, one could conceivably
continue using the disambiguation instead of switching to the native
support.

The Linux kernel is an example of this: in ancient times there was no
native support for source-specific routing, but it was possible to use
the generic policy routing mechanism to achieve this. When the native
support was added, it came with a new UAPI, so a routing daemon would
have to change to support it, while the old policy-based way would still work. Or maybe an implementation wants to support ancient kernels with
the same code and keeps using the policy-routing based way; it would
likely be somewhat painful, but in principle I suppose it could work.

-Toke
--0000000000008b049c05b35d6471-- From nobody Thu Nov 5 07:45:44 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CDC3A1355; Thu, 5 Nov 2020 07:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 RTzlrxvFcsRF; Thu, 5 Nov 2020 07:45:41 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 26D0F3A134D; Thu, 5 Nov 2020 07:45:13 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A5Fj2ko032475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Nov 2020 16:45:02 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 0A5Fj23S009477; Thu, 5 Nov 2020 16:45:02 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 87472C0CD6; Thu, 5 Nov 2020 16:45:02 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id oTYcX_-g_Ryn; Thu, 5 Nov 2020 16:45:00 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 43F6CC0CD3; Thu, 5 Nov 2020 16:44:59 +0100 (CET) Date: Thu, 05 Nov 2020 16:44:55 +0100 Message-ID: <878sbfajuw.wl-jch@irif.fr> From: Juliusz Chroboczek To: =?ISO-8859-1?Q?=C9ric?= Vyncke Cc: "The IESG" , draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake , david@opensourcerouting.org, as@cisco.com In-Reply-To: <160456253967.7318.72519100069215705@ietfa.amsl.com> References: <160456253967.7318.72519100069215705@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 05 Nov 2020 16:45:02 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 05 Nov 2020 16:45:02 +0100 (CET) X-Miltered: at korolev with ID 5FA41DFE.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FA41DFE.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA41DFE.003 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FA41DFE.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA41DFE.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FA41DFE.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] =?iso-8859-1?q?=C9ric_Vyncke=27s_Discuss_on_draft-ietf-b?= =?iso-8859-1?q?abel-source-specific-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 15:45:44 -0000 > == COMMENTS == > Generic comment: did the author read draft-ietf-rtgwg-dst-src-routing ? It is > an expired RTG WG adopted document and is not even cited as informative > reference. This draft was cited as [DSR] in previous versions (up to and including -05). Just before submission to the IESG, I was asked by the Responsible AD to not depend on an expired draft. In -06 I rewrote the Security Considerations section to not depend on [DSR] and removed the citation, as requested. Please let me know what to do. -- Juliusz Chroboczek From nobody Thu Nov 5 08:11:30 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4675F3A17E0; Thu, 5 Nov 2020 08:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g7oGDtTm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Dhpw89CQ 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 NHVHHsdTpxTu; Thu, 5 Nov 2020 08:11:25 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180D83A144A; Thu, 5 Nov 2020 08:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2000; q=dns/txt; s=iport; t=1604592685; x=1605802285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4QE3mCTQcSqUDCT6et9RxWU2nmcC132PfCKCxtJnD9k=; b=g7oGDtTmlHuSnyk4fXET8JMEMdV1eHcIhztjhuKeWQj67cRm4jdLJc45 JdqUxya4FVzsSnKjDtqvsGcMEnieZpTkA//eMDNPn6Tf1Zm2WQRhrhleP ECWmMZzH/j/8xuwnDRAK6pyXwwPklK+cAft07ShlMPPsE3KdUgB44lj8v Q=; IronPort-PHdr: =?us-ascii?q?9a23=3ACaN54hZZ0nrRm+kP1lERu1X/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4TB6vwChfCF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGdz/aRvcuC764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxCAAdI6Rf/4gNJK1iHgEBCxIMQIF?= =?us-ascii?q?EC4FSUQeBSS8uhD2DSQONU4oTjmyBQoERA1QLAQEBDQEBLQIEAQGESgIXgXc?= =?us-ascii?q?CJTcGDgIDAQELAQEFAQEBAgEGBHGFYQyFcgEBAQMBEhERDAEBNwELBAIBCA4?= =?us-ascii?q?DAwECAwImAgICHxEVBQMIAgQOBSKDBIJMAw4gAaVEAoE7iGh2gTKDBAEBBYU?= =?us-ascii?q?LDQuCEAmBDiqCcoNxgimELhuBQT+BESccgk8+ghuCCRqDFzOCLIkZhxeCdgE?= =?us-ascii?q?9ikKIZJBHVAqCbZV2hRMDH4MYihKFTI53hF2cVpJeAgQCBAUCDgEBBYFqJIF?= =?us-ascii?q?XcBVlAYI+UBcCDY4fDBcUgzqKWHQ4AgYBCQEBAwkBe4xtXwEB?= X-IronPort-AV: E=Sophos;i="5.77,453,1596499200"; d="scan'208";a="617949765" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Nov 2020 16:11:24 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A5GBOvD003869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 5 Nov 2020 16:11:24 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 10:11:23 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 5 Nov 2020 10:11:23 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 5 Nov 2020 11:11:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lKitZih5KlsyUAjgmKu1RhknTGXVpevY7kFKgax8tyiXUm2OBUZ2sx80grdAC45UvrM4lDH6DX8eh9a16MUSbu1P1amic4xYuOTvxCcMX1bIEW8SobwyMdL4OtkmF8w4qJCeAtogW7s0FcQBt37kH+ogxSU3+Qsv04hj0JYlVmct1ANiBn9+74lgHOYFcz3PnmNv7uy+A3hzNJd28zqAQszfLJbN4Rkw5y+B7TmykONUQCVDf9SZUYmc5NOjBb8HqvM3wQnKsimDJWnx6sf2jVx8SwBm6V0+8/PDX7ahKrJjXhJGRuBqi+KgNT+/iHWV4gnKpzB4ZVdjK+qQr3zEEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4QE3mCTQcSqUDCT6et9RxWU2nmcC132PfCKCxtJnD9k=; b=O4eJjPwX9sW5fV468sJX3mRbQP4vNFHzgfXeY082FrcU6Sc9U6pnxs0vM5voxp8STJWouAPuaZiI1cJhaDBVE1cRhdJwJzyGS79S9Upi2gFApXMU2i5KAfZGzrPizGj3WWucWZFbgZC1LpRg4OsA1Q2SFHX2lfYOiTM0dXSNPaFQLVlFIrCDYhQophAb2qK+1zdMmKCoJgMlta79q8bMH38jp2wYJjCcjCuMbPljCWG/m6z0IW/BKZD+4n/hAdGs5SsOsRcmp+MQUK+lAcbAN+FtfzIOpPblSqnJfM+XEIJBDyjThgtSydgiuGQjn89x9PJ4BPmE237S1M/C646hrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4QE3mCTQcSqUDCT6et9RxWU2nmcC132PfCKCxtJnD9k=; b=Dhpw89CQAQW08X+qDiel+9wOtY5DhT9dUepsobt+5B+muRIMrh7jDsBgHUzzT5ZB4wAlFnrXVNv6YiAXp+vTIoN5HIVX8rZQy7B92KVioECOxoaQltymRUOeDQwfHPPw5AVejK7LTBTxpLbvKxNP3Pzxd+ejY6lpXz9/0yNlqc8= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4822.namprd11.prod.outlook.com (2603:10b6:510:39::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Thu, 5 Nov 2020 16:11:22 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3499.032; Thu, 5 Nov 2020 16:11:22 +0000 From: "Eric Vyncke (evyncke)" To: Juliusz Chroboczek CC: The IESG , "draft-ietf-babel-source-specific@ietf.org" , "babel-chairs@ietf.org" , "babel@ietf.org" , Donald Eastlake , "david@opensourcerouting.org" , "as@cisco.com" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWJhYmVsLXNv?= =?utf-8?Q?urce-specific-07:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHWs4qt+8RZO8/JukiHAZfPWbkb2Km5xkeA Date: Thu, 5 Nov 2020 16:11:22 +0000 Message-ID: References: <160456253967.7318.72519100069215705@ietfa.amsl.com> <878sbfajuw.wl-jch@irif.fr> In-Reply-To: <878sbfajuw.wl-jch@irif.fr> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: irif.fr; dkim=none (message not signed) header.d=none;irif.fr; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:2594:64b2:2d96:735] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d551816-49ba-45a3-2c06-08d881a57016 x-ms-traffictypediagnostic: PH0PR11MB4822: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: O4/mHfR5JhRPteAPnexaX9FUoP6kvYeS2SsNZcSnPVUBipE/W4apiDTGwMnLqpv8mKg0dShR7fnlQB2TBDk16cOWJF15shW7G70PO9TCbuvJEwkxnlw74JQZqJ6WpAkYzeb9EgbJogooSBUT86SK3+qUXj5o5WajgKrgHFzg3oIAceq9ffp2Fpcmje2NdcMGenGMQUYNWGJSHvt8b5P5S86Whmdw9b06dmLCCw1qFq/Opnprv7hYO5TBj9JtGcQNuzmfNMCPkRI++5GVJSU2/exijNKbhgjZOmJl94v4kGMhxXIlMOHLnVe7Ukn7vtTBkz7QHlev54pp4t44mBPjFw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(366004)(376002)(346002)(39860400002)(54906003)(6486002)(66476007)(66446008)(64756008)(66556008)(76116006)(66946007)(5660300002)(91956017)(71200400001)(107886003)(33656002)(6916009)(224303003)(8936002)(36756003)(316002)(186003)(478600001)(2906002)(53546011)(6512007)(2616005)(83380400001)(4326008)(6506007)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Zojo0TYOdDREV7+x7J8hsR7663KMkp6e3Ah4tJMR5aKsVnDZYStzZD2zY7NaocFRPUEoKzhRrw6qZKsElX2cAyQWJA3/Y+H2HHkZTVWQJa1ljiMTK3Cvasks3f0CuVazNba5qnmrPDjTa8KDJbaE9E88nIJ70jW+OvRpr0yZ4TLPs6M+D6Y9noUh67dRv39p+bn+OFHC1t22t+sDM47jv6zxmTWRYDVtVFjk6gQ+sUH/Rg+Tg567sr8LJLSGg7qOvVcktKoc1kiT9qZQdTPVRWDJfpwcgSLkaE0zixbhy5Jrh+IF4xrjgH7bO7WYjqhLVnZXMFdm9+KRoTJed4sdq7QP4ijYYL+8PP3OTHuvuvBtQf63pHpMHgAd6X14dAbbwp4iUobJKp43gSg0kl+6uU7ODQFwcGxpuApKDwjVz/m9UZbnXx7iDh0ldMAGxkjleU8LGnmJwANpcca71mJYoDARsFW1A4r7n5PU0cZsQFHvkxZrK5rGYxSyYWLuQBh6SlJY1STT3Vh05MHTJ5UaIO/pNeya0+p6oyL4aoZ8PXSxr23mLWZC2ZPa59arcZ1uhbJgXUEOZMfC+ynSk40XgWnKhwTcfOV9mdFa9geLJqNsdEXDhxtmkQyNNDkPe5KlIKhoyv2A0ERedlbiODQI9QNosC14CPiV4xbUV9N3VK7+/OriB5w18jfL1PxZg7KUfnBnR5SqdPgBPCy5u19NPw== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d551816-49ba-45a3-2c06-08d881a57016 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2020 16:11:22.1898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: A6yOECbBMAPM6UAiJkmorhMmmw9r/aXHr8Z5oiSid7/qeVWgVpzFt3piAFbByLJ3Za2ZRY2+ZLxqbxOyqG/hbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4822 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [babel] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-bab?= =?utf-8?q?el-source-specific-07=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:11:29 -0000 SnVsaXVzeiwNCg0KRmlyc3QsIEkgaG9wZSB0aGF0IHlvdSBoYXZlIG5vdGljZWQgdGhhdCBteSBE SVNDVVNTIHdhcyBhIGN1dCAmIHBhc3RlIGVycm9yIGFuZCBpdCBoYXMgYmVlbiByZW1vdmVkIG9m IGNvdXJzZS4NCg0KQWJvdXQgdGhlIHJlZmVyZW5jZSwgaWYgdGhpcyBpcyBhIGNvbnNjaW91cyBk ZWNpc2lvbiBieSB0aGUgYXV0aG9ycyBhbmQgTWFydGluLCB0aGVuIEkgYW0gYWxsIHNldCBhbmQg ZmVlbCBmcmVlIHRvIGlnbm9yZSBteSBDT01NRU5ULg0KDQotw6lyaWMNCg0K77u/LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEp1bGl1c3ogQ2hyb2JvY3playA8amNoQGlyaWYuZnI+ DQpEYXRlOiBUaHVyc2RheSwgNSBOb3ZlbWJlciAyMDIwIGF0IDE2OjQ1DQpUbzogRXJpYyBWeW5j a2UgPGV2eW5ja2VAY2lzY28uY29tPg0KQ2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiwgImRy YWZ0LWlldGYtYmFiZWwtc291cmNlLXNwZWNpZmljQGlldGYub3JnIiA8ZHJhZnQtaWV0Zi1iYWJl bC1zb3VyY2Utc3BlY2lmaWNAaWV0Zi5vcmc+LCAiYmFiZWwtY2hhaXJzQGlldGYub3JnIiA8YmFi ZWwtY2hhaXJzQGlldGYub3JnPiwgImJhYmVsQGlldGYub3JnIiA8YmFiZWxAaWV0Zi5vcmc+LCBE b25hbGQgRWFzdGxha2UgPGQzZTNlM0BnbWFpbC5jb20+LCAiZGF2aWRAb3BlbnNvdXJjZXJvdXRp bmcub3JnIiA8ZGF2aWRAb3BlbnNvdXJjZXJvdXRpbmcub3JnPiwgImFzQGNpc2NvLmNvbSIgPGFz QGNpc2NvLmNvbT4NClN1YmplY3Q6IFJlOiDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtYmFiZWwtc291cmNlLXNwZWNpZmljLTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U KQ0KDQogICAgPiA9PSBDT01NRU5UUyA9PQ0KDQogICAgPiBHZW5lcmljIGNvbW1lbnQ6IGRpZCB0 aGUgYXV0aG9yIHJlYWQgZHJhZnQtaWV0Zi1ydGd3Zy1kc3Qtc3JjLXJvdXRpbmcgPyBJdCBpcw0K ICAgID4gYW4gZXhwaXJlZCBSVEcgV0cgYWRvcHRlZCBkb2N1bWVudCBhbmQgaXMgbm90IGV2ZW4g Y2l0ZWQgYXMgaW5mb3JtYXRpdmUNCiAgICA+IHJlZmVyZW5jZS4NCg0KICAgIFRoaXMgZHJhZnQg d2FzIGNpdGVkIGFzIFtEU1JdIGluIHByZXZpb3VzIHZlcnNpb25zICh1cCB0byBhbmQgaW5jbHVk aW5nIC0wNSkuDQoNCiAgICBKdXN0IGJlZm9yZSBzdWJtaXNzaW9uIHRvIHRoZSBJRVNHLCBJIHdh cyBhc2tlZCBieSB0aGUgUmVzcG9uc2libGUgQUQgdG8NCiAgICBub3QgZGVwZW5kIG9uIGFuIGV4 cGlyZWQgZHJhZnQuICBJbiAtMDYgSSByZXdyb3RlIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u cw0KICAgIHNlY3Rpb24gdG8gbm90IGRlcGVuZCBvbiBbRFNSXSBhbmQgcmVtb3ZlZCB0aGUgY2l0 YXRpb24sIGFzIHJlcXVlc3RlZC4NCg0KICAgIFBsZWFzZSBsZXQgbWUga25vdyB3aGF0IHRvIGRv Lg0KDQogICAgLS0gSnVsaXVzeiBDaHJvYm9jemVrDQoNCg== From nobody Thu Nov 5 08:26:11 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83C3A17F1; Thu, 5 Nov 2020 08:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 eIiXLQFIr56g; Thu, 5 Nov 2020 08:26:03 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 6AAC33A1349; Thu, 5 Nov 2020 08:26:01 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A5GPxDe030582; Thu, 5 Nov 2020 17:25:59 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 630BBC2D78; Thu, 5 Nov 2020 17:25:59 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ESF77J-IvVey; Thu, 5 Nov 2020 17:25:57 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 32B3CC2D70; Thu, 5 Nov 2020 17:25:57 +0100 (CET) Date: Thu, 05 Nov 2020 17:25:53 +0100 Message-ID: <875z6jahym.wl-jch@irif.fr> From: Juliusz Chroboczek To: Martin Duke Cc: "The IESG" , draft-ietf-babel-source-specific@ietf.org, babel-chairs@ietf.org, babel@ietf.org, Donald Eastlake In-Reply-To: <160453946202.22882.3587018410396865705@ietfa.amsl.com> References: <160453946202.22882.3587018410396865705@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 05 Nov 2020 17:25:59 +0100 (CET) X-Miltered: at korolev with ID 5FA42797.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA42797.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA42797.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Martin Duke's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:26:10 -0000 I've done some minor reordering to your comments. Hopefully this doesn't change their meaning. > I am concerned about the congestion implications of this architecture. If there > are P prefixes in the network, the number of TLVs exchanged potentially goes > from P to P^2. Source-specific routes don't arise ex nihilo: they are injected into the routing domain through redistribution, just like ordinary, destination-only routes. There is no way for Babel to exchange P prefixes unless the network administrator has explicitly selected P prefixes for redistribution. > But are there any safeguards in the protocol against this happening There are no safeguards in the protocol against a network administrator redistributing unreasonable numbers of source-specific routes into a Babel domain, just like there are no safeguards in the protocol against redistributing the full BGP routing table. > Or ought there to be some operational guidance to be somewhat selective > about source prefixes? Source-specific routing is a mechanism, which, as you rightly note, has a worst-case quadratic cost. We currently know of three applications for source-specific routing, outlined in [SS-ROUTING] Sections II.B and II.C, and none of the three known applications lead to the worst-case quadratic explosion that you fear. Interestingly, two of these applications have the potential to reduce the amount of routing data propagated globally in the Internet, at a moderate cost in the amount of data propagated locally. This seems to me like an excellent tradeoff. As source-specific routing becomes widely available and well-known, people will hopefully find new and exciting applications for this mechanism. Each of these new applications will need to be studied carefully, and its complexity understood. It is not the role of the mechanism, however, to prohibit future applications just because they might turn out to be too costly. -- Juliusz From nobody Thu Nov 5 12:16:01 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C6E3A1961 for ; Thu, 5 Nov 2020 12:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=kumari-net.20150623.gappssmtp.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 WMQ8rIjiIKmi for ; Thu, 5 Nov 2020 12:15:55 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 5AC523A0E68 for ; Thu, 5 Nov 2020 12:15:55 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id m16so2920681ljo.6 for ; Thu, 05 Nov 2020 12:15:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DLFnByZ5nYdHEaAhIIfSWazefaBpZaI9vdClaMpYBSw=; b=TF81R8ZPkhvJOTbvBUinlJU2fYJ2X/htFmC5aFzCqTyhJYSqK+8PznB1cLMFXdig/S yjaTdMynJUXlON79npFkcF66efyZBMjVIZ1mUSrWB/hIlkv0eB7h/mmEXj+092nmEgIm kY3UzIcEpS4nCxnSB9ymBx+/KzIbRZ3m9wmqGrdmi7Oa7rokYpEgafCHoe5PiEoo3n22 Qg+CfHSWTsW/1K1is/v5P1LVNXSyRULv+gYeHUi4SLMaK58QkpETT2cKMk57o6Dxrq+f RMq9DW3K+BQmYCN+RTScReSAVDHTE/bW8yzuSqIMhXSCnfHWjLoAyRS6sVE4/z86XMKZ VLpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DLFnByZ5nYdHEaAhIIfSWazefaBpZaI9vdClaMpYBSw=; b=cDwApHhoZG51li3WvZuOCnqGrRZl950kq72VrAQeJTezMaO85poFlrZcG41Kc9ZyHQ sSAlnGrFfEUf4PYpeTAhUALYK8d5cy4p0y4yQ0ZZahba70nkU3bp5Oq4x7XpiiCjDc+q J+AxP3ZK/0vp1MJE6O8aVx+/nQ+JD1WUu3DTL32Q8H7uVfpPkGcwSDB9CtrLVOXOn2Rx zmljAbXiODdBDjGSeUoGSGNNoeGrd8Oz+JbAwleDmDL4UrO+2gNHCHowcVN08fjRuDWt 0Js34EIuNqcbql6o1Q/SRGEdIZ5eBwNBJlmIKWYn3MLtxl485HT3TX6zAMFxH8jzWYR7 9gKA== X-Gm-Message-State: AOAM531xi82THCRh1TFW5K5ujdwGXcml8hv6zIhc298edRDZyAo7caND jgaZD3TTHqprXDqeLBVWQM9tduPCXRQ1ip/Sg6itMQ== X-Google-Smtp-Source: ABdhPJxUazvMM6M7m/ifYMNmcVUaAz049oNn+raupO0jxqU9Rn5l5EUyZTQnpPXwvxSPzkRDv0OCbp9OQTMQsb2xjns= X-Received: by 2002:a2e:921a:: with SMTP id k26mr1385042ljg.79.1604607352934; Thu, 05 Nov 2020 12:15:52 -0800 (PST) MIME-Version: 1.0 References: <160444589696.9348.17838097712934982658@ietfa.amsl.com> <87wnz1uzts.fsf@toke.dk> In-Reply-To: <87wnz1uzts.fsf@toke.dk> From: Warren Kumari Date: Thu, 5 Nov 2020 15:15:15 -0500 Message-ID: To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: The IESG , babel-chairs@ietf.org, Donald Eastlake , babel@ietf.org, draft-ietf-babel-source-specific@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 20:15:58 -0000 On Wed, Nov 4, 2020 at 6:27 AM Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > Warren Kumari via Datatracker writes: > > > Warren Kumari has entered the following ballot position for > > draft-ietf-babel-source-specific-07: 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/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-babel-source-specific/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I apologize for being rushed, and not balloting earlier, but I feel lik= e I must > > have missed something fundamental here. > > > > The example in Section 4 (Data Forwarding) illustrates an issue, but do= esn't > > actually *state* which (A or B) next hop will be used. The text then sa= ys that: > > "A Babel implementation MUST choose routing table entries by using the > > so-called destination-first ordering,". I interpret this to mean that t= he > > packet "with source 2001:DB8:0:2::42 and destination 2001:DB8:0:1::57" = should > > use next-hop A. This means that you will be sending the packet to the > > destination with no regard for if the provider connected to next-hop A > > carries/announces 2001:DB8:0:2::/64. If if it doesn't, this will look l= ike a > > spoofing attack, and the ISP will (rightly) drop it. > > > > The only way that I can see this working is if: > > 1: destination routes never point "outside" the network (and so will ne= ver hit > > inbound BCP38 filters) or 2: destination routes always "match" - if you= install > > x:y:z::/q pointing at next-hop A, you also install the same router poin= ting at > > next-hop B (this is pointless). > > > > Please help me understand what I'm missing here -- routing on destinati= on to an > > ISP (which is what I'm assuming based on the "small networks" statement= ) seems > > like it will route packets with ISP B sources addresses to ISP A, runni= ng into > > BCP38/anti-spoofing filters. BCP84 also covers a number of scenarios - = it > > sounds like you are referring to Section 4.3. Send Traffic Using a Pro= vider > > Prefix Only to That Provider, but that is exactly what is not happening= above. > > > > Again, I'm assuming that I'm just missing something blindingly obvious = here, > > but it would be good to figure out what, so the document can be clarifi= ed and > > others don't fall into the same trap... > > Please see my reply to Alvaro, where I describe how the multi-provider > use case is supposed to work: > > https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/ > So, that text certainly helps, but it ain't clear **from the document itself** - I think that it would be helpful to include something along these lines in the document, and a general warning of the "this should be used carefully". I also think that it would be useful to explicitly state which (A or B) is the result of the rules applied. Thank you for addressing my concerns; I'm trying to make sure that readers understand the intent and don't shoot themselves in the foot... W > -Toke --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Nov 5 13:51:29 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6149B3A1A75; Thu, 5 Nov 2020 13:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZQlqEwSGliXB; Thu, 5 Nov 2020 13:51:21 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C5D793A1A73; Thu, 5 Nov 2020 13:51:20 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A5LpIYH012126; Thu, 5 Nov 2020 22:51:18 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 62D38119B05; Thu, 5 Nov 2020 22:51:18 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id jj-l6rZiGGkO; Thu, 5 Nov 2020 22:51:16 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C322E119AFE; Thu, 5 Nov 2020 22:51:15 +0100 (CET) Date: Thu, 05 Nov 2020 22:51:12 +0100 Message-ID: <87lfff8obz.wl-jch@irif.fr> From: Juliusz Chroboczek To: Warren Kumari Cc: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , The IESG , babel-chairs@ietf.org, Donald Eastlake , babel@ietf.org, draft-ietf-babel-source-specific@ietf.org In-Reply-To: References: <160444589696.9348.17838097712934982658@ietfa.amsl.com> <87wnz1uzts.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Thu, 05 Nov 2020 22:51:18 +0100 (CET) X-Miltered: at korolev with ID 5FA473D6.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA473D6.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA473D6.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Warren Kumari's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 21:51:24 -0000 >> Please see my reply to Alvaro, where I describe how the multi-provider >> use case is supposed to work: >> >> https://mailarchive.ietf.org/arch/msg/babel/7_O-b6bN525EonbZu0cf6_hIjKU/ > So, that text certainly helps, but it ain't clear **from the document > itself** I think you may very well be right. Our work on source-specific was described in detail in [SS-ROUTING], and while we did try to repeat the necessary background in the I-D, we may have been a little too terse. -- Juliusz From nobody Fri Nov 6 13:40:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C773A0D64; Fri, 6 Nov 2020 13:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=att.onmicrosoft.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 KH88MYsgf5-z; Fri, 6 Nov 2020 13:40:39 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 268863A0D2C; Fri, 6 Nov 2020 13:40:39 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A6LXvB9016222; Fri, 6 Nov 2020 16:40:37 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 34n9epfh2p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Nov 2020 16:40:37 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A6Lea5T005152; Fri, 6 Nov 2020 16:40:36 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A6LeUv1005047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 16:40:30 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id ED18A4016B7E; Fri, 6 Nov 2020 21:40:29 +0000 (GMT) Received: from MISOUT7MSGED1DA.ITServices.sbc.com (unknown [135.66.184.175]) by zlp27128.vci.att.com (Service) with ESMTPS id C949A4016B62; Fri, 6 Nov 2020 21:40:29 +0000 (GMT) Received: from MISOUT7MSGEX2DB.ITServices.sbc.com (135.66.184.188) by MISOUT7MSGED1DA.ITServices.sbc.com (135.66.184.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 6 Nov 2020 16:40:29 -0500 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2DB.ITServices.sbc.com (135.66.184.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Fri, 6 Nov 2020 16:40:29 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.107) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Fri, 6 Nov 2020 16:40:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O29BXL/+7zqfigb5VgVoYmij5obLGSormk/Q8egcrVygUdZu7RBzf9Bw5H/kXFWm8SZ38jo+uOhcxVFBDuL1+4RlK5m7Co8WEvuelCYpL7G4XIvkrIc6hVXr9VhoTgvPe/CS/jj4r7MjHCt0SvWr/IE2GjPwrJlyjgcSlasgvmtZiNYIG6o60AIanq2N//goeMoI3Hz+2RkrtMJ2WsBMJusyKfqHguDK2MvmLCqVRkkmbpT9m9s+tD9DJ5+Qd9Ju1xZRKDHqcUHr03hkzeztmREdWulf2lHYldcFFrJBw32Tm3SOSlyLK/QFP1Tmvjq/ZGwx9BsGNVlXlt6i1DNvWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAX8MMRnsxx0hmA9iZa5L0eXhYbJiXBr27WMNnXBSiA=; b=CuKmY4FmHrB5CRaeSHNcCP3SunEEfz6VSiZeVrnObOC9s0rugGg+zZYn3j/XTWLuSk9i+OgA269pz8J9tbHOkS1Nsf7z2u6FzGoJ7em3Tx7QhZAr4qTs2wD3se2YIrbrP1b/otW5AAE7YRbdZWlpt/1b5U3N51mQbXgvdBkLFCawzIiJBmaS4CU9iKILoza01mQOESXOF6SEYcTZ5vdFad4f3hkTaW9t7HmyJwdQYFzI/7ZN2/pM6YxpkFJRODcB+rPesxMrxMJ73aYboW9H/7ob+UlwjFg7Mw2E/EdGUTXygpK/hbL5v1DajLpMHKoFGNMLNgaw3s1EzSm9g0q5jg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OAX8MMRnsxx0hmA9iZa5L0eXhYbJiXBr27WMNnXBSiA=; b=ZA+yESxpi2+DxY35b/FeDRwBKyJNB8TW2XTARi0naGB8S8sJ2S0oE+vfsu2EyM0YONVxTEhW1e4Z/D3Igt4BGCcYEe/Ho9zdm6gd0RXFhGW6TE7MUpytMVqlkfSPWncGeOBVNSgtsV9JiGHkKmWrOYy/JLN0HhG92fTjo919nLs= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB4080.namprd02.prod.outlook.com (2603:10b6:805:2c::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.27; Fri, 6 Nov 2020 21:40:26 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Fri, 6 Nov 2020 21:40:26 +0000 From: "STARK, BARBARA H" To: "'Rob Wilton (rwilton)'" , "'Mahesh Jethanandani'" CC: "'The IESG'" , "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'Babel at IETF'" , "'Donald Eastlake'" Thread-Topic: Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWstJ8CLomYVKETkWvjHAQXHsDcqm4SaMAgAEr5gCAAh0jcA== Date: Fri, 6 Nov 2020 21:40:25 +0000 Message-ID: References: <160451197790.28880.17597785068103610213@ietfa.amsl.com> <0CA8EA3A-4BB0-46EF-8FAC-D11B846852B4@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69534c48-65df-4c5d-f967-08d8829c92ab x-ms-traffictypediagnostic: SN6PR02MB4080: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VzFDk+plIKGQwWgDfB09rLLmt23u9OEgGZJFqYd/TBMuzyHOXepNSX7eSrHMcerZyyQrqLVLNYDmBJiKwND4w95rpNd7ZLSShZkLdsO6ReODhA72e3UjonhQFXSzrywdmOfxzarQwOEd9WBdvZLOT+Zek8wmx/52R/fNQInpSpI58Jx17S0wZUTHhJENDSLCyomqUn9l+gynws6yUZ6vTZCHlL2fozZlRT81VsWOHkGodKwEDcY+zbYa+N2AJFcTqwBI5CWSXor7jKR2rnCqX5d4mWAAzYS6/u06G4xI4iXSOJ3KCYwD6nXIKwtAcW7pHd5FtIQO7MvuO8zRDAGytwr0ZbCArM5DGjeBdK+5xHnuZpz/GudY/MthaDLWVlHuUkwNpZmmD/JETxIAvrvjOg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(346002)(376002)(396003)(4326008)(66446008)(66556008)(9686003)(66574015)(8676002)(54906003)(8936002)(82202003)(316002)(186003)(966005)(53546011)(5660300002)(6506007)(66946007)(83380400001)(55016002)(7696005)(66476007)(110136005)(2906002)(71200400001)(478600001)(52536014)(26005)(76116006)(86362001)(33656002)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: n3UuOLgRZ7Dm0GaYr4zDEdNKOridUT0LHgGFzPlTvVgMrKwCKcuZQNVcGwvVLBDLGulXVeKupWcnNWS/s//GqNo2Lbnp77ZY+S4Sar5UDuB3Qpfks+qT5qK49/jPSbue1GEKYfxegXmZ34P0GNjPOcAlJ+1dFwOQUxHyQzQC/m7ItHbW8h8r7NlMcso9mIvoJhqHX/hAkP1H4jwir2VPvpKzz3WWxph1iVvN+Io6n7Vj2Bq3seDf53Ws4Ft1qN9lgvEXB/2xn2eOgpOhadoKX+yh+CBEZDuQVQb0FeDuNwct3ZdqLt2tsfO6Hj14m370yDiW5sP/SD7zdNPLy4hMN2l621gp8fzt45e0nWF0LFHiBpryN4BC8L3moTruujuOyFX2waUuFaUsvxixW9WYQMygif25cW5h81nfTNpW3fUfB0aMVJHt8vEesM0qBgU7WrgkafWHXgcoRPrPgTzTYBPmfEjcqK3/+KL1pRoQBBNXGnrvtSfRzX0QGE7Rl0qFgNmHnBXz+mHzlJBQzz2vEWWcakkLaS3HiibTKjIhsn+7HhxSSjqfz/k3N09ceomkPoslIUyEi4mmm2zJLvHE/Of8GUey8I7olSTRVC+IX42qNOBDBCdc47MYF57f0v1ZJCcOcwt29cZfYOWK7BZ8+g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69534c48-65df-4c5d-f967-08d8829c92ab X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2020 21:40:25.8659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9luXNsqKORby9YrTY1fTOH8K/pSXSrqrOwCid/QFUxqMhq+L5j2YI2UX7qgw4nqX X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4080 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 28E031DB815847E60633B0AEC113BAE346EAF158D77F645B5573F174690893382 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-06_06:2020-11-05, 2020-11-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxlogscore=999 phishscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011060150 Archived-At: Subject: Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 21:40:41 -0000 Hi Rob and Mahesh, > Hi Mahesh, >=20 > Making it a normative reference only means draft-ietf-babel-information- > model contains some text (i.e. the text about datastores) that can only b= e > properly understood by reading some of RFC 8342. >=20 > Making RFC 8342 an informative reference would mean that there isn't any > text in draft-ietf-babel-information-model that needs RFC 8342 to properl= y > understand it, but that it contains information that may be > interesting/helpful to the reader. If you want RFC 8342 to only be an > informative reference (or potentially not be a reference at all), then I = think > that this document would either need to not talk about datastores at all,= or > provide more description about the concepts that it is ascribing to the > 'enable' properties in the information model. It seems that the terms causing a problem are "operational datastore" and "= running datastore"? I looked around on the Internet to see what I could find about = these terms (because I know the concepts have been around since long before RFC 8342). Here is a link to a definition of "Operational Datastore" from 2013, that m= akes no mention of YANG:=20 https://www.techopedia.com/definition/1226/operational-data-store-ods and the more generic "Datastore" definition (also from 2013): https://www.techopedia.com/definition/23343/datastore "Running datastore" does seem to be more specific to YANG. My brief searche= s haven't found that term outside YANG (yet). The first use of it in YANG I f= ind is RFC6241, where both "running datastore" and "operational datastore" are = used in Appendix C (YANG Module for NETCONF Protocol Operations) in node descriptio= ns. For example: anyxml config { description "Inline Config content: element. Represents an entire configuration datastore, not a subset of the running datastore."; Note the lower case usage. Interestingly, "operational datastore" does not appear in this RFC. Instead, it includes t= he term "configuration datastore". In terminology, "configuration datastore" and "r= unning configuration datastore" are both there (lowercase), but they aren't descri= bed as being concepts unique to YANG or NETCONF. They appear more to be defined as terms of art. I've never read RFC 8342, and had thought Mahesh was including them as well= - understood terms of art (I certainly immediately understood what concepts h= e was referring to when he introduced the words, in spite of my lack of famil= iarity with YANG or NETCONF). I note that babel-information-model uses the terms in lowercase.=20 I don't think a reference to RFC 8342 is appropriate to indicate where thes= e terms of art come from. They clearly predate RFC 8342 and NETCONF. There is= no=20 terminology section in this draft. I'm not keen on adding a terminology=20 section to the draft just for these 2 rather well-understood terms of art. But I would do that (and maybe find a few other terms of art to include so they don't seem out of place), if that were a suitable compromise. Barbara > Thanks, > Rob >=20 >=20 > From: Mahesh Jethanandani > Sent: 04 November 2020 18:24 > To: Rob Wilton (rwilton) > Cc: The IESG ; draft-ietf-babel-information-model@ietf.org= ; > babel-chairs@ietf.org; Babel at IETF ; Donald Eastlake > > Subject: Re: Robert Wilton's No Objection on draft-ietf-babel-information= - > model-11: (with COMMENT) >=20 > Hi Rob, >=20 >=20 > On Nov 4, 2020, at 9:46 AM, Robert Wilton via Datatracker > > wrote: >=20 > Robert Wilton has entered the following ballot position for > draft-ietf-babel-information-model-11: No Objection >=20 > 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.) >=20 >=20 > Please refer to > https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss > - > criteria.html__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI > 16Bb-pj5tYrjseBJzqy6yN$ > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf- > babel-information- > model/__;!!BhdT!zLVd1eLtHrXhlZziRBtQT2MAdZ6mm3waQWNOuByJpI16Bb > -pj5tYrjseBOB6qxxt$ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you for this document. >=20 > I support Ben's discuss regarding reusing the terminology from NMDA. I > think > that the document should have a normative reference to RFC 8342, and > probably > explain that in some places the information model is using the same conce= pts > of > configuration and operational data separation described in NMDA. >=20 > While I am not against a reference to the terminology from NMDA in the > information model, (BTW, I am ignorant on what it means for an > informational draft to have a normative reference), I am not sure whether= it > needs to normative or whether it can be informative. By making it normati= ve, > are we making this information model more YANG specific? Could the > reference to NMDA be normative in the YANG model of this information > model (which the YANG model already does)? >=20 > Thanks. >=20 >=20 >=20 > I also support Alvaro's question about whether the source-routing > component > should be included. >=20 > This is just a comment, and I'm not proposing that you change tack, but I > have > to confess that I question how beneficial publishing an Information Model > really is. I understand that the goal here is to be able to publish two > different data models, one based on YANG and other based on BBF's [TR- > 181] From nobody Fri Nov 6 14:31:46 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883493A0DDA for ; Fri, 6 Nov 2020 14:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 L2Zoa33J4WyF for ; Fri, 6 Nov 2020 14:31:42 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 697253A0DDB for ; Fri, 6 Nov 2020 14:31:36 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A6MVQUi022411; Fri, 6 Nov 2020 23:31:26 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4F970122AA3; Fri, 6 Nov 2020 23:31:26 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Yp2hEP28Jgk3; Fri, 6 Nov 2020 23:31:24 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6620A122AA1; Fri, 6 Nov 2020 23:31:23 +0100 (CET) Date: Fri, 06 Nov 2020 23:31:23 +0100 Message-ID: <87d00qungk.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: Valery Smyslov , Donald Eastlake , Barbara Stark , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgense?= =?ISO-8859-1?Q?n?= User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 06 Nov 2020 23:31:26 +0100 (CET) X-Miltered: at korolev with ID 5FA5CEBE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA5CEBE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA5CEBE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 22:31:45 -0000 Dear all, We've had a discussion with Barbara and Toke today, and we've come to the conclusion that there is an oversight in draft-ietf-babel-hmac-12. In Section 4.1, we say Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and MAY implement other MAC algorithms. As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size between 1 and 32 octets (8 and 256 bits). However, both implementations of Babel-MAC only ever produce 16-octet BLAKE2s hashes. This is done for the following reasons: - Babel-MAC is not believed to be vulnerable to collision attacks, hence 128 bits is believed to be large enough; - BLAKE2s is intended as a more lightweight alternative to SHA2-256, which is the recommended algorithm if 128-bit hashes are believed to not be sufficient. However, the digest size is not indicated in the draft. Therefore, in order to align the draft with implementation practice, I am asking the list's permission to clarify the draft by changing the paragraph cited above to say: Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693] with 16-octet (128-bit) hashes, and MAY implement other MAC algorithms and hash sizes. Donald, assuming nobody objects to the above, what is the right point at which to request this clarification? AUTH48? Or publish an erratum just after the RFC goes out? Sorry for the oversight, and thanks for everyone's help, -- Juliusz From nobody Fri Nov 6 14:43:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938603A0DE2 for ; Fri, 6 Nov 2020 14:43:06 -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 eiHgcGg0K3GJ for ; Fri, 6 Nov 2020 14:43:04 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 4471D3A0DDB for ; Fri, 6 Nov 2020 14:43:04 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id y16so3102602ljk.1 for ; Fri, 06 Nov 2020 14:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ODrs6FprKzWD14giFkDite5xV5ZiMP6gYLcR2zB/sxE=; b=oveLuDu10Jrj83IYoNBaE/O+GiqoJSBdiAFxLZAvlRcLtChdaw/uILFw//D1TLAqil 3d08cGghfFGp9T8pdc8GazKaX3/tTVQPnq2qAj7o+6ZMTH9mndViw2Obz0y74NuA/0OQ a+q1RzUp1dmlOpCQYWrDCarfSXMltQtj1l1WJ56GtQxxTQSQSBrSntn7wXEqUGPd98O6 v9R+2jwKFtRTojqgOU086W6PBb19NGTm7GGJ65pMz+iYCn//mnsa8LwDN8YsRKgKkJ06 xqD1f1GthMe6bYK2V2y/4UElf55S1Nr9GAPSpFe6eA+psD2nwDvGgJSgU0rCV52SQT6n /e3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ODrs6FprKzWD14giFkDite5xV5ZiMP6gYLcR2zB/sxE=; b=ECBtRwlK3ftWlZ0zlURAV3cMZjT8joi7JWMo4P728uNCuNO8Vbj/4rOKT+/ZOH0RWZ o694a/JeydIJmuFqIl5IY9d5viRiJF2eqOHg8mPbj6I+f5xIWgMQaw61sxIEk6PS9Xdm mw5ttF/hXByHzuujko7bqocQ8GSQFWk/J3OrN1V1wPAFTDrWyRNiPI7awSOw0HPv82t4 z9brkZBMRIokrQi7UzCiZRNJuzSzM/cYt2Xu8Dqa08BIOh9bytJF5zOD40vBT5PABXnc 8io7SQAby/esI++W+vOait8crswgRyVQkS2Pc6Z8rdi4es7lgxENEmnEJQFdFGvs/xVD X0Og== X-Gm-Message-State: AOAM531X4UjLQOj8SZGXeFVRreCMlEZMYdJbrJrE3Esy7dNDigOPlInW VhYUX5egZmxAkFpgFPG0Li1Wzns2MkAmun45kIJ8tXhmnT8= X-Google-Smtp-Source: ABdhPJyrFC2lBVt0StdUUrJulmzZnrFimiqK+4+OeV7zjNWUYdCTBLLAaokS/865cXuLwVM2Jx6d5gKfDaC9qEAtwiQ= X-Received: by 2002:a2e:b4c2:: with SMTP id r2mr1625170ljm.216.1604702582211; Fri, 06 Nov 2020 14:43:02 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> In-Reply-To: <87d00qungk.wl-jch@irif.fr> From: David Schinazi Date: Fri, 6 Nov 2020 14:42:51 -0800 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF , Donald Eastlake , Valery Smyslov , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Barbara Stark Content-Type: multipart/alternative; boundary="0000000000006207f805b377ef3e" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 22:43:07 -0000 --0000000000006207f805b377ef3e Content-Type: text/plain; charset="UTF-8" I support this change. David On Fri, Nov 6, 2020 at 2:31 PM Juliusz Chroboczek wrote: > Dear all, > > We've had a discussion with Barbara and Toke today, and we've come to the > conclusion that there is an oversight in draft-ietf-babel-hmac-12. In > Section 4.1, we say > > Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] > and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], > and MAY implement other MAC algorithms. > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size > between 1 and 32 octets (8 and 256 bits). However, both implementations > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. This is done for > the following reasons: > > - Babel-MAC is not believed to be vulnerable to collision attacks, hence > 128 bits is believed to be large enough; > > - BLAKE2s is intended as a more lightweight alternative to SHA2-256, > which is the recommended algorithm if 128-bit hashes are believed to > not be sufficient. > > However, the digest size is not indicated in the draft. Therefore, in > order to align the draft with implementation practice, I am asking the > list's permission to clarify the draft by changing the paragraph cited > above to say: > > Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] > and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693] > with 16-octet (128-bit) hashes, and MAY implement other MAC algorithms > and hash sizes. > > Donald, assuming nobody objects to the above, what is the right point at > which to request this clarification? AUTH48? Or publish an erratum just > after the RFC goes out? > > Sorry for the oversight, and thanks for everyone's help, > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000006207f805b377ef3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support this change.

David

On Fr= i, Nov 6, 2020 at 2:31 PM Juliusz Chroboczek <jch@irif.fr> wrote:
Dear all,

We've had a discussion with Barbara and Toke today, and we've come = to the
conclusion that there is an oversight in draft-ietf-babel-hmac-12.=C2=A0 In=
Section 4.1, we say

=C2=A0 =C2=A0Every implementation MUST implement HMAC-SHA256 as defined in = [RFC6234]
=C2=A0 =C2=A0and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RF= C7693],
=C2=A0 =C2=A0and MAY implement other MAC algorithms.

As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size
between 1 and 32 octets (8 and 256 bits).=C2=A0 However, both implementatio= ns
of Babel-MAC only ever produce 16-octet BLAKE2s hashes.=C2=A0 This is done = for
the following reasons:

=C2=A0 - Babel-MAC is not believed to be vulnerable to collision attacks, h= ence
=C2=A0 =C2=A0 128 bits is believed to be large enough;

=C2=A0 - BLAKE2s is intended as a more lightweight alternative to SHA2-256,=
=C2=A0 =C2=A0 which is the recommended algorithm if 128-bit hashes are beli= eved to
=C2=A0 =C2=A0 not be sufficient.

However, the digest size is not indicated in the draft.=C2=A0 Therefore, in=
order to align the draft with implementation practice, I am asking the
list's permission to clarify the draft by changing the paragraph cited<= br> above to say:

=C2=A0 =C2=A0Every implementation MUST implement HMAC-SHA256 as defined in = [RFC6234]
=C2=A0 =C2=A0and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RF= C7693]
=C2=A0 =C2=A0with 16-octet (128-bit) hashes, and MAY implement other MAC al= gorithms
=C2=A0 =C2=A0and hash sizes.

Donald, assuming nobody objects to the above, what is the right point at which to request this clarification?=C2=A0 AUTH48?=C2=A0 Or publish an erra= tum just
after the RFC goes out?

Sorry for the oversight, and thanks for everyone's help,

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000006207f805b377ef3e-- From nobody Fri Nov 6 14:51:42 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F7E3A0DEF for ; Fri, 6 Nov 2020 14:51:41 -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, 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=toke.dk 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 JTfCVY4GfObe for ; Fri, 6 Nov 2020 14:51:39 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 45E543A0DE9 for ; Fri, 6 Nov 2020 14:51:38 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1604703096; bh=UoX6MYh59JTlgR/krRl9uSBVXXpiasjShNWNrWNQtMk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QRo8sjiY2QvMO+2Iyiww7RZ3JCpV6YFqNnfaY5fvuqMWZwlvliA5vTf1TsnIx+zkM F8/12FKbo0N5IAVDCK28zfOfkmlmQpzjFQAeaJ8ZpnhoBNrRwXv7UvJ5dn5wRi/9Qe bl+EQMMUgwJaWYxHZe3+YrwHwBTsNksIc2QYAZIQ4bIV7pc6jymfsD4UZH2at89dpP pol4WlpuKOmnG4pLASKd+VAeI4EoRXExHt+LqnuftBewAVNkPLKmk4Cv8NndFm/uLC 1MlTBh+RcTLbU8b0nz3GnOteeUT98bOJi9C9C/EO5NXkwRX2V9CRahQvspjnTmCOIm 2wFyT9Pfyvd4A== To: Juliusz Chroboczek , babel@ietf.org Cc: Valery Smyslov , Donald Eastlake , Barbara Stark In-Reply-To: <87d00qungk.wl-jch@irif.fr> References: <87d00qungk.wl-jch@irif.fr> Date: Fri, 06 Nov 2020 23:51:33 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87h7q2f6a2.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 22:51:41 -0000 Juliusz Chroboczek writes: > Dear all, > > We've had a discussion with Barbara and Toke today, and we've come to the > conclusion that there is an oversight in draft-ietf-babel-hmac-12. In > Section 4.1, we say > > Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] > and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], > and MAY implement other MAC algorithms. > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size > between 1 and 32 octets (8 and 256 bits). However, both implementations > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. Okay, something seemed off about this when I read it just now, so I just double checked: And in fact both implementations use 32-byte Blake2s digest sizes... I still support making the change and specifying the size, but to correspond to current implementation practice the change would need to be "with 256-bit (32 octet) hashes". -Toke From nobody Fri Nov 6 15:06:29 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E908F3A0E24 for ; Fri, 6 Nov 2020 15:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 dGJEukDGWyjw for ; Fri, 6 Nov 2020 15:06:26 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 F0B7A3A0E22 for ; Fri, 6 Nov 2020 15:06:25 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0A6N6K8D029376; Sat, 7 Nov 2020 00:06:21 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id DCDA312387B; Sat, 7 Nov 2020 00:06:20 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id x2CclYmQG1Jk; Sat, 7 Nov 2020 00:06:19 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id C4540123879; Sat, 7 Nov 2020 00:06:18 +0100 (CET) Date: Sat, 07 Nov 2020 00:06:18 +0100 Message-ID: <87blgaulud.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Valery Smyslov , Donald Eastlake , Barbara Stark In-Reply-To: <87h7q2f6a2.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 07 Nov 2020 00:06:21 +0100 (CET) X-Miltered: at korolev with ID 5FA5D6EC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FA5D6EC.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FA5D6EC.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 23:06:28 -0000 > Okay, something seemed off about this when I read it just now, so I just > double checked: And in fact both implementations use 32-byte Blake2s > digest sizes... Looking through the git history... the original version implemented by Clara, Weronika and myself used 16-byte hashes, which was the original intent, for the reasons outlined in my previous mail. The version currently maintained by Antonin does indeed generate 32-byte hashes. While I haven't checked myself, Toke says that so does his version, and the two versions have been shown to interoperate. > I still support making the change and specifying the size, but to > correspond to current implementation practice the change would need to > be "with 256-bit (32 octet) hashes". No strong opinion either way. Let's give people a chance to comment. -- Juliusz From nobody Fri Nov 6 15:09:35 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CFB3A0E23 for ; Fri, 6 Nov 2020 15:09:34 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 xYUWscTHn7j1 for ; Fri, 6 Nov 2020 15:09:31 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 5F1593A0E22 for ; Fri, 6 Nov 2020 15:09:27 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id v5so2964730wmh.1 for ; Fri, 06 Nov 2020 15:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:cc:subject:from:to:date :message-id:in-reply-to; bh=F2S318ofziTiDZu/pYTLTnqu+Wz7YDJ3ggnPisW7Z2o=; b=DlkSWVkR3y0yZf57JBT4EPxD6+YsXEU/zB8O63l2gPcFA7lPePnijBOirVfjCtqleY SNVdsIe+2j/rMxo/v4Lgm5/Y7wbckHeGc44xodmMNCsuzZqFLXHG6o/paxlA7v4a4wN/ wJYWPeUdPSSQeXJS1wvFS9YXeekEAtS00ZkdiZwXci4U32DGnbTWaMNDhSX75OOZS3vZ HLalV3QowBJwmilbY+SuD9LMn6meHiK+60zS0cKeOE5qnFytsVk2GKJmdGNpmmm5NYS4 ZWu24SYm5XMoWuP8HfeDGZQUx5vriOvFsQVA/s6+Y51rwKodvJC4Uuw58KK+QZbKTIZ0 w2qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:cc :subject:from:to:date:message-id:in-reply-to; bh=F2S318ofziTiDZu/pYTLTnqu+Wz7YDJ3ggnPisW7Z2o=; b=gzkd6538vRDkJYEVNiJo4gN2c9c23ivvJZF0eUfrTXUmW2VdIoVoHoBn06O86sTbnx dCUSy9zrSYwYzrjiuykXbB5HUm3pA+un5+tEWQl2hXirUULq0WTZA0duxj7jA+mV9MeG JJNGthWuG5ygwdU8YnKemipsqWKSWrkCErp2q/cFFtEF4z7r3dZwEmY3myEkWxxcBcGn XZQvDX5mQOm+waPLXfpqdGFxtmGKxr0Z0XHvsiI+yTO3Ixa3enyLhxt42j2PU/EPaU1R J29pbcTuAWuC7Wkn2MdoJF1VLO+t01GrcYDfin/UCtqZ9HBwd90/xhIZ79wdTZl+mfTV 58Ug== X-Gm-Message-State: AOAM5334Pvewy9E8wk5hzhCqJSPM7Gq7pn28QQhtIw0qET5tZlQE3daw b7PCMrOYiF48QP41x0sAH8k= X-Google-Smtp-Source: ABdhPJw+Nsc8na1Z1nm7QjLC5D3Ovo4XtRsK8vOU0iVrjfj2E+G8s2aRyvyOZTVsWZrE9VmyzPbLIw== X-Received: by 2002:a1c:2108:: with SMTP id h8mr1858627wmh.63.1604704165869; Fri, 06 Nov 2020 15:09:25 -0800 (PST) Received: from localhost (243.2.26.109.rev.sfr.net. [109.26.2.243]) by smtp.gmail.com with ESMTPSA id a17sm4365601wra.61.2020.11.06.15.09.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Nov 2020 15:09:25 -0800 (PST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Cc: "Donald Eastlake" , "Valery Smyslov" , "Barbara Stark" From: =?utf-8?q?Antonin_D=C3=A9cimo?= To: =?utf-8?q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , "Juliusz Chroboczek" , Date: Fri, 06 Nov 2020 23:53:54 +0100 Message-Id: In-Reply-To: <87h7q2f6a2.fsf@toke.dk> Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 23:09:34 -0000 > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any size > > between 1 and 32 octets (8 and 256 bits). However, both implementation= s > > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. > > Okay, something seemed off about this when I read it just now, so I just > double checked: And in fact both implementations use 32-byte Blake2s > digest sizes... That also seemed off to me. To be fair regarding babeld, the "old" hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2=80= =99re using the reference blake2s implementation, and I changed 16 to the provided BLAKE2S_OUTBYTES =3D 32 constant. > I still support making the change and specifying the size, but to > correspond to current implementation practice the change would need to > be "with 256-bit (32 octet) hashes". Me too. I an exchange earlier this year, Donald and Juliusz explained to me that the size of the output hash is considered part of the hashing algorithm, so yes, I support making that explicit for blake2s. -- Antonin From nobody Fri Nov 6 16:05:08 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27F73A03FB; Fri, 6 Nov 2020 16:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 GSXypC0DRD-j; Fri, 6 Nov 2020 16:05:00 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 D39FC3A03F5; Fri, 6 Nov 2020 16:04:59 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0A703mXu025143; Fri, 6 Nov 2020 19:04:58 -0500 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0083689.ppops.net-00191d01. with ESMTP id 34mq8na25y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Nov 2020 19:04:57 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A704u7u030786; Fri, 6 Nov 2020 19:04:57 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0A704rtA028921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 19:04:53 -0500 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id 52529400B573; Sat, 7 Nov 2020 00:04:53 +0000 (GMT) Received: from GAALPA1MSGEX1AA.ITServices.sbc.com (unknown [135.50.89.96]) by zlp30488.vci.att.com (Service) with ESMTPS id 37545400B574; Sat, 7 Nov 2020 00:04:53 +0000 (GMT) Received: from GAALPA1MSGED2DC.ITServices.sbc.com (135.50.89.140) by GAALPA1MSGEX1AA.ITServices.sbc.com (135.50.89.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Fri, 6 Nov 2020 19:04:45 -0500 Received: from GAALPA1MSGETA02.tmg.ad.att.com (144.160.249.124) by GAALPA1MSGED2DC.ITServices.sbc.com (135.50.89.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Fri, 6 Nov 2020 19:04:38 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.104) by edgeal2.exch.att.com (144.160.249.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Fri, 6 Nov 2020 19:04:38 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=STYn5dkD1imG3KjmWaVVbylaoweG27GJ7whAoqHsIKumWxPFi/Aw1JhBpazU7n1b2ooS5jOrh5jc8hQzKxmO0L1bZ6AM43tRhclryilwh4prauO54pz/xP8zSL64veVVyp4M3gHG4c4pWMuNf9ITxzRGrkBA0ZZB7S45wAwCZZvCe94knd1a0RrE4XVzhTnQdBE5dlFzXoDxqCLVc+WOy8n0nt1g7tSfwSxiHJGrsV8rACHmptUFYI7zvpBWdGnxwvqyQAkrhuJw/u/tUomDNGsphyBgtC259Cof9I+vr2YvrsHuH2hjjD7jIF3kvtO2JQGdVLiXs9AD9yM8ZU8j9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2JRCzZnGaVPI39+8WSgmjlAAEKkVcyBQluycYnvJbdI=; b=Em+NVUUiwbVrUIPdQ5CMmPloPtmWcK7zT8DvhYfPmLDR41SSllavHv4tAeuWh+tAfSjGxv1a50xPnhR0YXE6MlK01R+FcqUNBCAqfulqA1070pk0HQUZZ4+bsOuWGPDgad91Me+PbEuTsjhOWy9L7PBnllM4+5nWYzyKOXXC9HRSC1j350LiNOfATe+/HGxnw569xUB5UPwAJpRu17SNwsGvU6F1kAur/NEG3rrjtcnZlOm0emLEVeIqVWvI6DvM9ANjydK9AAexzxBjAk8RVzvX+SfC8nRZkyqEF1rAUFv5LMf2VlaHdzdlvrKWyfJHm+xtRiZyHvBOrAFeU6GaNQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2JRCzZnGaVPI39+8WSgmjlAAEKkVcyBQluycYnvJbdI=; b=LN45SHZluV9EmP/6HQVWx7GlXxGlkSd3Lc7Hh4WBBwxnN34fLarTMS2X08A4x5W59VJ4e2jrcaWxjJ4qtbHyrokmDJGJVff0AVHiKtMZ5DpGjsWmKqPanXBSwP7O2WiPGqe4ouVOFbi4r3XBJ3ZflROc5n6NydTNJRRB9bOO91c= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN6PR02MB4687.namprd02.prod.outlook.com (2603:10b6:805:98::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.29; Sat, 7 Nov 2020 00:04:37 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::dc3c:5ad:4df8:f8af%7]) with mapi id 15.20.3499.032; Sat, 7 Nov 2020 00:04:37 +0000 From: "STARK, BARBARA H" To: "'Robert Wilton'" , "'The IESG'" CC: "'draft-ietf-babel-information-model@ietf.org'" , "'babel-chairs@ietf.org'" , "'babel@ietf.org'" , "'Donald Eastlake'" Thread-Topic: Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) Thread-Index: AQHWstJ8CLomYVKETkWvjHAQXHsDcqm7qp1Q Date: Sat, 7 Nov 2020 00:04:36 +0000 Message-ID: References: <160451197790.28880.17597785068103610213@ietfa.amsl.com> In-Reply-To: <160451197790.28880.17597785068103610213@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=att.com; x-originating-ip: [144.160.96.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f8a46da4-59ac-48f4-e414-08d882b0b714 x-ms-traffictypediagnostic: SN6PR02MB4687: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MIKRpINUqRcsLYHCYpgGL9kZb7A4yl3aDpH6i4WcgpulKk+0FY/2yuB1UL1EsBrU4KjbqxBb0aBWyAbiSVOwpbulhCE5HYMaTnpK6/diM42udZPpNFYj9o1A44h6JRsRdor/Pt81SrD+lxs9ODb556b32TLCUyxj7gpK9ohJDMRGBBgLG8tKuRl8BNNRJIXa3fVznEKOq/AdV27FJCR++J8eJWH4arlH8AkD5BxQsgomXyT8ayLUkNW65msnQrC5KLv1WXNcAWJBf+ENNlBDAYKaVCp6mKVuzNCRytZ2lXS2eUHQIc1OiZrdqzhoMYKUDVCdn2T2Qb8mrs16UL++gA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(366004)(346002)(396003)(376002)(54906003)(8936002)(33656002)(478600001)(26005)(2906002)(86362001)(83380400001)(7696005)(316002)(110136005)(55016002)(4326008)(5660300002)(66556008)(6506007)(71200400001)(76116006)(66946007)(9686003)(52536014)(64756008)(8676002)(82202003)(186003)(66446008)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: O+F4UM6sxl+WnlzF8mDb1h954qZMZm6lXopjFkCDMrMYkG7XEpEjR3oFqwiQ2xQTQ/TPFqm39Xr5RYEkSAztIoVlx6sGVkwVo4cjuUh4RWcqnZGNQFcFExQOjng8ZSsoLVB175CEbIBNg5mf/stH6GWhjzY+THICXUvF6CsZMJW7UVbp1CjIHDG4pDGd5YVoFQLREHOKYMP7BubTLY5mmAJT/fwuDmHW0U9Z5xG+ulcFOFfIrP3o57Qec+TwNgnfX3nhSPemURkb57eiQe9l0XNCYGUJTgQr/B97csPfVcGCUbeQgc0CT8ZtNN5bhoLBUWcRvVKWoGKZ1Ondb7Wrt8c4aPXzFkWG8iAAS4DzMX7+UknmUXrqAWTKTW6BRY+uHt4e2lDVCdwMAHxBuKLpu4ccItSy9F8b7CWCUHKQUEQ/QCy6WiD7kf61pvLiYbMmITnFH6hOogPjDhnkUSqFQnVP9hc5otNNJhU9Qm0lkmyXs2myMtzt44c+YE78XNa0VczVclfiHMbM2cktkH92vkQ9rPhhg7L4Oj2a7n5ofMVxT3yC7vGYUtAR0XuxJi7csRGP9t326VNg9jnZ35iSPiUoGoeA3o4gFfSLa9ZNUp2gRy5x+TOK2Y4tIWrkzuF7N+UxXNY0Fr88VsLgEbAG4A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f8a46da4-59ac-48f4-e414-08d882b0b714 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2020 00:04:36.8680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VtIld0UHMtikNy26SSk173VVLUJ9IITKqdIMKa4n3uKNvpTlgC9ziwfNiVjzlldO X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR02MB4687 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: FA31DD84945A7E0E73C26AE12DA823A17861655BE3F87E018687738CFBB695AF2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-06_06:2020-11-05, 2020-11-06 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 adultscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 mlxlogscore=999 suspectscore=0 spamscore=0 bulkscore=0 phishscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011060162 Archived-At: Subject: Re: [babel] Robert Wilton's No Objection on draft-ietf-babel-information-model-11: (with COMMENT) X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 00:05:02 -0000 DQpIaSBSb2IsDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3LiBTZXBhcmF0ZSBmcm9tIHRoZSBjb252 ZXJzYXRpb24gd2l0aCBNYWhlc2ggb24NCndoZXRoZXIgdGhlIGRvY3VtZW50IHNob3VsZCBoYXZl IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgODM0Mg0KKHdoaWNoIEkgcmVzcG9uZGVkIHRv IHJlY2VudGx5KSwgSSB3YW50ZWQgdG8gY29tbWVudCBvbiBvbmUgb2YgeW91ciBvdGhlcg0KcG9p bnRzLg0KVGh4LA0KQmFyYmFyYQ0KIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gDQo+IFRoYW5rIHlvdSBmb3IgdGhpcyBkb2N1bWVudC4NCj4gDQo+IEkg c3VwcG9ydCBCZW4ncyBkaXNjdXNzIHJlZ2FyZGluZyByZXVzaW5nIHRoZSB0ZXJtaW5vbG9neSBm cm9tIE5NREEuICBJDQo+IHRoaW5rDQo+IHRoYXQgdGhlIGRvY3VtZW50IHNob3VsZCBoYXZlIGEg bm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgODM0MiwgYW5kDQo+IHByb2JhYmx5DQo+IGV4cGxh aW4gdGhhdCBpbiBzb21lIHBsYWNlcyB0aGUgaW5mb3JtYXRpb24gbW9kZWwgaXMgdXNpbmcgdGhl IHNhbWUgY29uY2VwdHMNCj4gb2YNCj4gY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9uYWwgZGF0 YSBzZXBhcmF0aW9uIGRlc2NyaWJlZCBpbiBOTURBLg0KPiANCj4gSSBhbHNvIHN1cHBvcnQgQWx2 YXJvJ3MgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0aGUgc291cmNlLXJvdXRpbmcNCj4gY29tcG9u ZW50DQo+IHNob3VsZCBiZSBpbmNsdWRlZC4NCj4gDQo+IFRoaXMgaXMganVzdCBhIGNvbW1lbnQs IGFuZCBJJ20gbm90IHByb3Bvc2luZyB0aGF0IHlvdSBjaGFuZ2UgdGFjaywgYnV0IEkNCj4gaGF2 ZQ0KPiB0byBjb25mZXNzIHRoYXQgSSBxdWVzdGlvbiBob3cgYmVuZWZpY2lhbCBwdWJsaXNoaW5n IGFuIEluZm9ybWF0aW9uIE1vZGVsDQo+IHJlYWxseSBpcy4gIEkgdW5kZXJzdGFuZCB0aGF0IHRo ZSBnb2FsIGhlcmUgaXMgdG8gYmUgYWJsZSB0byBwdWJsaXNoIHR3bw0KPiBkaWZmZXJlbnQgZGF0 YSBtb2RlbHMsICBvbmUgYmFzZWQgb24gWUFORyBhbmQgb3RoZXIgYmFzZWQgb24gQkJGJ3MgW1RS LQ0KPiAxODFdLg0KPiBCdXQgd2hhdCB3ZSBlbmQgdXAgd2l0aCBpcyBhbiBpbmZvcm1hdGlvbiBt b2RlbCBkZWZpbmVkIGluIGEgY3VzdG9tIGFkIGhvYw0KPiBsYW5ndWFnZSwgd2hpY2ggd2lsbCBu YXR1cmFsbHkgbmVjZXNzaXRhdGUgZm9yIHRoZSBZQU5HIGFuZCBUUi0xODEgbW9kZWxzIHRvDQo+ IGJlDQo+IGdlbmVyYXRlZCBieSBoYW5kLCBhbmQgZm9yIGFsbCB0aHJlZSBtb2RlbHMgdG8gYmUg a2VwdCB1cCB0byBkYXRlIGFuZA0KPiBjb25zaXN0ZW50IHdpdGggZWFjaCBvdGhlci4gIEhlbmNl LCBJIHdvbmRlciB3aGV0aGVyIHJldHJvc3BlY3RpdmVseSBpdA0KPiB3b3VsZA0KPiBoYXZlIGJl ZW4gYmV0dGVyIHRvIGp1c3QgZGVmaW5lIHRoZSBZQU5HIG1vZGVsIGluIElFVEYgYW5kIGFzayBC QkYgdG8gdXNlDQo+IHRoYXQNCj4gYXMgc291cmNlIHJlZmVyZW5jZSB0byBjb25zdHJ1Y3QgdGhl IFRSLTE4MSBtb2RlbCBmcm9tLCBpZGVhbGx5IGFzIGENCj4gcHJvZ3JhbW1hdGljIGNvbnZlcnNp b24sIG9yIGZhaWxpbmcgdGhhdCBieSBoYW5kLiAgQXQgbGVhc3QgdGhhdCB3YXkgdGhlcmUgYXJl DQo+IG9ubHkgdHdvIHRoaW5ncyB0byBrZWVwIGluIHN5bmMgcmF0aGVyIHRoYW4gdGhyZWUuDQo+ IA0KPiBSZWdhcmRzLA0KPiBSb2INCg0KVGhlIHNob3J0IGFuc3dlciB0byB0aGUgcmV0cm9zcGVj dGl2ZSBxdWVzdGlvbiBpcyAiTm8iLg0KTG9uZyBhbnN3ZXI6DQpQZXJzb25hbGx5LCBJIHdvdWxk IGhhdmUgcHJlZmVycmVkIHRvIG9ubHkgZG8gdGhlIFRSLTE4MSBtb2RlbCwgYW5kIHRoZW4sDQpp ZiBzb21lb25lIHdhbnRlZCBhIFlBTkcgbW9kZWwsIHRoZXkgY291bGQgZmlndXJlIGl0IG91dCBm cm9tIG15IFRSLTE4MQ0KbW9kZWwuIE15IGVtcGxveWVyIChhbG9uZyB3aXRoIG1vc3QNCklTUHMg YXJvdW5kIHRoZSB3b3JsZCkgdXNlcyBUUi0wNjkgdG8gbWFuYWdlDQphbGwgb2YgaXRzICJSZXNp ZGVudGlhbCBHYXRld2F5IiBXaS1GaSByb3V0ZXJzLiBCYWJlbCBpcyB3ZWxsLXN1aXRlZA0KdG8g c3VjaCBXaS1GaSByb3V0ZXJzLiBJJ20gbm90IGF3YXJlIG9mIGFueSB1c2Ugb2YgTkVUQ09ORiBv ciBZQU5HIA0KdG8gbWFuYWdlIFdpLUZpIHJvdXRlcnMgb24gYSBsYXJnZSBzY2FsZS4NCkkgYW0g YXdhcmUgb2YgMiBtYWpvciBJU1BzIHdobyB3YW50IHRvIHVzZSBORVRDT05GIHRvIG1hbmFnZSB0 aGVpcg0KV2ktRmkgcm91dGVycyBhbmQgYXJlIHdvcmtpbmcgaW4NCkJCRiB0byB0cmFuc2xhdGUg QkJGIFRSLTE4MSBpbnRvIFlBTkcsIHNvIHRoZXkgaGF2ZSBhIHVzYWJsZSBkYXRhIG1vZGVsDQpm b3IgdGhhdCBwdXJwb3NlLg0KQnV0IGluIHRoZSBpbnRlcmVzdCBvZiBoYXJtb25pemF0aW9uIGJl dHdlZW4gQkJGIGFuZCBJRVRGLCBJIHRob3VnaHQgaXQgYmVzdA0KdG8gZG8gYW4gaW5mbyBtb2Rl bCB0aGF0IGNvdWxkIGRyaXZlIGJvdGguDQpBcyBpdCB0dXJucyBvdXQsIHRoaXMgaGFzIGhhZCBo YWQgdW5pbnRlbmRlZCBnb29kIGNvbnNlcXVlbmNlcy4gVGhlIEJhYmVsIHByb3RvY29sDQppbXBs ZW1lbnRvcnMgaGF2ZSB1c2VkIHRoZSBJbmZvIG1vZGVsIGFzIGEgYmFzaXMgZm9yIHRoZSByZXBv cnRpbmcgYW5kIA0KY29uZmlndXJhdGlvbiBvcHRpb25zIHRoZXkgZXhwb3NlIHRocm91Z2ggdGhl aXIgdXNlciBpbnRlcmZhY2VzIGFuZCBBUElzLiANClRoZXJlZm9yZSwgd2UgaGF2ZSBoYWQgZ29v ZCBpbnB1dCBmcm9tIHRoZSBpbXBsZW1lbnRvcnMgb24gdGhlIGluZm8gbW9kZWwsDQplZmZlY3Rp dmVseSBoYXZlIGltcGxlbWVudGF0aW9ucywgYW5kIGlmIHNvbWVvbmUgd2FudHMgdG8gdXNlIFRS LTE4MSBvcg0KWUFORyBmb3IgbWFuYWdlbWVudCwgdGhlIGhvb2tzIHdpbGwgZXhpc3QgaW4gdGhl c2UgaW1wbGVtZW50YXRpb25zLiANCk5vbmUgb2YgdGhlIGltcGxlbWVudG9ycyBoYXZlIGludGVy ZXN0IGluIGVpdGhlciBZQU5HIG9yIFRSLTE4MS4NCg0KQW55d2F5LCBpdCBtYXkgYmUgdXNlZnVs IHRvIHRoaW5rIG9mIG1lIGFzIHByaW1hcmlseSBhIEJCRiBjb21tdW5pdHkgbWVtYmVyDQp3aG8g aXMgcGFydGljaXBhdGluZyBpbiBJRVRGIHRvIGZ1cnRoZXIgY2VydGFpbiBlZmZvcnRzIHJlbGF0 ZWQgdG8gbXkgQkJGIHdvcmsuDQpJdCB3YXMgdmVyeSBnb29kIGZvciBCYWJlbCBXRyB0aGF0IE1h aGVzaCBzbyBraW5kbHkgYWdyZWVkIHRvIGhlbHAgd2l0aCB0aGUgWUFORyANCm1vZGVsIGF0IHRo ZSB0aW1lIHRoZSBXRyB3YXMgZ2V0dGluZyByZWFkeSB0byBzZW5kIHJmYzYxMjZiaXMgZm9yIElF VEYgTGFzdCBDYWxsLg0KSSB3YXMganVzdCBhYm91dCB0byBzdGFydCBhIHNjb3JjaGVkIEVhcnRo IC8gbm8taG9sZHMtYmFycmVkIHdhciB0byBnZXQgdGhlIA0KWUFORyBkZWxpdmVyYWJsZSB0YWtl biBvdXQgb2YgdGhlIGNoYXJ0ZXIgKGl0IHdhcyBpbmNsdWRlZCB1bmRlciBkdXJlc3MpDQpiZWNh dXNlIHdlIGhhZCBuby1vbmUgd2l0aCB0aGUgaW50ZXJlc3Qgb3IgY29tcGV0ZW5jeSB0byB3cml0 ZSBhIFlBTkcgRE0uIA0KTWFoZXNoIGlzIGEgaGVyby4g8J+Yig0K From nobody Fri Nov 6 16:14:54 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191963A0420 for ; Fri, 6 Nov 2020 16:14:53 -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 nKy8SNK4sgBT for ; Fri, 6 Nov 2020 16:14:51 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 19EC53A0418 for ; Fri, 6 Nov 2020 16:14:51 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id p15so3299486ljj.8 for ; Fri, 06 Nov 2020 16:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i+ciIg7eVnFimwhJtxzMgY9DDM5bW2vnr1tqRlrCtko=; b=uFVtIVWo7XdmdNI8IpwKfDBOS4tiO1WHhlY5mzSuWqezcK56etBwmNZyAbSzETnCO2 LbPpBs0jx3/7sUImmg2O8HXgGAtxqTJky1e0gqfW4bLvjIFVncMx8ynMPJCkHcwyIwUP /Tx+ONxckbxTm250D2cAXl7rUQIp1P5knH31KPfKbcSXZkaaEh/CSaULsRECp8S1oceO 1spkrZx7GyrWm7tygcncSvhh+5gCHRq4PILt+qd4q9CojEKpw/hb8B2dnQfy7tumoo91 axElDBSOHBHCpZkROuvR86k+Mf9CgNX6/hijaEYAJfKm0v1+42glegGMzcBeKGgPHQCS /Mgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i+ciIg7eVnFimwhJtxzMgY9DDM5bW2vnr1tqRlrCtko=; b=KyQ81+bWL8tF4czRywMOuQAJ7pDRtjU4PneUrTfYRDgkLD82v/iYN5hymaiA1dH9tv 7EPJjQzK3r20k5KEViXAyYqAcwNGv+n9g/Stifi5xbzNOXAmXKs/0lFZvjVLbWoZjOVv INgdev7r0rI5JePsA6lDYe0mbHjBrPn+OaZ3DmEYtBP1QCoyCcEZlxUio6apGsLzcCwY rgjhjJICsXnzSWWfhB620o2CwFU09v8JINwB934naqw0OooNbCCJyA+XCBOl9s6PtKss n6zgLIisORbM9a4YZqW2KO0A/A5roEumjjEPTJOURYieMZAu5pBVaDtyw3UP8Rusf6qE g0Mw== X-Gm-Message-State: AOAM531zmAV23lC9GNmvVUuTmgf+Edad5wXqbBTXL4h6bJaVAN1DK90g wa8SKw4YJh3IEuuzT4tKYudZcKDgEyrl2SQeNZg= X-Google-Smtp-Source: ABdhPJzJ7niu1p096eYhxLl1FAwRsy2ABN2Z9CLJyeHKP/NM+rgD/gWEmzURPj8bHtkknKjFx7EWhKeznPkRyTQv6SE= X-Received: by 2002:a2e:9188:: with SMTP id f8mr1694558ljg.333.1604708089075; Fri, 06 Nov 2020 16:14:49 -0800 (PST) MIME-Version: 1.0 References: <87h7q2f6a2.fsf@toke.dk> In-Reply-To: From: David Schinazi Date: Fri, 6 Nov 2020 16:14:38 -0800 Message-ID: To: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Juliusz Chroboczek , Babel at IETF , Donald Eastlake , Valery Smyslov , Barbara Stark Content-Type: multipart/alternative; boundary="0000000000009e1a5305b3793790" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 00:14:53 -0000 --0000000000009e1a5305b3793790 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Random thought: the draft mentions that the MAC algorithm is configured alongside the key for it. Perhaps we should add an explicit sentence such as "For MAC algorithms that support multiple digest sizes (such as BLAKE2s), the digest size needs to be communicated alongside the MAC algorithm.". I agree that the "SHOULD implement BLAKE2s" should mention a key length, but I have no preference between: - SHOULD implement BLAKE2s with 16-octet hashes - SHOULD implement BLAKE2s with 32-octet hashes - SHOULD implement BLAKE2s with both 16 and 32-octet hashes David On Fri, Nov 6, 2020 at 3:09 PM Antonin D=C3=A9cimo wrote: > > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any siz= e > > > between 1 and 32 octets (8 and 256 bits). However, both > implementations > > > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. > > > > Okay, something seemed off about this when I read it just now, so I jus= t > > double checked: And in fact both implementations use 32-byte Blake2s > > digest sizes... > > That also seemed off to me. To be fair regarding babeld, the "old" > hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2=80= =99re > using the reference blake2s implementation, and I changed 16 to the > provided BLAKE2S_OUTBYTES =3D 32 constant. > > > I still support making the change and specifying the size, but to > > correspond to current implementation practice the change would need to > > be "with 256-bit (32 octet) hashes". > > Me too. I an exchange earlier this year, Donald and Juliusz explained > to me that the size of the output hash is considered part of the > hashing algorithm, so yes, I support making that explicit for blake2s. > > > -- Antonin > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --0000000000009e1a5305b3793790 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Random thought: the draft mentions that the MAC algorithm<= div>is configured alongside the key for it. Perhaps we should
add= an explicit sentence such as "For MAC algorithms that
suppo= rt multiple digest sizes (such as BLAKE2s), the digest
size needs= to be communicated alongside the MAC algorithm.".

I agree that the "SHOULD implement BLAKE2s" should
mention a key length, but I have no preference between:
- SHOUL= D implement=C2=A0BLAKE2s with 16-octet hashes
- SHOULD implement= =C2=A0BLAKE2s with 32-octet hashes
- SHOULD implement=C2=A0BL= AKE2s with both 16 and 32-octet hashes

David

On Fri, Nov 6, 2020 at 3:09 PM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
> > As Valery Smy= slov noted, BLAKE2s is able to produce hashes of any size
> > between 1 and 32 octets (8 and 256 bits).=C2=A0 However, both imp= lementations
> > of Babel-MAC only ever produce 16-octet BLAKE2s hashes.
>
> Okay, something seemed off about this when I read it just now, so I ju= st
> double checked: And in fact both implementations use 32-byte Blake2s > digest sizes...

That also seemed off to me. To be fair regarding babeld, the "old"= ;
hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2=80= =99re
using the reference blake2s implementation, and I changed 16 to the
provided BLAKE2S_OUTBYTES =3D 32 constant.

> I still support making the change and specifying the size, but to
> correspond to current implementation practice the change would need to=
> be "with 256-bit (32 octet) hashes".

Me too. I an exchange earlier this year, Donald and Juliusz explained
to me that the size of the output hash is considered part of the
hashing algorithm, so yes, I support making that explicit for blake2s.


-- Antonin

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--0000000000009e1a5305b3793790-- From nobody Fri Nov 6 17:53:07 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A16D3A0EC6 for ; Fri, 6 Nov 2020 17:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, 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 VCSILz2-oCek for ; Fri, 6 Nov 2020 17:53:04 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 717DB3A0EC7 for ; Fri, 6 Nov 2020 17:53:04 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id o11so3408913ioo.11 for ; Fri, 06 Nov 2020 17:53:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hq03YuQLWRl1Wq/IeIE8kuyHdpbPOTDArdYRLiY9O9M=; b=K7Wb5knRnzNBmu8Su5X47DPdV2wHnEbaIdEDdDVLT/KBsd1WacFDJrxKh/iOjjGjmE MvKwDYKJ/5D7LCSYNuPjn3QeNFrjCSb9LvLq3np8eNJlSQk1Wn+nZrRmoj2UXfH14ldo SqDt9ft7I2wCq1Rw8+1VABFe0v6a9Fo+aY8UMJ/vNtx8qkR0Jr2Q3NHwq+N+zw0qL+Es z3SRSzn1S+mHOVhXiSXfAD/yOr+vOHKqpwVweDpkMvP2/7BNx5pDjsPkvNUKyEhiLYEm Oo6LXLVdBGV3cxyGiVW1YzYB+UVUAV1U10HlXgC6kNzzk7KagcygbA3Z8maHNTixIjCf EC1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hq03YuQLWRl1Wq/IeIE8kuyHdpbPOTDArdYRLiY9O9M=; b=leNSFTmx+TLlkboS5eCiPBOEPjtvh+GcFMNSehlRd1sXrqHtId5HPqTushhRU+DIES IiMi3WJoLw191Qhwu2Gca6TpjwRqsODSdyaF197o5BioUwA278n7cddP/bC+Q0LDuL6q uZMJorM5sxbEMWzDAv2zYXAVvIM2jUjiqZJahgPeP4TagmiwqBe2mBPHcHTuvffpKtYp XHffbhhyLS/Tx2NNcuWhmLVhoBCLugOO2qfKnPQLYrST3RB9BGEScjn2/Mf6WVHlEuqW 0cbLgdrc3wgmqPGusIp71OkM+8pfKysxEqQKCgt8HRhri9E0qmI4md4RaR/9ugRtpQTG W0NQ== X-Gm-Message-State: AOAM532DUbWACkKJA5cjMo6jbUvnxEcO8QhOtpcIoaxi7/hTYGmk3W0P xYYPkl9xxM761u5NAlBAUcMLyB/FzFa5FHM0M5I= X-Google-Smtp-Source: ABdhPJw2nIcORq4QCgkjnKdYRdaZDK7UUio/r+Xm8LjwZnhi2VofYEAZl2q97Up40RyAbKGTZmf/d4pse/prlCqSw0Q= X-Received: by 2002:a02:b06:: with SMTP id 6mr4157354jad.115.1604713983458; Fri, 06 Nov 2020 17:53:03 -0800 (PST) MIME-Version: 1.0 References: <87h7q2f6a2.fsf@toke.dk> In-Reply-To: From: Donald Eastlake Date: Fri, 6 Nov 2020 20:52:52 -0500 Message-ID: To: David Schinazi Cc: =?UTF-8?Q?Antonin_D=C3=A9cimo?= , =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Juliusz Chroboczek , Babel at IETF , Valery Smyslov , Barbara Stark Content-Type: multipart/alternative; boundary="000000000000f3417305b37a96f5" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 01:53:06 -0000 --000000000000f3417305b37a96f5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I guess AUTH48 is probably the right time to do this. Speaking as a WG member, although my opinion is not very strong, I would suggest - SHOULD implement BLAKE2s with 32-octet hashes Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Fri, Nov 6, 2020 at 7:14 PM David Schinazi wrote: > Random thought: the draft mentions that the MAC algorithm > is configured alongside the key for it. Perhaps we should > add an explicit sentence such as "For MAC algorithms that > support multiple digest sizes (such as BLAKE2s), the digest > size needs to be communicated alongside the MAC algorithm.". > > I agree that the "SHOULD implement BLAKE2s" should > mention a key length, but I have no preference between: > - SHOULD implement BLAKE2s with 16-octet hashes > - SHOULD implement BLAKE2s with 32-octet hashes > - SHOULD implement BLAKE2s with both 16 and 32-octet hashes > > David > > On Fri, Nov 6, 2020 at 3:09 PM Antonin D=C3=A9cimo > wrote: > >> > > As Valery Smyslov noted, BLAKE2s is able to produce hashes of any si= ze >> > > between 1 and 32 octets (8 and 256 bits). However, both >> implementations >> > > of Babel-MAC only ever produce 16-octet BLAKE2s hashes. >> > >> > Okay, something seemed off about this when I read it just now, so I ju= st >> > double checked: And in fact both implementations use 32-byte Blake2s >> > digest sizes... >> >> That also seemed off to me. To be fair regarding babeld, the "old" >> hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2= =80=99re >> using the reference blake2s implementation, and I changed 16 to the >> provided BLAKE2S_OUTBYTES =3D 32 constant. >> >> > I still support making the change and specifying the size, but to >> > correspond to current implementation practice the change would need to >> > be "with 256-bit (32 octet) hashes". >> >> Me too. I an exchange earlier this year, Donald and Juliusz explained >> to me that the size of the output hash is considered part of the >> hashing algorithm, so yes, I support making that explicit for blake2s. >> >> >> -- Antonin >> >> _______________________________________________ >> babel mailing list >> babel@ietf.org >> https://www.ietf.org/mailman/listinfo/babel >> > --000000000000f3417305b37a96f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess AUTH48 is probably the right time to do this.
=
Speaking as a WG member, although my opinion is not very str= ong, I would suggest
=C2=A0- SHOULD implement=C2=A0BLAKE2s with 3= 2-octet hashes

Thanks,
Donald
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2= =A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.com


On Fri, Nov 6, 2020 at 7:14 PM David Schinazi <dschinazi.ietf@gmail.com> wrote:
Random = thought: the draft mentions that the MAC algorithm
is configured alongs= ide the key for it. Perhaps we should
add an explicit sentence su= ch as "For MAC algorithms that
support multiple digest sizes= (such as BLAKE2s), the digest
size needs to be communicated alon= gside the MAC algorithm.".

I agree that the &= quot;SHOULD implement BLAKE2s" should
mention a key length, = but I have no preference between:
- SHOULD implement=C2=A0BLAKE2s= with 16-octet hashes
- SHOULD implement=C2=A0BLAKE2s with 32-oct= et hashes
- SHOULD implement=C2=A0BLAKE2s with both 16 and 32= -octet hashes

David

On Fri, Nov 6, 2020 = at 3:09 PM Antonin D=C3=A9cimo <antonin.decimo@gmail.com> wrote:
> > As Valery Smyslov n= oted, BLAKE2s is able to produce hashes of any size
> > between 1 and 32 octets (8 and 256 bits).=C2=A0 However, both imp= lementations
> > of Babel-MAC only ever produce 16-octet BLAKE2s hashes.
>
> Okay, something seemed off about this when I read it just now, so I ju= st
> double checked: And in fact both implementations use 32-byte Blake2s > digest sizes...

That also seemed off to me. To be fair regarding babeld, the "old"= ;
hmac branch used 16-bytes blake2s, and my rewrite uses 32-bytes. We=E2=80= =99re
using the reference blake2s implementation, and I changed 16 to the
provided BLAKE2S_OUTBYTES =3D 32 constant.

> I still support making the change and specifying the size, but to
> correspond to current implementation practice the change would need to=
> be "with 256-bit (32 octet) hashes".

Me too. I an exchange earlier this year, Donald and Juliusz explained
to me that the size of the output hash is considered part of the
hashing algorithm, so yes, I support making that explicit for blake2s.


-- Antonin

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000f3417305b37a96f5-- From nobody Sun Nov 15 09:55:12 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719CB3A011B for ; Sun, 15 Nov 2020 09:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 SSJBvFUeVzCI for ; Sun, 15 Nov 2020 09:55:08 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 4E2333A010D for ; Sun, 15 Nov 2020 09:55:07 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0AFHt4iE014355; Sun, 15 Nov 2020 18:55:05 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id D4491B515E; Sun, 15 Nov 2020 18:55:04 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id flXPbd3l1Sb6; Sun, 15 Nov 2020 18:55:03 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 05DE5B515B; Sun, 15 Nov 2020 18:55:00 +0100 (CET) Date: Sun, 15 Nov 2020 18:54:56 +0100 Message-ID: <87o8jya4jz.wl-jch@irif.fr> From: Juliusz Chroboczek To: babel@ietf.org Cc: Valery Smyslov In-Reply-To: <87h7q2f6a2.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 15 Nov 2020 18:55:05 +0100 (CET) X-Miltered: at korolev with ID 5FB16B78.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FB16B78.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FB16B78.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 17:55:10 -0000 After reading your replies, and thinking it over carefully, I disagree with the apparent consensus. I think Blake2s in Babel-MAC should use 128-bit keys, as in the initial implementation. Please hear me out. Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two reasons: - it is more computationally lightweight on platforms that don't implement SHA-256 in hardware; - it may serve as a fallback if SHA2 is ever broken. While I am still not quite convinced by these arguments, I've agreed to add the SHOULD Blake2s and to implement Blake2s for the following reasons: - it serves as a good example of adding a new algorithm to Babel-MAC; - with 128-bit signatures, it is useful on low-rate networks, which Babel is commonly used with. For these reasons, we implemented Blake2s with 128-bit signatures. Unfortunately, some confusion ensued, Toke implemented Blake2s with 256-bit signatures, Antonin changed our implementation to interoperate with Toke's (without discussing the issue with me beforehand), hence the current situation. If Blake2s uses 256-bit signatures, then I see little convincing reason to keep it around in addition to SHA-256. For this reason, I recommend the following course of action: 1. Toke agrees to switch to 128-bit Blake2s signatures; 2. we discard Antonin's branch (which is just a private branch), and do 128-bit Blake2s signatures instead; 3. during AUTH48, I make the clarification that the SHOULD implement applies to 128-bit signatures. Two more points. First, under no circumstances will I go against WG consensus on this point -- if the WG strongly believes that the SHOULD applies to 256-bit signatures, I will naturally follow the consensus. Second, Babel-HMAC is an extensible protocol, so even if the RFC ends up recommending n-bit signatures, nothing prevents a given implementation from implementing m-bit signatures in addition to the RFC-recommended n-bit signatures. Sorry again for the confusion. -- Juliusz From nobody Sun Nov 15 20:28:40 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBF3A1060 for ; Sun, 15 Nov 2020 20:28:39 -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 RDN82J5gaVch for ; Sun, 15 Nov 2020 20:28:38 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 D84493A129D for ; Sun, 15 Nov 2020 20:28:37 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id k1so13882318ilc.10 for ; Sun, 15 Nov 2020 20:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=05HQfDCdw1U2kM3A4Vf1EDSl+eqdGQrOvGgmeHJIUD8=; b=SfVj+628vzNEMtuF8KzvBJ8rveHVSJjlRt6bzIHTAX6Jr5xDem/BY77dtzQH8fSHLK Ocka/xwLu32jij43nb4Jgqkp0Pv6r2MYW2HsKzfrfr8COFvSxWcIAu5E62t5uWgHPbGo wbnhe4/GI4JOStGsR3bOdITx7q6g9USXDpQiFmV+MQ1qIEZMRw7YAbCGlGHYcXnJFhZq gsSsE3EGoPAGDCEozTpQ5iMx10xX2iYjQdORYvj1bWcL2E6oaYOH6JE+oEzb/QA9OYP4 aMlQCi0xKVf6N6GueuI2kMTYlDkjdTRKPaH/2uynzy9/Q8DEEduWRQKu0mso3HyXQRaI OE2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=05HQfDCdw1U2kM3A4Vf1EDSl+eqdGQrOvGgmeHJIUD8=; b=p0eVGPwgMxsNHW98WrV2Q2jNvDBj4Tom4w2z762e7UorHJZGJidTcvWR1kQj+G+8iT FfA367PqwRQ10dFKf6+ou56+n6DL/ajBMAvvcQpo4PfycZAGvsKWm1vvCqqbT2QqvXbx CPkULeB+K3BP/dm7LMcOWr2cg/muQ5RnzUIetMyyc5WfTjndL4/MGoB1IJCyxjQOi/q7 lWmSpPb9hDgm6HrcEccL2wCFwFV+iEkJj5slH1wFodx5doIsHrZKkrmkiW8CKP3wOPc3 HWvVkGlJiWMAD/6p6Cxopix4K0E7aAJQEapTtmGONo2ZWtBK/qiV3BLGp0fsDgqKpjLK RGow== X-Gm-Message-State: AOAM5338blsZ6aFF5cKfz8zlgHO5G1/bwxdTHfrXvyhuMBIRhZ4da+GG vYZ5SG+GF4bBNmeOG6sxjwDm10dtOwYM6ry1P+eA6+OhlNo= X-Google-Smtp-Source: ABdhPJzADC6Pgoj0d4Ep0t1N6Pi/Dl7dyqmFZ942ospyOlxhC+Ign8WZRHwSPt/Yana0pm/dIFFecBFA3Hl77Bveec0= X-Received: by 2002:a92:d78b:: with SMTP id d11mr4868107iln.40.1605500917061; Sun, 15 Nov 2020 20:28:37 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> In-Reply-To: <87o8jya4jz.wl-jch@irif.fr> From: Donald Eastlake Date: Sun, 15 Nov 2020 23:28:25 -0500 Message-ID: To: Juliusz Chroboczek Cc: Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 04:28:40 -0000 H Juliusz, Speaking as a WG participant, I think your argument make sense and I would supporting going in the direction you suggest. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Sun, Nov 15, 2020 at 12:55 PM Juliusz Chroboczek wrote: > > After reading your replies, and thinking it over carefully, I disagree > with the apparent consensus. I think Blake2s in Babel-MAC should use > 128-bit keys, as in the initial implementation. Please hear me out. > > Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two > reasons: > > - it is more computationally lightweight on platforms that don't > implement SHA-256 in hardware; > - it may serve as a fallback if SHA2 is ever broken. > > While I am still not quite convinced by these arguments, I've agreed to > add the SHOULD Blake2s and to implement Blake2s for the following reasons: > > - it serves as a good example of adding a new algorithm to Babel-MAC; > - with 128-bit signatures, it is useful on low-rate networks, which > Babel is commonly used with. > > For these reasons, we implemented Blake2s with 128-bit signatures. > Unfortunately, some confusion ensued, Toke implemented Blake2s with > 256-bit signatures, Antonin changed our implementation to interoperate > with Toke's (without discussing the issue with me beforehand), hence the > current situation. > > If Blake2s uses 256-bit signatures, then I see little convincing reason to > keep it around in addition to SHA-256. For this reason, I recommend the > following course of action: > > 1. Toke agrees to switch to 128-bit Blake2s signatures; > 2. we discard Antonin's branch (which is just a private branch), and do > 128-bit Blake2s signatures instead; > 3. during AUTH48, I make the clarification that the SHOULD implement > applies to 128-bit signatures. > > Two more points. First, under no circumstances will I go against WG > consensus on this point -- if the WG strongly believes that the SHOULD > applies to 256-bit signatures, I will naturally follow the consensus. > Second, Babel-HMAC is an extensible protocol, so even if the RFC ends up > recommending n-bit signatures, nothing prevents a given implementation > from implementing m-bit signatures in addition to the RFC-recommended > n-bit signatures. > > Sorry again for the confusion. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel From nobody Mon Nov 16 03:52:47 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6855F3A0D69 for ; Mon, 16 Nov 2020 03:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qPoIrKr_PYSE for ; Mon, 16 Nov 2020 03:52:44 -0800 (PST) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 58AF53A0D65 for ; Mon, 16 Nov 2020 03:52:44 -0800 (PST) Received: by mail-wr1-x430.google.com with SMTP id m6so1196085wrg.7 for ; Mon, 16 Nov 2020 03:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=//gzltKJmWyz7kPz4lzwIi8qh2qAxFFPziKIu5sHSw4=; b=u/eR2TjOjWcPSRoWeuZTc2+1BMSRSvl5S9UeIC5TuNVKkE+S38fKEEUsj1+GZmD6M2 Ay0aoVavkJn8m40YIc4u+zoRjDbybX0v5WVLHObZLthrlmyK0/mP3G+BCzO+J9CG/rQx vPRB/1o6CYNKuqWjAT6aD/6jXkF53jxn95LgnuvCz9YcW4GvWuc1T7/w48DUJT8xBrbu EVpQyYEcA6lAu04d6245V2cP4IyuC3ek/B4i+NpOGkdEFRNpW5GzCp7CZzkxEg15Hp21 lBTVOdFkVL89eUlhMXfvGq4wltdvPp3Dh8zQY7jqKokqEEDfO1eMViVhE8Hgk0ZpL5Zc +VZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=//gzltKJmWyz7kPz4lzwIi8qh2qAxFFPziKIu5sHSw4=; b=OXqUVNjOuSD+Xq7tr31m1zQPFF94HaibaFID/q75pnTsc0uPW6yzUsh8lXfj/ghdTs 3ZcApJrimd95tsR7j99ponCJhIml1DcOXTyCdwd6TzRRSE1g9d5QulTd1eRXkr2cZJCS itNH2SasRmX70s8q6J4cnHAAaKBS5yACU/5sN/C7t/v8+sdn5r73B5DItm8GFRTq5og5 yq+e33JyD1IpIOHpuOi/wTPD9e8LNg1VuSqAJQ6jI9mPZpdFq5PKeYd3oU0P/BwX1hsC sAROmNft9/BMrbipP0P1Z/hU7URoSilVqqPjkELXYJMPnHbXUPYguvqOZzPf2aC3mXVm 6j7Q== X-Gm-Message-State: AOAM533n4CSsEwMJRnLcvof+UpHBriXdJyVCCu+ZTaa46ikyI18gihF9 wMYjyQi/tsOk8CQKklFQ2D4k2Oe1Bwt2k913C/gnmQ== X-Google-Smtp-Source: ABdhPJyv5mqhM+tY44coKTdWrBe8KWGYJOqA5o+K9DigzQnvO4oQpPtz+NJ2rKdEsBNTSc25cKL2OC9p1hQ30DqRNMo= X-Received: by 2002:a5d:448a:: with SMTP id j10mr18054159wrq.33.1605527562407; Mon, 16 Nov 2020 03:52:42 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> In-Reply-To: From: Gabriel Kerneis Date: Mon, 16 Nov 2020 12:52:06 +0100 Message-ID: To: Donald Eastlake Cc: Juliusz Chroboczek , Babel at IETF Content-Type: multipart/alternative; boundary="000000000000092cf905b4380427" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 11:52:46 -0000 --000000000000092cf905b4380427 Content-Type: text/plain; charset="UTF-8" I'm sorry I didn't reply earlier on this thread. Even before Juliusz' email, the consensus seemed odd to me, for the reasons he outlined and I intended to raise this up. Note that I have not taken part in any implementation Babel, and I am basing my opinion purely on the facts laid out in this thread. I think blake2s should use 128-bit signatures. Gabriel Kerneis On Mon, Nov 16, 2020 at 5:28 AM Donald Eastlake wrote: > H Juliusz, > > Speaking as a WG participant, I think your argument make sense and I > would supporting going in the direction you suggest. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > > On Sun, Nov 15, 2020 at 12:55 PM Juliusz Chroboczek wrote: > > > > After reading your replies, and thinking it over carefully, I disagree > > with the apparent consensus. I think Blake2s in Babel-MAC should use > > 128-bit keys, as in the initial implementation. Please hear me out. > > > > Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two > > reasons: > > > > - it is more computationally lightweight on platforms that don't > > implement SHA-256 in hardware; > > - it may serve as a fallback if SHA2 is ever broken. > > > > While I am still not quite convinced by these arguments, I've agreed to > > add the SHOULD Blake2s and to implement Blake2s for the following > reasons: > > > > - it serves as a good example of adding a new algorithm to Babel-MAC; > > - with 128-bit signatures, it is useful on low-rate networks, which > > Babel is commonly used with. > > > > For these reasons, we implemented Blake2s with 128-bit signatures. > > Unfortunately, some confusion ensued, Toke implemented Blake2s with > > 256-bit signatures, Antonin changed our implementation to interoperate > > with Toke's (without discussing the issue with me beforehand), hence the > > current situation. > > > > If Blake2s uses 256-bit signatures, then I see little convincing reason > to > > keep it around in addition to SHA-256. For this reason, I recommend the > > following course of action: > > > > 1. Toke agrees to switch to 128-bit Blake2s signatures; > > 2. we discard Antonin's branch (which is just a private branch), and do > > 128-bit Blake2s signatures instead; > > 3. during AUTH48, I make the clarification that the SHOULD implement > > applies to 128-bit signatures. > > > > Two more points. First, under no circumstances will I go against WG > > consensus on this point -- if the WG strongly believes that the SHOULD > > applies to 256-bit signatures, I will naturally follow the consensus. > > Second, Babel-HMAC is an extensible protocol, so even if the RFC ends up > > recommending n-bit signatures, nothing prevents a given implementation > > from implementing m-bit signatures in addition to the RFC-recommended > > n-bit signatures. > > > > Sorry again for the confusion. > > > > -- Juliusz > > > > _______________________________________________ > > babel mailing list > > babel@ietf.org > > https://www.ietf.org/mailman/listinfo/babel > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --000000000000092cf905b4380427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm sorry I didn't reply earlier on this thread. E= ven before Juliusz' email, the consensus seemed odd to me, for the reas= ons he outlined and I intended to raise this up. Note that I have not taken= part in any implementation Babel, and I am basing my opinion purely on the= facts laid out in this thread. I think blake2s should use 128-bit signatur= es.

Gabriel Kerneis


On Mon, Nov 16, 2020 at 5:28 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
H Juliusz,

Speaking as a WG participant, I think your argument make sense and I
would supporting going in the direction you suggest.

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlake 3rd=C2=A0 =C2=A0+1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka, FL 32703 USA
=C2=A0d3e3e3@gmail.co= m

On Sun, Nov 15, 2020 at 12:55 PM Juliusz Chroboczek <jch@irif.fr> wrote:
>
> After reading your replies, and thinking it over carefully, I disagree=
> with the apparent consensus.=C2=A0 I think Blake2s in Babel-MAC should= use
> 128-bit keys, as in the initial implementation.=C2=A0 Please hear me o= ut.
>
> Toke and Dave originally suggested adding Blake2s to Babel-HMAC for tw= o
> reasons:
>
>=C2=A0 =C2=A0- it is more computationally lightweight on platforms that= don't
>=C2=A0 =C2=A0 =C2=A0implement SHA-256 in hardware;
>=C2=A0 =C2=A0- it may serve as a fallback if SHA2 is ever broken.
>
> While I am still not quite convinced by these arguments, I've agre= ed to
> add the SHOULD Blake2s and to implement Blake2s for the following reas= ons:
>
>=C2=A0 =C2=A0- it serves as a good example of adding a new algorithm to= Babel-MAC;
>=C2=A0 =C2=A0- with 128-bit signatures, it is useful on low-rate networ= ks, which
>=C2=A0 =C2=A0 =C2=A0Babel is commonly used with.
>
> For these reasons, we implemented Blake2s with 128-bit signatures.
> Unfortunately, some confusion ensued, Toke implemented Blake2s with > 256-bit signatures, Antonin changed our implementation to interoperate=
> with Toke's (without discussing the issue with me beforehand), hen= ce the
> current situation.
>
> If Blake2s uses 256-bit signatures, then I see little convincing reaso= n to
> keep it around in addition to SHA-256.=C2=A0 For this reason, I recomm= end the
> following course of action:
>
>=C2=A0 =C2=A01. Toke agrees to switch to 128-bit Blake2s signatures; >=C2=A0 =C2=A02. we discard Antonin's branch (which is just a privat= e branch), and do
>=C2=A0 =C2=A0 =C2=A0 128-bit Blake2s signatures instead;
>=C2=A0 =C2=A03. during AUTH48, I make the clarification that the SHOULD= implement
>=C2=A0 =C2=A0 =C2=A0 applies to 128-bit signatures.
>
> Two more points.=C2=A0 First, under no circumstances will I go against= WG
> consensus on this point -- if the WG strongly believes that the SHOULD=
> applies to 256-bit signatures, I will naturally follow the consensus.<= br> > Second, Babel-HMAC is an extensible protocol, so even if the RFC ends = up
> recommending n-bit signatures, nothing prevents a given implementation=
> from implementing m-bit signatures in addition to the RFC-recommended<= br> > n-bit signatures.
>
> Sorry again for the confusion.
>
> -- Juliusz
>
> _______________________________________________
> babel mailing list
> babel@ietf.org=
> https://www.ietf.org/mailman/listinfo/babel

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--000000000000092cf905b4380427-- From nobody Mon Nov 16 05:13:14 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DBE3A0E9D for ; Mon, 16 Nov 2020 05:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 pO5LxN-ja-FC for ; Mon, 16 Nov 2020 05:13:11 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 CE0523A0E2D for ; Mon, 16 Nov 2020 05:13:10 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0AGDD7En001583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Nov 2020 14:13:07 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 0AGDD7XQ031950; Mon, 16 Nov 2020 14:13:07 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3401FC1798; Mon, 16 Nov 2020 14:13:07 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id YmIZcjEn_eJm; Mon, 16 Nov 2020 14:13:05 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 9961AC1795; Mon, 16 Nov 2020 14:13:05 +0100 (CET) Date: Mon, 16 Nov 2020 14:13:02 +0100 Message-ID: <878sb1wild.wl-jch@irif.fr> From: Juliusz Chroboczek To: Gabriel Kerneis Cc: Babel at IETF In-Reply-To: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Mon, 16 Nov 2020 14:13:07 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Mon, 16 Nov 2020 14:13:07 +0100 (CET) X-Miltered: at korolev with ID 5FB27AE3.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FB27AE3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FB27AE3.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FB27AE3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FB27AE3.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FB27AE3.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 13:13:13 -0000 > Note that I have not taken part in any implementation Babel $ cd /usr/local/src/babel/babeld $ git log | grep -i kerneis | wc -l 10 Gabriel is also the co-author of the integration of babeld into OpenWRT. -- Juliusz From nobody Mon Nov 16 05:51:33 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1753A0FF7 for ; Mon, 16 Nov 2020 05:51:31 -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, 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=toke.dk 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 qm3hOw6MZPxb for ; Mon, 16 Nov 2020 05:51:29 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 6C1FA3A0FF2 for ; Mon, 16 Nov 2020 05:51:28 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1605534685; bh=7xc9YXg8dW1+4ss8GzTF+XVioePh254ADlFXs7qGTJE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=xGmWwuN0T7abWGXn/t7DUqKhScaY06BxwPqKAnnco4lfQGMvy5kXMNYN0U2mbMIry G1tdn6mQeye7CzrEZpqtE/hdZQpD4C91rI1iUwAumeBE1RlLF2Cxm3mysSwepp/sJt 0o5w29/nenz+hb7FQKOWFiBB9QAb4LJuyT+VRTrrVTO3JCUUneoSpgsE4Oe5B/6Nki 9ehuwLGy72g3/xeRkqxJGowCyBd7FTGEceL+J5h2ow1Srkk9MPn3rRiJmkdFv4I7z/ TvDxh2hvjVaQaojdBjVLDMhculADzunHn6++ESbrnfRSEV32+4LMLEA/fyKtW0/mRh ReX6MJMnr2J1g== To: Juliusz Chroboczek , babel@ietf.org Cc: Valery Smyslov In-Reply-To: <87o8jya4jz.wl-jch@irif.fr> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> Date: Mon, 16 Nov 2020 14:51:25 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87wnyl4dgi.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 13:51:32 -0000 Juliusz Chroboczek writes: > After reading your replies, and thinking it over carefully, I disagree > with the apparent consensus. I think Blake2s in Babel-MAC should use > 128-bit keys, as in the initial implementation. Please hear me out. > > Toke and Dave originally suggested adding Blake2s to Babel-HMAC for two > reasons: > > - it is more computationally lightweight on platforms that don't > implement SHA-256 in hardware; > - it may serve as a fallback if SHA2 is ever broken. > > While I am still not quite convinced by these arguments, I've agreed to > add the SHOULD Blake2s and to implement Blake2s for the following reasons: > > - it serves as a good example of adding a new algorithm to Babel-MAC; > - with 128-bit signatures, it is useful on low-rate networks, which > Babel is commonly used with. > > For these reasons, we implemented Blake2s with 128-bit signatures. > Unfortunately, some confusion ensued, Toke implemented Blake2s with > 256-bit signatures, Antonin changed our implementation to interoperate > with Toke's (without discussing the issue with me beforehand), hence the > current situation. Note sure that I quite agree with your history here, but that doesn't really matter; I'm not actually opposed to 128-bit signatures per se, although I would be more comfortable if someone with a crypto background could weigh in with an opinion on this. (Note that the way blake2s implements this is just by truncating the output to whatever size you specify, the rest of the algorithm is exactly the same). > If Blake2s uses 256-bit signatures, then I see little convincing reason to > keep it around in addition to SHA-256. For this reason, I recommend the > following course of action: > > 1. Toke agrees to switch to 128-bit Blake2s signatures; I think what would happen is that Bird would support both. It already supports a whole bunch of other signature schemes (some of which, like MD5, should probably not be used), and my patch adds support for both blake2s and blake2b. I'll think about what the best UI for this is, and ask the Bird devs as well I suppose. -Toke From nobody Tue Nov 17 15:47:29 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6C23A1033 for ; Tue, 17 Nov 2020 15:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 mqjZR67C5K0P for ; Tue, 17 Nov 2020 15:47:26 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 B7DF23A1044 for ; Tue, 17 Nov 2020 15:47:25 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0AHNlNtC014647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Nov 2020 00:47:23 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 0AHNlMts020009; Wed, 18 Nov 2020 00:47:22 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 52BA2EDE2D; Wed, 18 Nov 2020 00:47:22 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id VE1CxoT63Xy7; Wed, 18 Nov 2020 00:47:20 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 84451EDE2B; Wed, 18 Nov 2020 00:47:16 +0100 (CET) Date: Wed, 18 Nov 2020 00:47:13 +0100 Message-ID: <878sazh7ge.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Valery Smyslov In-Reply-To: <87wnyl4dgi.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 18 Nov 2020 00:47:23 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 18 Nov 2020 00:47:23 +0100 (CET) X-Miltered: at korolev with ID 5FB4610B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FB4610A.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FB4610B.001 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FB4610A.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FB4610B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FB4610A.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 23:47:28 -0000 >> Toke and Dave originally suggested adding Blake2s to Babel-HMAC [...] > Note sure that I quite agree with your history here, It's quite likely I got it wrong, sorry if that's the case. > I'm not actually opposed to 128-bit signatures per se, although I would > be more comfortable if someone with a crypto background could weigh in > with an opinion on this. Valery, perhaps you could help? >> 1. Toke agrees to switch to 128-bit Blake2s signatures; > I think what would happen is that Bird would support both. Ok. You didn't address the most important question: do you agree with modifying the RFC-to-be so that the SHOULD applies to 128-bit signatures, and clarifying the information model that the "Blake2s" algorithm implies 128-bit signatures? -- Juliusz From nobody Wed Nov 18 02:57:29 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C763C3A17AC for ; Wed, 18 Nov 2020 02:57:27 -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, 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=toke.dk 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 yNPmZKdENLCs for ; Wed, 18 Nov 2020 02:57:25 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 A8DCA3A17AB for ; Wed, 18 Nov 2020 02:57:24 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1605697041; bh=nBNu4GdvBjY3MUOWHhbXjV2rVR1XuQ8r1a7Z8+W3UFM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XLvLfKzoK53J/gVgX9xvRKC5nWfhqv0e9a9PpngMWErkZNfcNJQvJdPuPxjpcwLcu vTf7Zs9gGU3sjtrWfj8CmqDKG9vp3/z8OAsQhYVUeyYVDMzwA/n4RJIEjX9dNoOAKm GsPXKPWUwpCdDp3t+r+N2Gg3izpTBk5FGAHa/L0u4cpJ7XxDZxtqChCyKtfYRBWLfp 8yqPY+Y3bjsRGiJsmMZnTEoYmQoP8x+Z0F53aNgfyaHzjBN4au+2ML3oh/dJxlc0Bl UuVHog6ZdYFZbXr5C+qLg9Q66mU0LpNPazVTqqpGYLZc33cPBGHT17NulTJd4eEB7N bwvQQu2EwsTHg== To: Juliusz Chroboczek Cc: babel@ietf.org, Valery Smyslov In-Reply-To: <878sazh7ge.wl-jch@irif.fr> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> Date: Wed, 18 Nov 2020 11:57:21 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o8jvylta.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 10:57:28 -0000 Juliusz Chroboczek writes: >>> Toke and Dave originally suggested adding Blake2s to Babel-HMAC [...] > >> Note sure that I quite agree with your history here, > > It's quite likely I got it wrong, sorry if that's the case. > >> I'm not actually opposed to 128-bit signatures per se, although I would >> be more comfortable if someone with a crypto background could weigh in >> with an opinion on this. > > Valery, perhaps you could help? > >>> 1. Toke agrees to switch to 128-bit Blake2s signatures; > >> I think what would happen is that Bird would support both. > > Ok. > > You didn't address the most important question: do you agree with modifying > the RFC-to-be so that the SHOULD applies to 128-bit signatures, and > clarifying the information model that the "Blake2s" algorithm implies > 128-bit signatures? I asked my go-to crypto guy who assured me that 128 bits is sufficient for this use case. So no objections from me :) (He also helpfully pointed out that I was completely wrong to assert that Blake2s just truncates the hash if it's configured for shorter output; so much for my C reading comprehension skills :/) -Toke From nobody Wed Nov 18 04:44:28 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7203A1861 for ; Wed, 18 Nov 2020 04:44:27 -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, 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=smyslov.net 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 xl3m0dlOApSb for ; Wed, 18 Nov 2020 04:44:25 -0800 (PST) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 B185B3A1831 for ; Wed, 18 Nov 2020 04:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RCFTRErtUlSFVjZTjFAHLWO97Iu1aJJp+Vz9/dmMXsM=; b=QFPRlEDFHScOEOFvC3ZE/BOAR+ pcXTURhx+sxaIhNWSGNjhoAVLskIN2X+T6nKfFBLvs/lyhB5L//8Rq8wWcQTE6xNTG6fmm4qNtEtq wr7IAdgLnPm/NoOifbi/az9GqHb62zX+bcQHjAaDcCA6+k0cuwh0Lc5BVoYo0HyHBuyEk7SmWFK8r HF510vv8Qoe8AMLjFKlJE+Xifa08vb2Itawij4SBhDqZ5I7Y+vYXbjhMAxtw3QMjhP/cO7x1wes5D ylS3xonlUcTy6F/LIufBLR5Y+3knkcKeTc6gvDCY/nVY0ld9SNcz8+mdZ3/QtlPY13zcHKd7f5Wbi 67xJNdIQ==; Received: from [93.188.44.203] (port=51715 helo=buildpc) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kfMot-0004jP-Ke; Wed, 18 Nov 2020 07:44:20 -0500 From: "Valery Smyslov" To: "'Juliusz Chroboczek'" , =?iso-8859-1?Q?'Toke_H=F8iland-J=F8rgensen'?= Cc: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> In-Reply-To: <878sazh7ge.wl-jch@irif.fr> Date: Wed, 18 Nov 2020 15:44:18 +0300 Message-ID: <081e01d6bda8$8acc0470$a0640d50$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIBt3/S0skzJeVSyc6nHEpVtErVDwIUTv9yAdDdeJgBRMbiFQKRzd0zqTn78hA= Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2020 12:44:27 -0000 Hi Juliusz, > >> Toke and Dave originally suggested adding Blake2s to Babel-HMAC [...] > > > Note sure that I quite agree with your history here, > > It's quite likely I got it wrong, sorry if that's the case. > > > I'm not actually opposed to 128-bit signatures per se, although I would > > be more comfortable if someone with a crypto background could weigh in > > with an opinion on this. > > Valery, perhaps you could help? I'll try to help, but [full disclaimer] I'm not a cryptographer, just a user of crypto :-) I'm not very familiar with blake2s, but I assume that it's a strong cryptographic MAC function, so the best possible attack is brute force. So 128 bits for MAC size generally looks OK if the key length is also at least 128 bits and has enough entropy. That said, I have two concerns with these figures. First, from my understanding of how MAC is used in babel, it seems that the keys are long lived, so you potentially protect very large number of packets using one key. That gives an attacker much more opportunities to attack algorithm itself. For example, the CFRG has a draft draft-irtf-cfrg-aead-limits discussing limits of data to be safely protected with one key (well it's for AEAD ciphers, but the same concerns applies for any crypto algorithm). I'd feel more comfortable to use longer MACs for long-lived keys, but, on the other hand, from my understanding routing protocols send relatively little data, so probably 128 bits is OK for babel. My second concern is mostly theoretical one for now - it's quantum computers. It is known that for any symmetric crypto quantum computers would reduce the effective key size by half (using Grover's algorithm). I'm not quite sure, but that might apply to forging MACs too (finding second preimage). Anyway, this is my personal opinion and I think that CFRG should be asked if you want to get more authoritative answer. Regards, Valery. > >> 1. Toke agrees to switch to 128-bit Blake2s signatures; > > > I think what would happen is that Bird would support both. > > Ok. > > You didn't address the most important question: do you agree with modifying > the RFC-to-be so that the SHOULD applies to 128-bit signatures, and > clarifying the information model that the "Blake2s" algorithm implies > 128-bit signatures? > > -- Juliusz From nobody Mon Nov 23 02:55:53 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941613A07F4 for ; Mon, 23 Nov 2020 02:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=toke.dk 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 G_2eE58qzBbx for ; Mon, 23 Nov 2020 02:55:43 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 3C4D83A0603 for ; Mon, 23 Nov 2020 02:55:40 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1606128936; bh=XwfE7BK37qFy5PCWr7Sl2DkDvFnbf5DnJJWiR3OjQ18=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bAbzk6+w4a1A0eTaMSkiDQo+xkbtd396Tj8oITR3VWC+Ab8TK9hhm6iktPixOyIef 9GqG3ryzV2QQRW1WzfTVcF6UxQN9Y6/bu//Dol+q3SdVhw0LySnq9JIDkFHk0oSPdo Z+rthBU+tLHD+NVbhGwJJsuB1FCBWNBrDu+SfSSjWWswd1arSh+X1y4z28JJzpkC+4 cQ+Dp4MjFRIWfmG9dlXG/vHecO/Ts+45/crAonZ58iK+9wuhNQiY7pckgrDzhn/dGL sw9ZpP4GnOokA+wtMkD58Q0V5iW2p08ZClLE6ktEvRy4ZX5OIDHedatXypJWYSjNpS f11IjNEfCQ48Q== To: Juliusz Chroboczek Cc: babel@ietf.org, Valery Smyslov In-Reply-To: <87o8jvylta.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> Date: Mon, 23 Nov 2020 11:55:36 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87o8jomjfb.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 10:55:52 -0000 Toke H=C3=B8iland-J=C3=B8rgensen writes: > Juliusz Chroboczek writes: > >>>> Toke and Dave originally suggested adding Blake2s to Babel-HMAC [...] >> >>> Note sure that I quite agree with your history here, >> >> It's quite likely I got it wrong, sorry if that's the case. >> >>> I'm not actually opposed to 128-bit signatures per se, although I would >>> be more comfortable if someone with a crypto background could weigh in >>> with an opinion on this. >> >> Valery, perhaps you could help? >> >>>> 1. Toke agrees to switch to 128-bit Blake2s signatures; >> >>> I think what would happen is that Bird would support both. >> >> Ok. >> >> You didn't address the most important question: do you agree with modify= ing >> the RFC-to-be so that the SHOULD applies to 128-bit signatures, and >> clarifying the information model that the "Blake2s" algorithm implies >> 128-bit signatures? > > I asked my go-to crypto guy who assured me that 128 bits is sufficient > for this use case. So no objections from me :) This does raise one question, though (as I just found out while implementing the option for a 128-bit version): How does this impact the recommendations for key size? I've been restricting the key size to always be equal to the output size, so does this also imply that the key size recommendation should change to 16 bytes? -Toke From nobody Wed Nov 25 10:28:18 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B99BA3A1537 for ; Wed, 25 Nov 2020 10:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Hn261rzwyC1N for ; Wed, 25 Nov 2020 10:28:15 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 C01103A14FF for ; Wed, 25 Nov 2020 10:28:13 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0APISB6t008382; Wed, 25 Nov 2020 19:28:11 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A3FEED5A93; Wed, 25 Nov 2020 19:28:11 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id lTCsTkqKuyJD; Wed, 25 Nov 2020 19:28:10 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id BFE81D5A8F; Wed, 25 Nov 2020 19:28:09 +0100 (CET) Date: Wed, 25 Nov 2020 19:28:03 +0100 Message-ID: <87360xz3yk.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Valery Smyslov In-Reply-To: <87o8jomjfb.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 25 Nov 2020 19:28:11 +0100 (CET) X-Miltered: at korolev with ID 5FBEA23B.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FBEA23B.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FBEA23B.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 18:28:17 -0000 > This does raise one question, though (as I just found out while > implementing the option for a 128-bit version): How does this impact the > recommendations for key size? I suggest that they remain the same (SHOULD be 32 bytes). The digest size impacts the overhead carried by every packet. Not so the key size: increasing the key size is essentially free. As a matter of fact, Blake2s will pad the key with zeroes before it is used. Thus: - allowing shorter keys gains no generality (the user may achieve the same result by padding with zeroes before passing the key to Blake2s); - disallowing shorter keys causes confusion (by using a value different from both HMAC-SHA-256 and the Blake2s maximum), and has no measurable benefits. I do not believe that it impacts the security in any way (2^128 ns is roughly 10^12 times the age of the universe), but I could be wrong. -- Juliusz From nobody Thu Nov 26 02:26:40 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6533A1057 for ; Thu, 26 Nov 2020 02:26:38 -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, 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=toke.dk 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 iAmgJTW-9O-Y for ; Thu, 26 Nov 2020 02:26:35 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 75ECB3A1056 for ; Thu, 26 Nov 2020 02:26:34 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1606386390; bh=FMR9ggIpLibq0s3Sga0I2Az8QyJlRKczWdR5lFkXKaI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=W+O9zbR/sZF8vrrLz1weat3Izc3pBnnDnp0OSRpwO4407BoK+/PJj1Mal6Mbi7ecT 2mLh4TXowefKlefoHaAHm+EfW7864KKgPIgBkP57d+5AHzHG9UTcwjXVbHdGaxe9Dt acchUJkyHxpdARQxcLXqIUGXgD5UVv5oboJqgrGubhdQAwp9UX87HKN3iC1EwY/gQI nASyR+gi5sn6m5XzJJIUb9DDj5+cq/eqm3wkvdHMxOieLTLOUS8/umYXGMuH6NwBbB 6F2XWfvGeyhLH/XY0XEQga0ZjH48vPi2WUK8gkVPbiHkoycyO1OzsAdnuiEkIMQFHw YI0oejeXNvGOg== To: Juliusz Chroboczek Cc: babel@ietf.org, Valery Smyslov In-Reply-To: <87360xz3yk.wl-jch@irif.fr> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> Date: Thu, 26 Nov 2020 11:26:29 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87ft4wl8h6.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 10:26:38 -0000 Juliusz Chroboczek writes: >> This does raise one question, though (as I just found out while >> implementing the option for a 128-bit version): How does this impact the >> recommendations for key size? > > I suggest that they remain the same (SHOULD be 32 bytes). > > The digest size impacts the overhead carried by every packet. Not so the > key size: increasing the key size is essentially free. As a matter of > fact, Blake2s will pad the key with zeroes before it is used. > > Thus: > > - allowing shorter keys gains no generality (the user may achieve the > same result by padding with zeroes before passing the key to Blake2s); > > - disallowing shorter keys causes confusion (by using a value different > from both HMAC-SHA-256 and the Blake2s maximum), and has no measurable > benefits. > > I do not believe that it impacts the security in any way (2^128 ns is > roughly 10^12 times the age of the universe), but I could be wrong. Yeah, makes sense, let's keep it at 32 bytes :) -Toke From nobody Thu Nov 26 04:04:56 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521823A0E48; Thu, 26 Nov 2020 04:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 8m4sLacKNnZb; Thu, 26 Nov 2020 04:04:53 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 2F13B3A0E4B; Thu, 26 Nov 2020 04:04:52 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0AQC4poe029059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Nov 2020 13:04:51 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 0AQC4pKh019569; Thu, 26 Nov 2020 13:04:51 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 150C1FE01A; Thu, 26 Nov 2020 13:04:51 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Gx4aQh_0Gc_S; Thu, 26 Nov 2020 13:04:48 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 2A426FE014; Thu, 26 Nov 2020 13:04:47 +0100 (CET) Date: Thu, 26 Nov 2020 13:04:40 +0100 Message-ID: <87lfeocoiv.wl-jch@irif.fr> From: Juliusz Chroboczek To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= Cc: babel@ietf.org, Valery Smyslov , babel-chairs@ietf.org In-Reply-To: <87ft4wl8h6.fsf@toke.dk> References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 26 Nov 2020 13:04:51 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 26 Nov 2020 13:04:51 +0100 (CET) X-Miltered: at korolev with ID 5FBF99E3.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FBF99E3.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FBF99E3.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FBF99E3.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FBF99E3.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FBF99E3.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 12:04:55 -0000 >> I do not believe that it impacts the security in any way (2^128 ns is >> roughly 10^12 times the age of the universe), but I could be wrong. > Yeah, makes sense, let's keep it at 32 bytes :) Excellent. I'm therefore going to make the following change in AUTH48: - in Section 4.1, replace Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and MAY implement other MAC algorithms. Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s with 128-bit (16-octet) digests [RFC7693], and MAY implement other MAC algorithms. I will not change the following text in Section 7: Ideally, they should have a length of 32 octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly. Donald, are you willing to call consensus on this point? -- Juliusz From nobody Thu Nov 26 04:25:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525E13A12B9; Thu, 26 Nov 2020 04:25:26 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 cQY5KtaKGOIL; Thu, 26 Nov 2020 04:25:24 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 7FEBC3A12BD; Thu, 26 Nov 2020 04:25:24 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id t143so2068759oif.10; Thu, 26 Nov 2020 04:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/iCGYO9RKXnYgDXT3WqbAMIcqb6xG7QZLNqu/9fuNSQ=; b=kcFLEPZV1VZmfL3A18QbjKbdZCPbPE9xFiTJD8vqQkXRextLjcMla+WWp2aoZwIPkF cW6v92Xc4AS9T8du4JC/D1em2+ztLXsNlQwvFC3UsUc/lkgdAah7p4MEorttDdJFS+EJ Vv92Aq+wOz3psH5R4wqT4q9JbAQT2yuGRqsn6TDRsvfVpwbzN3ra9sav2MmKhwf3s6dl R36g2TytaJG+JfDqjGJXlpxsQMz7xOUJSE0Ms++8UOEEh1Z2veqvDXFwSfHcQaPpYBLk ks9qMKAr1YIcvI9RR0b8kKkay4FXkY5fxmACE6nHRTqmLAu0p6PokEujuXSkDcnfmMKw kdMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/iCGYO9RKXnYgDXT3WqbAMIcqb6xG7QZLNqu/9fuNSQ=; b=gXclhAnAe3Ky5j1WkVeG0A5IcYxMLB2PQ1OF2zgXThwtTrkLBmWjW+936iaFh0sP3C q3dTtgaFDq6tT6/IoA8G9Qi8t6btOBYfCWGzm/N38oupInz3jfk7+CGu9XyVHY4ci7Ym cynQh4a7UEyK9Jw6rHA4H+mocxSiDSsNV0AfUY3NEFiDoeafZMWMLl8uSkEPvKVSlYaF eR6PZrJwW0eWwlm8kQcNFglJ2YhH2Y7vToRDIXqNGwRtn/TMjQqAKBvD7lZ7AlrH2xIG xUjugMQU9G2QjKlWXIFElgYTdFbhcdDH2gtJKZAOK/PWzf7tUFGhX/G+gPDTmsINnOam Aapw== X-Gm-Message-State: AOAM531UqNATZh1TyRVvmsyrpo+hA4H3tvs1uqxHW5rczxW0mfKFhC8K g5NEazuCaZIVvqXV0EMUcuD0TvCrnMiWAhNn8Ts= X-Google-Smtp-Source: ABdhPJwXJHz2C/BPTRLqgwvC71eWtzfwd/ApkSYBkIJmn9ujcRP0/LKNyEuOPpHAzzZkUGmPMTPfhvbnmhN6R8heQjY= X-Received: by 2002:aca:6704:: with SMTP id z4mr1889145oix.97.1606393523671; Thu, 26 Nov 2020 04:25:23 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> <87lfeocoiv.wl-jch@irif.fr> In-Reply-To: <87lfeocoiv.wl-jch@irif.fr> From: =?UTF-8?Q?Antonin_D=C3=A9cimo?= Date: Thu, 26 Nov 2020 13:25:12 +0100 Message-ID: To: Juliusz Chroboczek Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , babel-chairs , Valery Smyslov , Babel at IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 12:25:26 -0000 I support Juliusz' changes, and I have a patch ready ;-) From nobody Thu Nov 26 05:04:20 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5813F3A131F; Thu, 26 Nov 2020 05:04:18 -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, 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=toke.dk 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 XRmuJwfGxd88; Thu, 26 Nov 2020 05:04:16 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 03FDA3A1288; Thu, 26 Nov 2020 05:04:15 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1606395848; bh=Q3waPbZTDOy72aob0wNRZCBebfzxZvohDhOaxojbRfY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=pcidpW31jRSWlZW6UoaursfqyEllMRbe639kqHOwE89jCkdpgi6S24cWO2Y1z9ft2 8IhaycocWxPqPOqRYdOtPyDjup51Q+mI0/VmPS+F1aXQ8RzlLnBbHviSN8e79OOxTv fk+m7g4ZtmHiUJ06iDycLD6nxIIIan7rhvG8rcWb+gKc50kZQb8t/iKZ1UdjIRZbxf xiuWHxrIoGhZ+nifebeXC8UckPeIahQHfBKmZoJ3Koy7qxPwhCzUiJJe7bnFL9s02n JUO26r5hbODKH3559dVhwdmYHhTfh3iM7nXfqWxz/tNogKAY5/oZ9DyBBcxNE9bhGw G/4AaMx0K16jw== To: Antonin =?utf-8?Q?D=C3=A9cimo?= , Juliusz Chroboczek Cc: babel-chairs , Valery Smyslov , Babel at IETF In-Reply-To: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> <87lfeocoiv.wl-jch@irif.fr> Date: Thu, 26 Nov 2020 14:04:08 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87a6v4l16f.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 13:04:19 -0000 Antonin D=C3=A9cimo writes: > I support Juliusz' changes, and I have a patch ready ;-) The Bird implementation[0][1] is already updated (apart from the key size thing[2]), so feel free to test against that :) -Toke [0] http://trubka.network.cz/pipermail/bird-users/2020-November/015033.html [1] https://github.com/tohojo/bird/tree/babel-mac-03 [2] http://trubka.network.cz/pipermail/bird-users/2020-November/015047.html From nobody Thu Nov 26 11:03:01 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF5F3A0978; Thu, 26 Nov 2020 11:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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, 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 aiHvVfb2tQnt; Thu, 26 Nov 2020 11:02:59 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 3371C3A0980; Thu, 26 Nov 2020 11:02:59 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id i9so2663573ioo.2; Thu, 26 Nov 2020 11:02:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vrL0VjmkKk0LgLOzh2n502fqDf6XUxsbZKtEhU4Sf4M=; b=joWWaEpZ9jSZ/6qbOlE0UmThqw412sfttltSN79UOzbYyq5ojK4vTQ0G3/vD6P8CZ6 Ig2GZihMtvUhempqHEEz9/cM4A8AqICFfHEDXLOmDRnG9v9WbdcVZrCaXkRmGVtd0HEH sF2aVqG6AeRTHL74iFW0qWe07M3NJ41b7s3SkGj7/7UTIh3Je92tUzfOLNoFyT1jj8z/ jqI1spYDbKbPlmJKzV7SPDOKGPxYC9gfXfu4IoqzxRmYGsmbZPAk7Kkuw2NROJdpXyEJ WRizebMrjca3FojFIzHu2lqsd1dIewHaYZtnr6VfsPJrqaI/ubNyscAzVgghW0w9IqPh Wh8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vrL0VjmkKk0LgLOzh2n502fqDf6XUxsbZKtEhU4Sf4M=; b=UAxYFv0/X6PBVkJe94SKOUPhkAjMbea8ZZxbAfbuGTBXrn58VX8uHWwQr/SJKFezuA 0jZOhKWCzBTA9LPMmtesKx7l5Hn1UwFFz9r58gZU909DyA5PwOu4vxBhhnATNPIWpToX aHe0RCxSnaiUM4PPYoQkbU5fdjFqWJM/CFJ6NIKSAomTNTE7alKNlFRn+QXhhVSifUAh onA4hFA96FZgIxgtIVexxWo4JuEObkU7BfSj57IdOFo0efWPRH5Y6xBt4jYAA8HPEnlE XyqVefIb5oGbIwJsfJreq5itI9+7Gl9pyfmtjF6p2oD5X1M6jX4tO4uVKIHnKovpbz8F GiAg== X-Gm-Message-State: AOAM5321N/xoflV5TutkWX6UhCgbIQcOHog508LF3qX84g0qx2CKvsGe tVf9zQOAobLjDUz1prCOJE2/TzlUCZmX0XrE2Y0= X-Google-Smtp-Source: ABdhPJzjmf9qElWexZdtcxAc8WxxO+38UNZRj41TOXLKKtPw1lX6ntWvk9ZB8tRVYHOsW+GGmMti1VvRvZOqcSH+zSo= X-Received: by 2002:a02:ba90:: with SMTP id g16mr4265320jao.96.1606417378439; Thu, 26 Nov 2020 11:02:58 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> <87lfeocoiv.wl-jch@irif.fr> In-Reply-To: <87lfeocoiv.wl-jch@irif.fr> From: Donald Eastlake Date: Thu, 26 Nov 2020 14:02:47 -0500 Message-ID: To: Juliusz Chroboczek Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Babel at IETF , Valery Smyslov , babel-chairs Content-Type: multipart/alternative; boundary="00000000000033f59805b507316a" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 19:03:01 -0000 --00000000000033f59805b507316a Content-Type: text/plain; charset="UTF-8" Hi Juliusz, On Thu, Nov 26, 2020 at 7:04 AM Juliusz Chroboczek wrote: > >> I do not believe that it impacts the security in any way (2^128 ns is > >> roughly 10^12 times the age of the universe), but I could be wrong. > > > Yeah, makes sense, let's keep it at 32 bytes :) > > Excellent. I'm therefore going to make the following change in AUTH48: > > - in Section 4.1, replace > > Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] > and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], > and MAY implement other MAC algorithms. > > Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] > and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s with 128-bit > (16-octet) digests [RFC7693], and MAY implement other MAC algorithms. > > I will not change the following text in Section 7: > > Ideally, they should have a length of 32 octets (both for HMAC-SHA256 > and Blake2s), and be chosen randomly. > > Donald, are you willing to call consensus on this point? > All this has been discussed on the WG mailing list with no objection and there has been some further success but just to be sure, I'd like to wait a couple of days before declaring consensus. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com > -- Juliusz > --00000000000033f59805b507316a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Juliusz,

On Thu, Nov 26, 2020 at 7:04 AM Juliusz Chroboczek <jch@irif.fr> wrote:
>> I do not believe that it impacts the= security in any way (2^128 ns is
>> roughly 10^12 times the age of the universe), but I could be wrong= .

> Yeah, makes sense, let's keep it at 32 bytes :)

Excellent.=C2=A0 I'm therefore going to make the following change in AU= TH48:

=C2=A0 - in Section 4.1, replace

=C2=A0 =C2=A0Every implementation MUST implement HMAC-SHA256 as defined in = [RFC6234]
=C2=A0 =C2=A0and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RF= C7693],
=C2=A0 =C2=A0and MAY implement other MAC algorithms.

=C2=A0 =C2=A0Every implementation MUST implement HMAC-SHA256 as defined in = [RFC6234]
=C2=A0 =C2=A0and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s wit= h 128-bit
=C2=A0 =C2=A0(16-octet) digests [RFC7693], and MAY implement other MAC algo= rithms.

I will not change the following text in Section 7:

=C2=A0 =C2=A0 Ideally, they should have a length of 32 octets (both for HMA= C-SHA256
=C2=A0 =C2=A0 and Blake2s), and be chosen randomly.

Donald, are you willing to call consensus on this point?

All this has been discussed on the WG mailing list with n= o objection and there has been some further success but just to be sure, I&= #39;d like to wait a couple of days before declaring consensus.
<= br>
Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donald E. Eastlak= e 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A02386 Panoramic Circle, Apopka,= FL 32703 USA
=C2=A0
-- Juliusz
--00000000000033f59805b507316a-- From nobody Sat Nov 28 10:42:26 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBEC3A0ED9; Sat, 28 Nov 2020 10:42:24 -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 L5G966wnBkk0; Sat, 28 Nov 2020 10:42:23 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 522183A0ED5; Sat, 28 Nov 2020 10:42:23 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id d17so7817170ion.4; Sat, 28 Nov 2020 10:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f8uYrgdkLyM8581V4LRhNxVva+k3rtK2PFD0EZu/KKc=; b=ubC9kHvLrX5UV/XBZBORVYDEaoGCnFRY1s+ZvxdMFtLjneFulunAAbxqYu7LSRDiFN QFuF2mu0pYFUM6VvUNLTwO1RmeX7pZXcUEeLRq5BQzap5HYzYcK/ABnUPGvgw+2BIlX2 sMSjhxq78aBeasZKTXik8ThPnQTH9x8z4kOybLyYChL+2nDOMw+J6M7Nmdu3yCO25bV2 LGiFqlmoODyPFCAvpWb9KVpugUKggHHxdoyl+gVplelVY2D+rNfyFkMc83tuIA1iCATK uXxqg+6HbGxIZGaPOnoZN9wTwOdMFIZ+UzgFhRUwBrZhZTRez4n4eC7a995lU0xAJNCk l2Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f8uYrgdkLyM8581V4LRhNxVva+k3rtK2PFD0EZu/KKc=; b=axsB39oyZrL3uQHNN2e2Pku7em3VQdySjV5nGRSU8KKpAAuNIl226TQO778NEra8ej cj+RtD0NSf4fScqcdD8AU58xJygA0NZA7dg3aiNTzTIkPCtnGqDJnHLkAvTsBl7H93Ye sN17S6s2ypeH40JCr50ta33WAm0/bwpqko+TxUU/MbBtdTxFsxbIod09m8TklZC7xeuk 0+hTFl7XXGeX16HNtpvOxYFejNnADuS0+v7bZubb9u6O9ETwkkrGvXXZolfzq0/uWEzQ Co6k6jrvugXPlskFXUWYeUXL+GJ79/JxIXubIO50NOh6R0b8x6HpVcV1sGgPz0m9M8e2 oypg== X-Gm-Message-State: AOAM532849q1RsiCGToBp9EaxsmhF6CutAEGkfnIoQt5osmcSkHQ1D1N 7J2ZI2DFaJE8qYETxEucZmclduCo33Rwn/tuNMWG72KVYhg= X-Google-Smtp-Source: ABdhPJyZGTnIEH5b4ZkyQuXddNo++bjP4cyB8IMw+3aOYdBwq3d/V2x24Fi4A0IP+gHYW6N7Nik+SgKgJaHfZEKkou4= X-Received: by 2002:a02:90ca:: with SMTP id c10mr13120645jag.115.1606588942395; Sat, 28 Nov 2020 10:42:22 -0800 (PST) MIME-Version: 1.0 References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> <87lfeocoiv.wl-jch@irif.fr> In-Reply-To: From: Donald Eastlake Date: Sat, 28 Nov 2020 13:42:11 -0500 Message-ID: To: Juliusz Chroboczek Cc: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= , Babel at IETF , Valery Smyslov , babel-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 18:42:25 -0000 Hi Juliusz, There having been no further comments and given the extent to the discussion of this on the WG mailing list, I'm declaring WG consensus for this minor change. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Thu, Nov 26, 2020 at 2:02 PM Donald Eastlake wrote: > > Hi Juliusz, > > On Thu, Nov 26, 2020 at 7:04 AM Juliusz Chroboczek wrote: >> >> >> I do not believe that it impacts the security in any way (2^128 ns is >> >> roughly 10^12 times the age of the universe), but I could be wrong. >> >> > Yeah, makes sense, let's keep it at 32 bytes :) >> >> Excellent. I'm therefore going to make the following change in AUTH48: >> >> - in Section 4.1, replace >> >> Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] >> and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], >> and MAY implement other MAC algorithms. >> >> Every implementation MUST implement HMAC-SHA256 as defined in [RFC6234] >> and Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s with 128-bit >> (16-octet) digests [RFC7693], and MAY implement other MAC algorithms. >> >> I will not change the following text in Section 7: >> >> Ideally, they should have a length of 32 octets (both for HMAC-SHA256 >> and Blake2s), and be chosen randomly. >> >> Donald, are you willing to call consensus on this point? > > > All this has been discussed on the WG mailing list with no objection and there has been some further success but just to be sure, I'd like to wait a couple of days before declaring consensus. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 2386 Panoramic Circle, Apopka, FL 32703 USA > d3e3e3@gmail.com > >> >> -- Juliusz From nobody Mon Nov 30 13:10:57 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E763A11F2; Mon, 30 Nov 2020 13:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.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 jtY_eq0Vp6FI; Mon, 30 Nov 2020 13:10:47 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 263193A1208; Mon, 30 Nov 2020 13:10:47 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 0AUL5AvK022335; Mon, 30 Nov 2020 16:10:46 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 3555wc3wpx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Nov 2020 16:10:46 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0AULAi9H026563; Mon, 30 Nov 2020 16:10:45 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 0AULAgrY026536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Nov 2020 16:10:43 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id DF1F816A59A; Mon, 30 Nov 2020 21:10:42 +0000 (GMT) Received: from MISOUT7MSGEX2DF.ITServices.sbc.com (unknown [135.66.184.225]) by zlp27125.vci.att.com (Service) with ESMTPS id C6C4B16A593; Mon, 30 Nov 2020 21:10:42 +0000 (GMT) Received: from MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) by MISOUT7MSGEX2DF.ITServices.sbc.com (135.66.184.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 30 Nov 2020 16:10:41 -0500 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4 via Frontend Transport; Mon, 30 Nov 2020 16:10:41 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.174) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Mon, 30 Nov 2020 16:10:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XttbsCLib31YiLs8rJVP7Smxt4BOVpgTZbo9+mldEXQhbpKML3kvV92HhXGGPp/Hz5UiKC+3r63XYCu7f5i9EO0xjca2jOFdxDOU4oQT3By4s+guy3vSlSo2/q+RhFpPawkVPluiWaQlM8b0yCCdXQP4AIUDM+utAat2u2mczVP9jYqf5hG7yMUNq1fc5bPFMlIqin9oWWW33v0G3TxE+qQ0H8OZx3s+QwO7wrBItu52bCcvKAdaN0zTTf220BdSc1r94upVfEH+BzdWMM8hAnnFJuB77pVXWrPW8LKuDmwe+4jdy2qs/iSGPjtv+iuhbv2nF3M+Wc1bTC8VgKPaMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OxeLjuPM4KPX9cBZM0zv+kE5yZinIdeI37zC6a2Bb6E=; b=OH2BL1s0Xp6RMt9vMd44R0QeoibcOwb0cL9bkrA3aRPBNQ7auZyN5qF0jel28Ee0yFdY3WlZMpr+izpdfw1b8Y/ApqU8lzQPz1aR+r9I2O1d67N9ErqDgPmiDaPs0tuT+10kOoIQnsLlD6NCWAignuww7A1Sq1WlaOjTEHHi9QgYD546IUivbbD2RhSfBaWDyrpn+VWksb3s0SBrhqSaT6nu0u5YlKMHhzbO3CKGbxPxFnGAs099/n0g4734RuG+0gJuOBORtlnoNEPUTPUDAOpL0hpfqskHWrNAMlgPkx08CiPPTFy37qaJABsP6DZk/YKam+kmoFB0zN5ojA7Wkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OxeLjuPM4KPX9cBZM0zv+kE5yZinIdeI37zC6a2Bb6E=; b=NQySmFg7/C2OXLcBWfMdMIYoEO/1l8jVoe9F+gDXt+MS6alUaec3Z6GH3aEwhkXMwm0me5hCIK8vvTJS+ykP8fbHGkd4XZWhbOOqLjGROhiiiBiB3GbAgvYVVXo/gYsYmjDu+nguNrRZ5P3ykJqXQ8NkTMEK1/HMfw1O5KM6wg8= Received: from SN6PR02MB4512.namprd02.prod.outlook.com (2603:10b6:805:a4::13) by SN1PR02MB3872.namprd02.prod.outlook.com (2603:10b6:802:31::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Mon, 30 Nov 2020 21:10:27 +0000 Received: from SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::1813:2439:6aac:fc24]) by SN6PR02MB4512.namprd02.prod.outlook.com ([fe80::1813:2439:6aac:fc24%6]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 21:10:27 +0000 From: "STARK, BARBARA H" To: =?iso-8859-1?Q?=27Toke_H=F8iland-J=F8rgensen=27?= , "'Juliusz Chroboczek'" CC: "'Valery Smyslov'" , "'babel@ietf.org'" Thread-Topic: [babel] Babel-MAC: Blake2s is 128-bits by default Thread-Index: AQHWtIynqOW2ZrjKv0unDQSqMiR04Km7taWAgA3SHACAAU5LgIACOMyAgAC7PICAB9srAIADoxOAgAELyICABvr/QA== Date: Mon, 30 Nov 2020 21:10:27 +0000 Message-ID: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> In-Reply-To: <87ft4wl8h6.fsf@toke.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=att.com; x-originating-ip: [45.18.123.63] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ed0d676e-ef3c-41cb-4249-08d895745c63 x-ms-traffictypediagnostic: SN1PR02MB3872: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3S4kanYoQxmsZcEm4K/Mc9sbTq8sfE+gOmM0ONzksmurMT+6+NdgBYjCajMp2Mtr8Mgy/OTKkeI++PPwPnMfjRJtfwnCsHNvpJsQL47++yBJtA8TjkHMla2+1dC8+3URoSk32J5mBvoIYNzBoznxzRZziW27zjPxKcHMaAFKhJx2cZjGCQb3G5BDgwRtdbKhqs7xq3hwmOfWhAR45OK9rT3Mx9UB0zeHKJ2SbFsvY3hiO5rf4Fp0wTWaQm/clJYT3FifRMbWGCfhRXx47HtQS3Mdk+Rf3Cu17hSzosVuyiBXb0gWu8X46U6EYKKB58CGTd/cYOcEDefBl/9oW6bXEA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR02MB4512.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(4326008)(71200400001)(86362001)(478600001)(64756008)(5660300002)(33656002)(66556008)(52536014)(76116006)(66446008)(8676002)(8936002)(110136005)(82202003)(2906002)(6506007)(9686003)(55016002)(66476007)(316002)(54906003)(7696005)(26005)(186003)(66946007)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?KwVXJCV2CmmTkUszxuKHKbgaqqyzq0KoSDmhK7YFu8EVzeHlWGwihGJuy/?= =?iso-8859-1?Q?KZWGiGa0ub6BzwCM9FrmvvmJJBcIdYjpUUrOcCdukLfC8suxA/EhuBoe1e?= =?iso-8859-1?Q?hzYS5GgWT6pUMkL5ejH6G1zdbAfckSnBlC/Ca0FA7woauXxm9VHAKR4WY8?= =?iso-8859-1?Q?s9Sci7foR0IfzRH5J0x16D9JEQeeSrXbcfJ+JkbpawhmSGBB+h8y//POfr?= =?iso-8859-1?Q?HPA7f1bT+3oGM77hkBYbiK7bEBCJeshQgrUgMUNQLyfLLqXOFyUEck/oD0?= =?iso-8859-1?Q?b62AguP4Zhn3d2o+YsV+z1FMhHj3wKy0uG1VjCNCvsj50iTPuZphxGbUlK?= =?iso-8859-1?Q?EdbDxrWeawJQ7XxeVIlO5KqMAWslokwk06DgVCIaMF2AK/PDFVEZIUYtp4?= =?iso-8859-1?Q?wIx78xnppHuMJHPwA0rBRAjD+xaBE1TkYPLV55MD/z9dMb9Od81hK5NjWA?= =?iso-8859-1?Q?Mx1w0GL8m3BNiCyQCPljpfgvT6w9uj7qZEEy0pby/2cfJDTdshGyVWjEdm?= =?iso-8859-1?Q?wXZ4lpFkivMLRRDcp9m9j5hHt/Y7pvQwBxHp5/JvM1FFm5BTdEFwegc4EH?= =?iso-8859-1?Q?wLxkGyGn0jko8br0Ttit6vaowYJBWav9eGHbEDo1YBI5EUG/+PnTFkrO02?= =?iso-8859-1?Q?1PGWvfG8RMK/r45evB9+F1NTqhiWoIIcCkKoDQQh9Am0TWwsHfcuqsZ9J6?= =?iso-8859-1?Q?jSM99DYxmXRlINgrfrG1MWTb1ckM+SQNTeft9dBQAS206fwEBS/W1Vpqob?= =?iso-8859-1?Q?x+6J4B1HDV0rN2asiFUBm9G6rNftfW+ae/2iDDWElderSKNAUyYRiDrnxt?= =?iso-8859-1?Q?J3lVkCxblEsgtSTmjUkikN//b0qpJD/ugPUhCoxLaW+WTZ44Xe8sE+0V+a?= =?iso-8859-1?Q?1dvBKjXY7xCuf6VgVfae9OPvJ+VtIugwQEpcEC7hIud1Zrv7TQEbkQ1UNi?= =?iso-8859-1?Q?7zj7Swy40pATKByVDjcLfjumPIopSY1jxYicNSPZ3ZAbvqm91ZVBCzcmSO?= =?iso-8859-1?Q?Cahx3nG+ynbkyUSRo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR02MB4512.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed0d676e-ef3c-41cb-4249-08d895745c63 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 21:10:27.0539 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EffW15/5g/IhgpljiVwi2fo+1cd1KzfZlYiG0ZMBYGn6qKOViZOeYpzRzh4yu91Z X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB3872 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: BC61128B1C9AEE6EE876B8B0D1C4AB80D085159FC657C339FE4CC496F25689222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-30_11:2020-11-30, 2020-11-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 impostorscore=0 phishscore=0 priorityscore=1501 suspectscore=0 adultscore=0 bulkscore=0 mlxlogscore=270 clxscore=1015 malwarescore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011300134 Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 21:10:56 -0000 Just to confirm (because assuming is bad)... > >> This does raise one question, though (as I just found out while > >> implementing the option for a 128-bit version): How does this impact t= he > >> recommendations for key size? > > > > I suggest that they remain the same (SHOULD be 32 bytes). > > > > The digest size impacts the overhead carried by every packet. Not so t= he > > key size: increasing the key size is essentially free. As a matter of > > fact, Blake2s will pad the key with zeroes before it is used. > > > > Thus: > > > > - allowing shorter keys gains no generality (the user may achieve the > > same result by padding with zeroes before passing the key to Blake2= s); > > > > - disallowing shorter keys causes confusion (by using a value differe= nt > > from both HMAC-SHA-256 and the Blake2s maximum), and has no > measurable > > benefits. > > > > I do not believe that it impacts the security in any way (2^128 ns is > > roughly 10^12 times the age of the universe), but I could be wrong. >=20 > Yeah, makes sense, let's keep it at 32 bytes :) ... this means that other than changing "BLAKE2s" to "BLAKE2s-128" (consist= ent with the list of "possible values" change), no other change is needed to th= e text=20 in info model re BLAKE2s key length: If the algorithm is "BLAKE2s-128", the length MUST be between 0 and 32 bytes inclusive, as described in [RFC7693]. Barbara From nobody Mon Nov 30 15:26:27 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7623A125F for ; Mon, 30 Nov 2020 15:26:18 -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, 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=toke.dk 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 FVyLI8SRfCDz for ; Mon, 30 Nov 2020 15:26:16 -0800 (PST) Received: from mail.toke.dk (mail.toke.dk [45.145.95.4]) (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 B5F3D3A1263 for ; Mon, 30 Nov 2020 15:26:15 -0800 (PST) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1606778769; bh=Qx8wfA4v4zv+HpPdoppchHbXK18ywhOXiK19ybpdGaY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=O/bzJR1oGxhDcytbqyPeSELb0zEpnyxhg9FaPX9TKjYF5BxsqBHN+A3lWgpRxVEsv X/dzSULRZ9onDRkvaq6O8L33ISEKpBBQs8kT/+9XgeP2a8Y02s6yXfahX3H9rhX10a ipbiTfxyxplaIrB191jF0WAJOqt+T6fndHp7Tfq3H7A1GVdpxOnEl4gQ0aJ7WJzg1U A0RXgDcw0BYSswqU4w1P8xU5EPqNwM8NMLam0AoQsJPSJzw6CiHFvowAbog6hig5jo o9mql0keO3D3USjv5g7xT9rScEodpQN10BhIzSNNf8N/ydnJfhUGTLv9ACihGUPe58 fP4zBnmS3B5RQ== To: "STARK, BARBARA H" , 'Juliusz Chroboczek' Cc: 'Valery Smyslov' , "'babel@ietf.org'" In-Reply-To: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> Date: Tue, 01 Dec 2020 00:26:09 +0100 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87k0u2whny.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 23:26:26 -0000 "STARK, BARBARA H" writes: > Just to confirm (because assuming is bad)... > >> >> This does raise one question, though (as I just found out while >> >> implementing the option for a 128-bit version): How does this impact the >> >> recommendations for key size? >> > >> > I suggest that they remain the same (SHOULD be 32 bytes). >> > >> > The digest size impacts the overhead carried by every packet. Not so the >> > key size: increasing the key size is essentially free. As a matter of >> > fact, Blake2s will pad the key with zeroes before it is used. >> > >> > Thus: >> > >> > - allowing shorter keys gains no generality (the user may achieve the >> > same result by padding with zeroes before passing the key to Blake2s); >> > >> > - disallowing shorter keys causes confusion (by using a value different >> > from both HMAC-SHA-256 and the Blake2s maximum), and has no >> measurable >> > benefits. >> > >> > I do not believe that it impacts the security in any way (2^128 ns is >> > roughly 10^12 times the age of the universe), but I could be wrong. >> >> Yeah, makes sense, let's keep it at 32 bytes :) > > ... this means that other than changing "BLAKE2s" to "BLAKE2s-128" (consistent > with the list of "possible values" change), no other change is needed to the text > in info model re BLAKE2s key length: > > If the algorithm is "BLAKE2s-128", > the length MUST be between 0 and 32 bytes inclusive, as described > in [RFC7693]. AFAICT, you are quite right! :) -Toke From nobody Mon Nov 30 15:40:08 2020 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711EA3A1077; Mon, 30 Nov 2020 15:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 YJ3YoyBUXRqP; Mon, 30 Nov 2020 15:40:04 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 68D443A03F4; Mon, 30 Nov 2020 15:40:02 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 0AUNducT009943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Dec 2020 00:39:56 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 0AUNdtgp004981; Tue, 1 Dec 2020 00:39:55 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 4F820129C66; Tue, 1 Dec 2020 00:39:55 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id P_JLqcH4Brzp; Tue, 1 Dec 2020 00:39:53 +0100 (CET) Received: from pirx.irif.fr (82-64-141-196.subs.proxad.net [82.64.141.196]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 6F6F8129C64; Tue, 1 Dec 2020 00:39:53 +0100 (CET) Date: Tue, 01 Dec 2020 00:39:45 +0100 Message-ID: <87ft4q5s8u.wl-jch@irif.fr> From: Juliusz Chroboczek To: "STARK, BARBARA H" Cc: "'Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen=27?=" , "'Valery Smyslov'" , "'babel@ietf.org'" In-Reply-To: References: <87d00qungk.wl-jch@irif.fr> <87h7q2f6a2.fsf@toke.dk> <87o8jya4jz.wl-jch@irif.fr> <87wnyl4dgi.fsf@toke.dk> <878sazh7ge.wl-jch@irif.fr> <87o8jvylta.fsf@toke.dk> <87o8jomjfb.fsf@toke.dk> <87360xz3yk.wl-jch@irif.fr> <87ft4wl8h6.fsf@toke.dk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 01 Dec 2020 00:39:56 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 01 Dec 2020 00:39:56 +0100 (CET) X-Miltered: at korolev with ID 5FC582CC.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 5FC582CB.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5FC582CC.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 5FC582CB.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5FC582CC.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 5FC582CB.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Archived-At: Subject: Re: [babel] Babel-MAC: Blake2s is 128-bits by default X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 23:40:07 -0000 > ... this means that other than changing "BLAKE2s" to "BLAKE2s-128" (consistent > with the list of "possible values" change), no other change is needed to the text > in info model re BLAKE2s key length: > If the algorithm is "BLAKE2s-128", > the length MUST be between 0 and 32 bytes inclusive, as described > in [RFC7693]. That looks correct to me.