From nobody Thu Jan 4 14:30:46 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3F3126D85 for ; Thu, 4 Jan 2018 14:30: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calix.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 SYcKHf1p-nDi for ; Thu, 4 Jan 2018 14:30:34 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0207.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e46::207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8651242F5 for ; Thu, 4 Jan 2018 14:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com; s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/waJGrun+eQOJi0AOhPYIryPWfJvslas0ntVozLHK4g=; b=BL7Xe4GF5B27bIoeDQ+z5IY6j7SafNX8+vRi715iCwh+xFkCLs6HuN2rCwQp2Rg3N4LbTGEgvRYsfURl3K+OZj82W9OMOPQ3MarNz2TGzMaDxBpYkTLi7eoWa1kiL4zvtT7YEyLBJeyLKHmArjLpyXB4qK3bH6NTO2PF+VVHPCA= Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB1719.namprd05.prod.outlook.com (10.163.154.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Thu, 4 Jan 2018 22:30:04 +0000 Received: from BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) with mapi id 15.20.0386.006; Thu, 4 Jan 2018 22:30:04 +0000 From: Marta Seda To: "ipfix@ietf.org" Thread-Topic: RFC 6728 IETF IPFIX Yang Discussion Thread-Index: AdOFq4/g/UhqDUnGS1y9w5Kq6vABEg== Date: Thu, 4 Jan 2018 22:30:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marta.Seda@calix.com; x-originating-ip: [23.118.53.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1719; 7:rNSSbOKL3fKjnAgsn9Fy89xmv64aj2oMtn98JpM7/xVH9Bm7j3+2/t2kTWfjjCRVBbxjj++3ZPhlWNyB7OV7Yvn/6j9T+4W9k+pYgE3R+sfXpt5twYJSwnOGKm3R5V1ctc11c/ameFQpGOfjFhH2LJ81CxC0gCZbt68xGAjqkbAAuEzw+1jou5x6rLdUQnChdanerCtyUdhcSGQ1bgSQUdrMzPmSvNbgmtFwz3o9ARG/5+DUhX5geoUYPvC3nCNZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 87a50f01-3d12-4d8e-2fd3-08d553c2b3c3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074); SRVR:BY2PR0501MB1719; x-ms-traffictypediagnostic: BY2PR0501MB1719: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231023)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:BY2PR0501MB1719; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR0501MB1719; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(376002)(366004)(346002)(39380400002)(396003)(199004)(189003)(5660300001)(55016002)(33656002)(2900100001)(68736007)(72206003)(790700001)(9326002)(9686003)(236005)(5640700003)(102836004)(1730700003)(8676002)(3846002)(6116002)(99286004)(77096006)(6306002)(86362001)(6436002)(606006)(316002)(81166006)(6916009)(14454004)(54896002)(81156014)(478600001)(7736002)(5890100001)(6506007)(99936001)(7696005)(2351001)(97736004)(2501003)(3660700001)(8936002)(2906002)(59450400001)(3280700002)(66066001)(106356001)(74316002)(5630700001)(25786009)(105586002)(53936002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB1719; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: calix.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 44adEKc5u1rtEpt7H0Oihkmt5QT2JOz/Lv8hGZnEP5cqjQ820MvcNjZAZaE1RhDJCzQ5SpABCnG+ZhMgj9U3iQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_004_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_" MIME-Version: 1.0 X-OriginatorOrg: calix.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87a50f01-3d12-4d8e-2fd3-08d553c2b3c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 22:30:04.6529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1719 Archived-At: Subject: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 22:30:44 -0000 --_004_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_ Content-Type: multipart/alternative; boundary="_000_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_" --_000_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I am reaching out to the IETF IPFIX mailing list on some issues I have run= into with respect to RFC 6728 "Configuration Data Model for the IP Flow In= formation Export (IPFIX) and Packet Sampling (PSAMP) Protocols" 1. RFC 6728 doesn't meet the latest Yang Best Practices (https://tools.i= etf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identif= iers are camel case (e.g., destinationAddress instead of destination-addres= s). Are there any ongoing efforts to update RFC 6728 to meet the latest be= st practices? Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lower-case letters, numbers, and dashes SHOULD be used in identifier names. Upper-case characters and the underscore character MAY be used if the identifier represents a well-known value that uses these characters. Identifiers SHOULD include complete words and/or well-known acronyms or abbreviations. Child nodes within a container or list SHOULD NOT replicate the parent identifier. YANG identifiers are hierarchical and are only meant to be unique within the the set of sibling nodes defined in the same module namespace. It is permissible to use common identifiers such as "name" or "id" in data definition statements, especially if these data nodes share a common data type. Identifiers SHOULD NOT carry any special semantics that identify data modelling properties. Only YANG statements and YANG extension statements are designed to convey machine readable data modelling properties. For example, naming an object "config" or "state" does not change whether it is configuration data or state data. Only defined YANG statements or YANG extension statements can be used to assign semantics in a machine readable format in YANG. 1. I generated the RFC 6728 yang tree (see attached). The tcp and udp e= xporting processes support a destinationIPAddress (line 400, 455) which is = mandatory. The type is inet:ip-address. * A collector may be doing load balancing. Rather than managing ip-= addresses, the collector may be using DNS (an exporter could resolve from t= he domain name where the collector is located). * The collector address may be learnt via other methods (e.g., throu= gh DHCP options) * A choice statement to select what method to use seems more appropr= iate than what is presently in RFC 6728. For example (use some shorthand) choice destination-method{ case destination-address{ leaf destination-address// rw with type ine= t:host } case dhcp-acquired-address{ container dcp-acquired-address{ leaf destination-ip-address= inet-address //ro } } However I can't augment to ietf-ipfix becau= se destinationIPAddress is mandatory. Can the group suggest methods to (a)= change the destinationIPAddress type and (b) allow a choice? 1. RFC 6728 mandates SCTP transport. I understand the logic behind this= (IETF prefers use of SCTP). There are situations where sctp is unnecessar= y and not supported (e.g., point to point connection). During netconf nego= tiations you can announce your feature set (currently sctptransport is not = a feature). Is there ongoing work in updating RFC 6728 to include sctptran= sport as a feature (so that the device can announce whether or not it suppo= rts sctptransport)? Regards Marta Seda --_000_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

I am reaching out to the IETF IPFIX mailing list &nb= sp;on some issues I have run into with respect to RFC 6728 “Configura= tion Data Model for the IP Flow Information Export (IPFIX)  and Packet= Sampling (PSAMP) Protocols”

 

  1. R= FC 6728 doesn’t meet the latest Yang Best Practices (https= ://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1).&= nbsp;  Leaf identifiers are camel case (e.g., destinationAddress instead of desti= nation-address).  Are there any ongoing efforts to update RFC 6728 to = meet the latest best practices?

 

   Identifiers SHOULD follow a consi= stent naming pattern throughout the

   module.  Only lower-case let= ters, numbers, and dashes SHOULD be used

   in identifier names.  Upper-= case characters and the underscore

   character MAY be used if the iden= tifier represents a well-known value

   that uses these characters.<= /o:p>

 

   Identifiers SHOULD include comple= te words and/or well-known acronyms

   or abbreviations.  Child nod= es within a container or list SHOULD NOT

   replicate the parent identifier.&= nbsp; YANG identifiers are hierarchical

   and are only meant to be unique w= ithin the the set of sibling nodes

   defined in the same module namesp= ace.

 

   It is permissible to use common i= dentifiers such as "name" or "id" in<= /p>

   data definition statements, espec= ially if these data nodes share a

   common data type.

 

   Identifiers SHOULD NOT carry any = special semantics that identify data

   modelling properties.  Only = YANG statements and YANG extension

   statements are designed to convey= machine readable data modelling

   properties.  For example, na= ming an object "config" or "state" does

   not change whether it is configur= ation data or state data.  Only

   defined YANG statements or YANG e= xtension statements can be used to

   assign semantics in a machine rea= dable format in YANG.

 

  1. I= generated the RFC 6728 yang tree (see attached).  The tcp and udp exp= orting processes support a destinationIPAddress (line 400, 455) which is ma= ndatory.  The type is inet:ip-address. 
    1. A= collector may be doing load balancing.  Rather than managing ip-addre= sses, the collector may be using DNS (an exporter could resolve from the do= main name where the collector is located). 
    2. The collector address may be learnt via other methods (e.g.,= through DHCP options)
    3. A choice statement to select what meth= od to use seems more appropriate than what is presently in RFC 6728.  = For example (use some shorthand)

 

choice destination-metho= d{

    =             case des= tination-address{

    =             &nb= sp;            =    leaf destination-address// rw with type inet:host

    =             }

    =             case dhc= p-acquired-address{

    =             &nb= sp;            =    container dcp-acquired-address{

    =             &nb= sp;            =             &nb= sp;      leaf destination-ip-address inet-address = //ro

    =             }

}

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;          However I can&#= 8217;t augment to ietf-ipfix because destinationIPAddress is mandatory.&nbs= p; Can the group suggest methods to (a) change the destinationIPAddress typ= e and (b) allow a choice?

 

 

  1. R= FC 6728 mandates SCTP transport.  I understand the logic behind this (= IETF prefers use of SCTP).  There are situations where sctp is unneces= sary and not supported (e.g., point to point connection).  During netconf negotiations you can announce your feature set (currently s= ctptransport is not a feature).  Is there ongoing work in updating RFC= 6728 to include sctptransport as a feature (so that the device can announc= e whether or not it supports sctptransport)? 

 

Regards

 

Marta Seda

 

--_000_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_-- --_004_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_ Content-Type: application/octet-stream; name="ietf-ipfix.tree" Content-Description: ietf-ipfix.tree Content-Disposition: attachment; filename="ietf-ipfix.tree"; size=29671; creation-date="Thu, 04 Jan 2018 22:22:16 GMT"; modification-date="Tue, 02 Jan 2018 22:02:54 GMT" Content-Transfer-Encoding: base64 bW9kdWxlOiBpZXRmLWlwZml4LXBzYW1wCiAgICArLS1ydyBpcGZpeAogICAgICAgKy0tcncgY29s bGVjdGluZ1Byb2Nlc3MqIFtuYW1lXSB7Y29sbGVjdG9yfT8KICAgICAgIHwgICstLXJ3IG5hbWUg ICAgICAgICAgICAgICAgbmFtZVR5cGUKICAgICAgIHwgICstLXJ3IHNjdHBDb2xsZWN0b3IqIFtu YW1lXQogICAgICAgfCAgfCAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgICBuYW1lVHlw ZQogICAgICAgfCAgfCAgKy0tcncgbG9jYWxQb3J0PyAgICAgICAgICAgICAgICBpbmV0OnBvcnQt bnVtYmVyCiAgICAgICB8ICB8ICArLS1ydyB0cmFuc3BvcnRMYXllclNlY3VyaXR5IQogICAgICAg fCAgfCAgfCAgKy0tcncgbG9jYWxDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5RE4qICAgIHN0cmluZwog ICAgICAgfCAgfCAgfCAgKy0tcncgbG9jYWxTdWJqZWN0RE4qICAgICAgICAgICAgICAgICAgIHN0 cmluZwogICAgICAgfCAgfCAgfCAgKy0tcncgbG9jYWxTdWJqZWN0RlFETiogICAgICAgICAgICAg ICAgIGluZXQ6ZG9tYWluLW5hbWUKICAgICAgIHwgIHwgIHwgICstLXJ3IHJlbW90ZUNlcnRpZmlj YXRpb25BdXRob3JpdHlETiogICBzdHJpbmcKICAgICAgIHwgIHwgIHwgICstLXJ3IHJlbW90ZVN1 YmplY3RETiogICAgICAgICAgICAgICAgICBzdHJpbmcKICAgICAgIHwgIHwgIHwgICstLXJ3IHJl bW90ZVN1YmplY3RGUUROKiAgICAgICAgICAgICAgICBpbmV0OmRvbWFpbi1uYW1lCiAgICAgICB8 ICB8ICArLS1ybyB0cmFuc3BvcnRTZXNzaW9uKgogICAgICAgfCAgfCAgfCAgKy0tcm8gaXBmaXhW ZXJzaW9uPyAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgfCAgfCAgfCAgKy0t cm8gc291cmNlQWRkcmVzcz8gICAgICAgICAgICAgICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcwog ICAgICAgfCAgfCAgfCAgKy0tcm8gZGVzdGluYXRpb25BZGRyZXNzPyAgICAgICAgICAgICAgICAg IGluZXQ6aXAtYWRkcmVzcwogICAgICAgfCAgfCAgfCAgKy0tcm8gc291cmNlUG9ydD8gICAgICAg ICAgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXIKICAgICAgIHwgIHwgIHwgICstLXJv IGRlc3RpbmF0aW9uUG9ydD8gICAgICAgICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAg ICAgICB8ICB8ICB8ICArLS1ybyBzY3RwQXNzb2NJZD8gICAgICAgICAgICAgICAgICAgICAgICAg dWludDMyCiAgICAgICB8ICB8ICB8ICArLS1ybyBzdGF0dXM/ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdHJhbnNwb3J0U2Vzc2lvblN0YXR1cwogICAgICAgfCAgfCAgfCAgKy0tcm8gcmF0 ZT8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6Z2F1Z2UzMgogICAgICAgfCAg fCAgfCAgKy0tcm8gYnl0ZXM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6Y291 bnRlcjY0CiAgICAgICB8ICB8ICB8ICArLS1ybyBtZXNzYWdlcz8gICAgICAgICAgICAgICAgICAg ICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgIHwgIHwgIHwgICstLXJvIGRpc2NhcmRlZE1l c3NhZ2VzPyAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgfCAgfCAgfCAg Ky0tcm8gcmVjb3Jkcz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0 CiAgICAgICB8ICB8ICB8ICArLS1ybyB0ZW1wbGF0ZXM/ICAgICAgICAgICAgICAgICAgICAgICAg ICAgeWFuZzpjb3VudGVyMzIKICAgICAgIHwgIHwgIHwgICstLXJvIG9wdGlvbnNUZW1wbGF0ZXM/ ICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXIzMgogICAgICAgfCAgfCAgfCAgKy0tcm8g dHJhbnNwb3J0U2Vzc2lvblN0YXJ0VGltZT8gICAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQog ICAgICAgfCAgfCAgfCAgKy0tcm8gdHJhbnNwb3J0U2Vzc2lvbkRpc2NvbnRpbnVpdHlUaW1lPyAg IHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAgfCAgfCAgfCAgKy0tcm8gdGVtcGxhdGUqCiAgICAg ICB8ICB8ICB8ICAgICArLS1ybyBvYnNlcnZhdGlvbkRvbWFpbklkPyAgICAgICAgIHVpbnQzMgog ICAgICAgfCAgfCAgfCAgICAgKy0tcm8gdGVtcGxhdGVJZD8gICAgICAgICAgICAgICAgICB1aW50 MTYKICAgICAgIHwgIHwgIHwgICAgICstLXJvIHNldElkPyAgICAgICAgICAgICAgICAgICAgICAg dWludDE2CiAgICAgICB8ICB8ICB8ICAgICArLS1ybyBhY2Nlc3NUaW1lPyAgICAgICAgICAgICAg ICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAgfCAgfCAgfCAgICAgKy0tcm8gdGVtcGxhdGVE YXRhUmVjb3Jkcz8gICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgfCAgfCAgfCAgICAgKy0t cm8gdGVtcGxhdGVEaXNjb250aW51aXR5VGltZT8gICB5YW5nOmRhdGUtYW5kLXRpbWUKICAgICAg IHwgIHwgIHwgICAgICstLXJvIGZpZWxkKgogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcm8gaWVJ ZD8gICAgICAgICAgICAgICAgIGllSWRUeXBlCiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBp ZUxlbmd0aD8gICAgICAgICAgICAgdWludDE2CiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBp ZUVudGVycHJpc2VOdW1iZXI/ICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBp c0Zsb3dLZXk/ICAgICAgICAgICAgZW1wdHkKICAgICAgIHwgIHwgIHwgICAgICAgICstLXJvIGlz U2NvcGU/ICAgICAgICAgICAgICBlbXB0eQogICAgICAgfCAgfCAgKy0tcncgbG9jYWxJUEFkZHJl c3MqICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgIHwgICstLXJ3IHVkcENvbGxlY3Rv ciogW25hbWVdIHt1ZHBUcmFuc3BvcnR9PwogICAgICAgfCAgfCAgKy0tcncgbmFtZSAgICAgICAg ICAgICAgICAgICAgICAgICBuYW1lVHlwZQogICAgICAgfCAgfCAgKy0tcncgbG9jYWxQb3J0PyAg ICAgICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICB8ICB8ICArLS1ydyB0cmFu c3BvcnRMYXllclNlY3VyaXR5IQogICAgICAgfCAgfCAgfCAgKy0tcncgbG9jYWxDZXJ0aWZpY2F0 aW9uQXV0aG9yaXR5RE4qICAgIHN0cmluZwogICAgICAgfCAgfCAgfCAgKy0tcncgbG9jYWxTdWJq ZWN0RE4qICAgICAgICAgICAgICAgICAgIHN0cmluZwogICAgICAgfCAgfCAgfCAgKy0tcncgbG9j YWxTdWJqZWN0RlFETiogICAgICAgICAgICAgICAgIGluZXQ6ZG9tYWluLW5hbWUKICAgICAgIHwg IHwgIHwgICstLXJ3IHJlbW90ZUNlcnRpZmljYXRpb25BdXRob3JpdHlETiogICBzdHJpbmcKICAg ICAgIHwgIHwgIHwgICstLXJ3IHJlbW90ZVN1YmplY3RETiogICAgICAgICAgICAgICAgICBzdHJp bmcKICAgICAgIHwgIHwgIHwgICstLXJ3IHJlbW90ZVN1YmplY3RGUUROKiAgICAgICAgICAgICAg ICBpbmV0OmRvbWFpbi1uYW1lCiAgICAgICB8ICB8ICArLS1ybyB0cmFuc3BvcnRTZXNzaW9uKgog ICAgICAgfCAgfCAgfCAgKy0tcm8gaXBmaXhWZXJzaW9uPyAgICAgICAgICAgICAgICAgICAgICAg IHVpbnQxNgogICAgICAgfCAgfCAgfCAgKy0tcm8gc291cmNlQWRkcmVzcz8gICAgICAgICAgICAg ICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcwogICAgICAgfCAgfCAgfCAgKy0tcm8gZGVzdGluYXRp b25BZGRyZXNzPyAgICAgICAgICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcwogICAgICAgfCAgfCAg fCAgKy0tcm8gc291cmNlUG9ydD8gICAgICAgICAgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1u dW1iZXIKICAgICAgIHwgIHwgIHwgICstLXJvIGRlc3RpbmF0aW9uUG9ydD8gICAgICAgICAgICAg ICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICB8ICB8ICB8ICArLS1ybyBzY3RwQXNzb2NJ ZD8gICAgICAgICAgICAgICAgICAgICAgICAgdWludDMyCiAgICAgICB8ICB8ICB8ICArLS1ybyBz dGF0dXM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdHJhbnNwb3J0U2Vzc2lvblN0YXR1 cwogICAgICAgfCAgfCAgfCAgKy0tcm8gcmF0ZT8gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHlhbmc6Z2F1Z2UzMgogICAgICAgfCAgfCAgfCAgKy0tcm8gYnl0ZXM/ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICB8ICB8ICB8ICArLS1ybyBt ZXNzYWdlcz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAg IHwgIHwgIHwgICstLXJvIGRpc2NhcmRlZE1lc3NhZ2VzPyAgICAgICAgICAgICAgICAgICB5YW5n OmNvdW50ZXI2NAogICAgICAgfCAgfCAgfCAgKy0tcm8gcmVjb3Jkcz8gICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICB8ICB8ICB8ICArLS1ybyB0ZW1wbGF0 ZXM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyMzIKICAgICAgIHwgIHwg IHwgICstLXJvIG9wdGlvbnNUZW1wbGF0ZXM/ICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50 ZXIzMgogICAgICAgfCAgfCAgfCAgKy0tcm8gdHJhbnNwb3J0U2Vzc2lvblN0YXJ0VGltZT8gICAg ICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAgfCAgfCAgfCAgKy0tcm8gdHJhbnNwb3J0 U2Vzc2lvbkRpc2NvbnRpbnVpdHlUaW1lPyAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAgfCAg fCAgfCAgKy0tcm8gdGVtcGxhdGUqCiAgICAgICB8ICB8ICB8ICAgICArLS1ybyBvYnNlcnZhdGlv bkRvbWFpbklkPyAgICAgICAgIHVpbnQzMgogICAgICAgfCAgfCAgfCAgICAgKy0tcm8gdGVtcGxh dGVJZD8gICAgICAgICAgICAgICAgICB1aW50MTYKICAgICAgIHwgIHwgIHwgICAgICstLXJvIHNl dElkPyAgICAgICAgICAgICAgICAgICAgICAgdWludDE2CiAgICAgICB8ICB8ICB8ICAgICArLS1y byBhY2Nlc3NUaW1lPyAgICAgICAgICAgICAgICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAg fCAgfCAgfCAgICAgKy0tcm8gdGVtcGxhdGVEYXRhUmVjb3Jkcz8gICAgICAgICB5YW5nOmNvdW50 ZXI2NAogICAgICAgfCAgfCAgfCAgICAgKy0tcm8gdGVtcGxhdGVEaXNjb250aW51aXR5VGltZT8g ICB5YW5nOmRhdGUtYW5kLXRpbWUKICAgICAgIHwgIHwgIHwgICAgICstLXJvIGZpZWxkKgogICAg ICAgfCAgfCAgfCAgICAgICAgKy0tcm8gaWVJZD8gICAgICAgICAgICAgICAgIGllSWRUeXBlCiAg ICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBpZUxlbmd0aD8gICAgICAgICAgICAgdWludDE2CiAg ICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBpZUVudGVycHJpc2VOdW1iZXI/ICAgdWludDMyCiAg ICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBpc0Zsb3dLZXk/ICAgICAgICAgICAgZW1wdHkKICAg ICAgIHwgIHwgIHwgICAgICAgICstLXJvIGlzU2NvcGU/ICAgICAgICAgICAgICBlbXB0eQogICAg ICAgfCAgfCAgKy0tcncgbG9jYWxJUEFkZHJlc3MqICAgICAgICAgICAgICBpbmV0OmlwLWFkZHJl c3MKICAgICAgIHwgIHwgICstLXJ3IHRlbXBsYXRlTGlmZVRpbWU/ICAgICAgICAgICAgdWludDMy CiAgICAgICB8ICB8ICArLS1ydyBvcHRpb25zVGVtcGxhdGVMaWZlVGltZT8gICAgIHVpbnQzMgog ICAgICAgfCAgfCAgKy0tcncgdGVtcGxhdGVMaWZlUGFja2V0PyAgICAgICAgICB1aW50MzIKICAg ICAgIHwgIHwgICstLXJ3IG9wdGlvbnNUZW1wbGF0ZUxpZmVQYWNrZXQ/ICAgdWludDMyCiAgICAg ICB8ICArLS1ydyB0Y3BDb2xsZWN0b3IqIFtuYW1lXSB7dGNwVHJhbnNwb3J0fT8KICAgICAgIHwg IHwgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgbmFtZVR5cGUKICAgICAgIHwgIHwg ICstLXJ3IGxvY2FsUG9ydD8gICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAg fCAgfCAgKy0tcncgdHJhbnNwb3J0TGF5ZXJTZWN1cml0eSEKICAgICAgIHwgIHwgIHwgICstLXJ3 IGxvY2FsQ2VydGlmaWNhdGlvbkF1dGhvcml0eUROKiAgICBzdHJpbmcKICAgICAgIHwgIHwgIHwg ICstLXJ3IGxvY2FsU3ViamVjdEROKiAgICAgICAgICAgICAgICAgICBzdHJpbmcKICAgICAgIHwg IHwgIHwgICstLXJ3IGxvY2FsU3ViamVjdEZRRE4qICAgICAgICAgICAgICAgICBpbmV0OmRvbWFp bi1uYW1lCiAgICAgICB8ICB8ICB8ICArLS1ydyByZW1vdGVDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5 RE4qICAgc3RyaW5nCiAgICAgICB8ICB8ICB8ICArLS1ydyByZW1vdGVTdWJqZWN0RE4qICAgICAg ICAgICAgICAgICAgc3RyaW5nCiAgICAgICB8ICB8ICB8ICArLS1ydyByZW1vdGVTdWJqZWN0RlFE TiogICAgICAgICAgICAgICAgaW5ldDpkb21haW4tbmFtZQogICAgICAgfCAgfCAgKy0tcm8gdHJh bnNwb3J0U2Vzc2lvbioKICAgICAgIHwgIHwgIHwgICstLXJvIGlwZml4VmVyc2lvbj8gICAgICAg ICAgICAgICAgICAgICAgICB1aW50MTYKICAgICAgIHwgIHwgIHwgICstLXJvIHNvdXJjZUFkZHJl c3M/ICAgICAgICAgICAgICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgIHwgIHwgIHwg ICstLXJvIGRlc3RpbmF0aW9uQWRkcmVzcz8gICAgICAgICAgICAgICAgICBpbmV0OmlwLWFkZHJl c3MKICAgICAgIHwgIHwgIHwgICstLXJvIHNvdXJjZVBvcnQ/ICAgICAgICAgICAgICAgICAgICAg ICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICB8ICB8ICB8ICArLS1ybyBkZXN0aW5hdGlvblBv cnQ/ICAgICAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAgfCAgfCAgfCAg Ky0tcm8gc2N0cEFzc29jSWQ/ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMgogICAgICAg fCAgfCAgfCAgKy0tcm8gc3RhdHVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRyYW5z cG9ydFNlc3Npb25TdGF0dXMKICAgICAgIHwgIHwgIHwgICstLXJvIHJhdGU/ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB5YW5nOmdhdWdlMzIKICAgICAgIHwgIHwgIHwgICstLXJvIGJ5 dGVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAg fCAgfCAgfCAgKy0tcm8gbWVzc2FnZXM/ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6 Y291bnRlcjY0CiAgICAgICB8ICB8ICB8ICArLS1ybyBkaXNjYXJkZWRNZXNzYWdlcz8gICAgICAg ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgIHwgIHwgIHwgICstLXJvIHJlY29yZHM/ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgfCAgfCAg fCAgKy0tcm8gdGVtcGxhdGVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRl cjMyCiAgICAgICB8ICB8ICB8ICArLS1ybyBvcHRpb25zVGVtcGxhdGVzPyAgICAgICAgICAgICAg ICAgICAgeWFuZzpjb3VudGVyMzIKICAgICAgIHwgIHwgIHwgICstLXJvIHRyYW5zcG9ydFNlc3Np b25TdGFydFRpbWU/ICAgICAgICAgICB5YW5nOmRhdGUtYW5kLXRpbWUKICAgICAgIHwgIHwgIHwg ICstLXJvIHRyYW5zcG9ydFNlc3Npb25EaXNjb250aW51aXR5VGltZT8gICB5YW5nOmRhdGUtYW5k LXRpbWUKICAgICAgIHwgIHwgIHwgICstLXJvIHRlbXBsYXRlKgogICAgICAgfCAgfCAgfCAgICAg Ky0tcm8gb2JzZXJ2YXRpb25Eb21haW5JZD8gICAgICAgICB1aW50MzIKICAgICAgIHwgIHwgIHwg ICAgICstLXJvIHRlbXBsYXRlSWQ/ICAgICAgICAgICAgICAgICAgdWludDE2CiAgICAgICB8ICB8 ICB8ICAgICArLS1ybyBzZXRJZD8gICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAg fCAgfCAgfCAgICAgKy0tcm8gYWNjZXNzVGltZT8gICAgICAgICAgICAgICAgICB5YW5nOmRhdGUt YW5kLXRpbWUKICAgICAgIHwgIHwgIHwgICAgICstLXJvIHRlbXBsYXRlRGF0YVJlY29yZHM/ICAg ICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgIHwgIHwgIHwgICAgICstLXJvIHRlbXBsYXRlRGlz Y29udGludWl0eVRpbWU/ICAgeWFuZzpkYXRlLWFuZC10aW1lCiAgICAgICB8ICB8ICB8ICAgICAr LS1ybyBmaWVsZCoKICAgICAgIHwgIHwgIHwgICAgICAgICstLXJvIGllSWQ/ICAgICAgICAgICAg ICAgICBpZUlkVHlwZQogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcm8gaWVMZW5ndGg/ICAgICAg ICAgICAgIHVpbnQxNgogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcm8gaWVFbnRlcnByaXNlTnVt YmVyPyAgIHVpbnQzMgogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcm8gaXNGbG93S2V5PyAgICAg ICAgICAgIGVtcHR5CiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBpc1Njb3BlPyAgICAgICAg ICAgICAgZW1wdHkKICAgICAgIHwgIHwgICstLXJ3IGxvY2FsSVBBZGRyZXNzKiAgICAgICAgICAg aW5ldDppcC1hZGRyZXNzCiAgICAgICB8ICArLS1ydyBmaWxlUmVhZGVyKiBbbmFtZV0ge2ZpbGVS ZWFkZXJ9PwogICAgICAgfCAgfCAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAg IG5hbWVUeXBlCiAgICAgICB8ICB8ICArLS1ydyBmaWxlICAgICAgICAgICAgICAgICAgICAgICAg ICAgaW5ldDp1cmkKICAgICAgIHwgIHwgICstLXJvIGJ5dGVzPyAgICAgICAgICAgICAgICAgICAg ICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgfCAgfCAgKy0tcm8gbWVzc2FnZXM/ICAgICAgICAg ICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICB8ICB8ICArLS1ybyByZWNvcmRzPyAg ICAgICAgICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgIHwgIHwgICstLXJvIHRl bXBsYXRlcz8gICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXIzMgogICAgICAgfCAgfCAg Ky0tcm8gb3B0aW9uc1RlbXBsYXRlcz8gICAgICAgICAgICAgIHlhbmc6Y291bnRlcjMyCiAgICAg ICB8ICB8ICArLS1ybyBmaWxlUmVhZGVyRGlzY29udGludWl0eVRpbWU/ICAgeWFuZzpkYXRlLWFu ZC10aW1lCiAgICAgICB8ICB8ICArLS1ybyB0ZW1wbGF0ZSoKICAgICAgIHwgIHwgICAgICstLXJv IG9ic2VydmF0aW9uRG9tYWluSWQ/ICAgICAgICAgdWludDMyCiAgICAgICB8ICB8ICAgICArLS1y byB0ZW1wbGF0ZUlkPyAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgfCAgfCAgICAgKy0t cm8gc2V0SWQ/ICAgICAgICAgICAgICAgICAgICAgICB1aW50MTYKICAgICAgIHwgIHwgICAgICst LXJvIGFjY2Vzc1RpbWU/ICAgICAgICAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lCiAgICAg ICB8ICB8ICAgICArLS1ybyB0ZW1wbGF0ZURhdGFSZWNvcmRzPyAgICAgICAgIHlhbmc6Y291bnRl cjY0CiAgICAgICB8ICB8ICAgICArLS1ybyB0ZW1wbGF0ZURpc2NvbnRpbnVpdHlUaW1lPyAgIHlh bmc6ZGF0ZS1hbmQtdGltZQogICAgICAgfCAgfCAgICAgKy0tcm8gZmllbGQqCiAgICAgICB8ICB8 ICAgICAgICArLS1ybyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5cGUKICAgICAgIHwgIHwg ICAgICAgICstLXJvIGllTGVuZ3RoPyAgICAgICAgICAgICB1aW50MTYKICAgICAgIHwgIHwgICAg ICAgICstLXJvIGllRW50ZXJwcmlzZU51bWJlcj8gICB1aW50MzIKICAgICAgIHwgIHwgICAgICAg ICstLXJvIGlzRmxvd0tleT8gICAgICAgICAgICBlbXB0eQogICAgICAgfCAgfCAgICAgICAgKy0t cm8gaXNTY29wZT8gICAgICAgICAgICAgIGVtcHR5CiAgICAgICB8ICArLS1ydyBleHBvcnRpbmdQ cm9jZXNzKiAgIC0+IC9pcGZpeC9leHBvcnRpbmdQcm9jZXNzL25hbWUge2V4cG9ydGVyfT8KICAg ICAgICstLXJ3IG9ic2VydmF0aW9uUG9pbnQqIFtuYW1lXSB7bWV0ZXJ9PwogICAgICAgfCAgKy0t cncgbmFtZSAgICAgICAgICAgICAgICAgICBuYW1lVHlwZQogICAgICAgfCAgKy0tcm8gb2JzZXJ2 YXRpb25Qb2ludElkPyAgICB1aW50MzIKICAgICAgIHwgICstLXJ3IG9ic2VydmF0aW9uRG9tYWlu SWQgICAgdWludDMyCiAgICAgICB8ICArLS1ydyBpZk5hbWUqICAgICAgICAgICAgICAgIGlmTmFt ZVR5cGUKICAgICAgIHwgICstLXJ3IGlmSW5kZXgqICAgICAgICAgICAgICAgdWludDMyCiAgICAg ICB8ICArLS1ydyBlbnRQaHlzaWNhbE5hbWUqICAgICAgIHN0cmluZwogICAgICAgfCAgKy0tcncg ZW50UGh5c2ljYWxJbmRleCogICAgICB1aW50MzIKICAgICAgIHwgICstLXJ3IGRpcmVjdGlvbj8g ICAgICAgICAgICAgZGlyZWN0aW9uCiAgICAgICB8ICArLS1ydyBzZWxlY3Rpb25Qcm9jZXNzKiAg ICAgIC0+IC9pcGZpeC9zZWxlY3Rpb25Qcm9jZXNzL25hbWUKICAgICAgICstLXJ3IHNlbGVjdGlv blByb2Nlc3MqIFtuYW1lXSB7bWV0ZXJ9PwogICAgICAgfCAgKy0tcncgbmFtZSAgICAgICAgICAg ICAgICAgbmFtZVR5cGUKICAgICAgIHwgICstLXJ3IHNlbGVjdG9yKiBbbmFtZV0KICAgICAgIHwg IHwgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgICAgbmFtZVR5cGUKICAgICAgIHwg IHwgICstLXJ3IChNZXRob2QpCiAgICAgICB8ICB8ICB8ICArLS06KHNlbGVjdEFsbCkKICAgICAg IHwgIHwgIHwgIHwgICstLXJ3IHNlbGVjdEFsbD8gICAgICAgICAgICAgICAgICAgZW1wdHkKICAg ICAgIHwgIHwgIHwgICstLTooc2FtcENvdW50QmFzZWQpCiAgICAgICB8ICB8ICB8ICB8ICArLS1y dyBzYW1wQ291bnRCYXNlZCB7cHNhbXBTYW1wQ291bnRCYXNlZH0/CiAgICAgICB8ICB8ICB8ICB8 ICAgICArLS1ydyBwYWNrZXRJbnRlcnZhbCAgICB1aW50MzIKICAgICAgIHwgIHwgIHwgIHwgICAg ICstLXJ3IHBhY2tldFNwYWNlICAgICAgIHVpbnQzMgogICAgICAgfCAgfCAgfCAgKy0tOihzYW1w VGltZUJhc2VkKQogICAgICAgfCAgfCAgfCAgfCAgKy0tcncgc2FtcFRpbWVCYXNlZCB7cHNhbXBT YW1wVGltZUJhc2VkfT8KICAgICAgIHwgIHwgIHwgIHwgICAgICstLXJ3IHRpbWVJbnRlcnZhbCAg ICB1aW50MzIKICAgICAgIHwgIHwgIHwgIHwgICAgICstLXJ3IHRpbWVTcGFjZSAgICAgICB1aW50 MzIKICAgICAgIHwgIHwgIHwgICstLTooc2FtcFJhbmRPdXRPZk4pCiAgICAgICB8ICB8ICB8ICB8 ICArLS1ydyBzYW1wUmFuZE91dE9mTiB7cHNhbXBTYW1wUmFuZE91dE9mTn0/CiAgICAgICB8ICB8 ICB8ICB8ICAgICArLS1ydyBzaXplICAgICAgICAgIHVpbnQzMgogICAgICAgfCAgfCAgfCAgfCAg ICAgKy0tcncgcG9wdWxhdGlvbiAgICB1aW50MzIKICAgICAgIHwgIHwgIHwgICstLTooc2FtcFVu aVByb2IpCiAgICAgICB8ICB8ICB8ICB8ICArLS1ydyBzYW1wVW5pUHJvYiB7cHNhbXBTYW1wVW5p UHJvYn0/CiAgICAgICB8ICB8ICB8ICB8ICAgICArLS1ydyBwcm9iYWJpbGl0eSAgICBkZWNpbWFs NjQKICAgICAgIHwgIHwgIHwgICstLTooZmlsdGVyTWF0Y2gpCiAgICAgICB8ICB8ICB8ICB8ICAr LS1ydyBmaWx0ZXJNYXRjaCB7cHNhbXBGaWx0ZXJNYXRjaH0/CiAgICAgICB8ICB8ICB8ICB8ICAg ICArLS1ydyAobmFtZU9ySWQpCiAgICAgICB8ICB8ICB8ICB8ICAgICB8ICArLS06KGllTmFtZSkK ICAgICAgIHwgIHwgIHwgIHwgICAgIHwgIHwgICstLXJ3IGllTmFtZT8gICAgICAgICAgICAgICBp ZU5hbWVUeXBlCiAgICAgICB8ICB8ICB8ICB8ICAgICB8ICArLS06KGllSWQpCiAgICAgICB8ICB8 ICB8ICB8ICAgICB8ICAgICArLS1ydyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5cGUKICAg ICAgIHwgIHwgIHwgIHwgICAgICstLXJ3IGllRW50ZXJwcmlzZU51bWJlcj8gICB1aW50MzIKICAg ICAgIHwgIHwgIHwgIHwgICAgICstLXJ3IHZhbHVlICAgICAgICAgICAgICAgICBzdHJpbmcKICAg ICAgIHwgIHwgIHwgICstLTooZmlsdGVySGFzaCkKICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGZp bHRlckhhc2gge3BzYW1wRmlsdGVySGFzaH0/CiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ydyBo YXNoRnVuY3Rpb24/ICAgICAgIGlkZW50aXR5cmVmCiAgICAgICB8ICB8ICB8ICAgICAgICArLS1y dyBpbml0aWFsaXplclZhbHVlPyAgIHVpbnQ2NAogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcncg aXBQYXlsb2FkT2Zmc2V0PyAgICB1aW50NjQKICAgICAgIHwgIHwgIHwgICAgICAgICstLXJ3IGlw UGF5bG9hZFNpemU/ICAgICAgdWludDY0CiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ydyBkaWdl c3RPdXRwdXQ/ICAgICAgIGJvb2xlYW4KICAgICAgIHwgIHwgIHwgICAgICAgICstLXJvIG91dHB1 dFJhbmdlTWluPyAgICAgdWludDY0CiAgICAgICB8ICB8ICB8ICAgICAgICArLS1ybyBvdXRwdXRS YW5nZU1heD8gICAgIHVpbnQ2NAogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcncgc2VsZWN0ZWRS YW5nZSogW25hbWVdCiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBuYW1lICAgIG5hbWVU eXBlCiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBtaW4/ICAgIHVpbnQ2NAogICAgICAg fCAgfCAgfCAgICAgICAgICAgKy0tcncgbWF4PyAgICB1aW50NjQKICAgICAgIHwgIHwgICstLXJv IHBhY2tldHNPYnNlcnZlZD8gICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgIHwgIHwg ICstLXJvIHBhY2tldHNEcm9wcGVkPyAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAg IHwgIHwgICstLXJvIHNlbGVjdG9yRGlzY29udGludWl0eVRpbWU/ICAgeWFuZzpkYXRlLWFuZC10 aW1lCiAgICAgICB8ICArLS1ybyBzZWxlY3Rpb25TZXF1ZW5jZSoKICAgICAgIHwgIHwgICstLXJv IG9ic2VydmF0aW9uRG9tYWluSWQ/ICAgdWludDMyCiAgICAgICB8ICB8ICArLS1ybyBzZWxlY3Rp b25TZXF1ZW5jZUlkPyAgIHVpbnQ2NAogICAgICAgfCAgKy0tcncgY2FjaGU/ICAgICAgICAgICAg ICAgLT4gL2lwZml4L2NhY2hlL25hbWUKICAgICAgICstLXJ3IGNhY2hlKiBbbmFtZV0ge21ldGVy fT8KICAgICAgIHwgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICAgICAgbmFtZVR5cGUKICAg ICAgIHwgICstLXJvIG1ldGVyaW5nUHJvY2Vzc0lkPyAgICAgICAgdWludDMyCiAgICAgICB8ICAr LS1ybyBkYXRhUmVjb3Jkcz8gICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICB8ICAr LS1ybyBjYWNoZURpc2NvbnRpbnVpdHlUaW1lPyAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAg fCAgKy0tcncgKENhY2hlVHlwZSkKICAgICAgIHwgIHwgICstLTooaW1tZWRpYXRlQ2FjaGUpCiAg ICAgICB8ICB8ICB8ICArLS1ydyBpbW1lZGlhdGVDYWNoZSB7aW1tZWRpYXRlQ2FjaGV9PwogICAg ICAgfCAgfCAgfCAgICAgKy0tcncgY2FjaGVMYXlvdXQKICAgICAgIHwgIHwgIHwgICAgICAgICst LXJ3IGNhY2hlRmllbGQqIFtuYW1lXQogICAgICAgfCAgfCAgfCAgICAgICAgICAgKy0tcncgbmFt ZSAgICAgICAgICAgICAgICAgIG5hbWVUeXBlCiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1y dyAobmFtZU9ySWQpCiAgICAgICB8ICB8ICB8ICAgICAgICAgICB8ICArLS06KGllTmFtZSkKICAg ICAgIHwgIHwgIHwgICAgICAgICAgIHwgIHwgICstLXJ3IGllTmFtZT8gICAgICAgICAgICAgICBp ZU5hbWVUeXBlCiAgICAgICB8ICB8ICB8ICAgICAgICAgICB8ICArLS06KGllSWQpCiAgICAgICB8 ICB8ICB8ICAgICAgICAgICB8ICAgICArLS1ydyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5 cGUKICAgICAgIHwgIHwgIHwgICAgICAgICAgICstLXJ3IGllTGVuZ3RoPyAgICAgICAgICAgICB1 aW50MTYKICAgICAgIHwgIHwgIHwgICAgICAgICAgICstLXJ3IGllRW50ZXJwcmlzZU51bWJlcj8g ICB1aW50MzIKICAgICAgIHwgIHwgIHwgICAgICAgICAgICstLXJ3IGlzRmxvd0tleT8gICAgICAg ICAgICBlbXB0eQogICAgICAgfCAgfCAgKy0tOih0aW1lb3V0Q2FjaGUpCiAgICAgICB8ICB8ICB8 ICArLS1ydyB0aW1lb3V0Q2FjaGUge3RpbWVvdXRDYWNoZX0/CiAgICAgICB8ICB8ICB8ICAgICAr LS1ydyBtYXhGbG93cz8gICAgICAgICAgICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICArLS1y dyBhY3RpdmVUaW1lb3V0PyAgICAgICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICArLS1ydyBp ZGxlVGltZW91dD8gICAgICAgICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICArLS1ydyBleHBv cnRJbnRlcnZhbD8gICAgICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICArLS1ybyBhY3RpdmVG bG93cz8gICAgICAgICAgeWFuZzpnYXVnZTMyCiAgICAgICB8ICB8ICB8ICAgICArLS1ybyB1bnVz ZWRDYWNoZUVudHJpZXM/ICAgeWFuZzpnYXVnZTMyCiAgICAgICB8ICB8ICB8ICAgICArLS1ydyBj YWNoZUxheW91dAogICAgICAgfCAgfCAgfCAgICAgICAgKy0tcncgY2FjaGVGaWVsZCogW25hbWVd CiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAgbmFt ZVR5cGUKICAgICAgIHwgIHwgIHwgICAgICAgICAgICstLXJ3IChuYW1lT3JJZCkKICAgICAgIHwg IHwgIHwgICAgICAgICAgIHwgICstLTooaWVOYW1lKQogICAgICAgfCAgfCAgfCAgICAgICAgICAg fCAgfCAgKy0tcncgaWVOYW1lPyAgICAgICAgICAgICAgIGllTmFtZVR5cGUKICAgICAgIHwgIHwg IHwgICAgICAgICAgIHwgICstLTooaWVJZCkKICAgICAgIHwgIHwgIHwgICAgICAgICAgIHwgICAg ICstLXJ3IGllSWQ/ICAgICAgICAgICAgICAgICBpZUlkVHlwZQogICAgICAgfCAgfCAgfCAgICAg ICAgICAgKy0tcncgaWVMZW5ndGg/ICAgICAgICAgICAgIHVpbnQxNgogICAgICAgfCAgfCAgfCAg ICAgICAgICAgKy0tcncgaWVFbnRlcnByaXNlTnVtYmVyPyAgIHVpbnQzMgogICAgICAgfCAgfCAg fCAgICAgICAgICAgKy0tcncgaXNGbG93S2V5PyAgICAgICAgICAgIGVtcHR5CiAgICAgICB8ICB8 ICArLS06KG5hdHVyYWxDYWNoZSkKICAgICAgIHwgIHwgIHwgICstLXJ3IG5hdHVyYWxDYWNoZSB7 bmF0dXJhbENhY2hlfT8KICAgICAgIHwgIHwgIHwgICAgICstLXJ3IG1heEZsb3dzPyAgICAgICAg ICAgICB1aW50MzIKICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGFjdGl2ZVRpbWVvdXQ/ICAgICAg ICB1aW50MzIKICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGlkbGVUaW1lb3V0PyAgICAgICAgICB1 aW50MzIKICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGV4cG9ydEludGVydmFsPyAgICAgICB1aW50 MzIKICAgICAgIHwgIHwgIHwgICAgICstLXJvIGFjdGl2ZUZsb3dzPyAgICAgICAgICB5YW5nOmdh dWdlMzIKICAgICAgIHwgIHwgIHwgICAgICstLXJvIHVudXNlZENhY2hlRW50cmllcz8gICB5YW5n OmdhdWdlMzIKICAgICAgIHwgIHwgIHwgICAgICstLXJ3IGNhY2hlTGF5b3V0CiAgICAgICB8ICB8 ICB8ICAgICAgICArLS1ydyBjYWNoZUZpZWxkKiBbbmFtZV0KICAgICAgIHwgIHwgIHwgICAgICAg ICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgICAgICBuYW1lVHlwZQogICAgICAgfCAgfCAgfCAg ICAgICAgICAgKy0tcncgKG5hbWVPcklkKQogICAgICAgfCAgfCAgfCAgICAgICAgICAgfCAgKy0t OihpZU5hbWUpCiAgICAgICB8ICB8ICB8ICAgICAgICAgICB8ICB8ICArLS1ydyBpZU5hbWU/ICAg ICAgICAgICAgICAgaWVOYW1lVHlwZQogICAgICAgfCAgfCAgfCAgICAgICAgICAgfCAgKy0tOihp ZUlkKQogICAgICAgfCAgfCAgfCAgICAgICAgICAgfCAgICAgKy0tcncgaWVJZD8gICAgICAgICAg ICAgICAgIGllSWRUeXBlCiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBpZUxlbmd0aD8g ICAgICAgICAgICAgdWludDE2CiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBpZUVudGVy cHJpc2VOdW1iZXI/ICAgdWludDMyCiAgICAgICB8ICB8ICB8ICAgICAgICAgICArLS1ydyBpc0Zs b3dLZXk/ICAgICAgICAgICAgZW1wdHkKICAgICAgIHwgIHwgICstLToocGVybWFuZW50Q2FjaGUp CiAgICAgICB8ICB8ICAgICArLS1ydyBwZXJtYW5lbnRDYWNoZSB7cGVybWFuZW50Q2FjaGV9Pwog ICAgICAgfCAgfCAgICAgICAgKy0tcncgbWF4Rmxvd3M/ICAgICAgICAgICAgIHVpbnQzMgogICAg ICAgfCAgfCAgICAgICAgKy0tcncgYWN0aXZlVGltZW91dD8gICAgICAgIHVpbnQzMgogICAgICAg fCAgfCAgICAgICAgKy0tcncgaWRsZVRpbWVvdXQ/ICAgICAgICAgIHVpbnQzMgogICAgICAgfCAg fCAgICAgICAgKy0tcncgZXhwb3J0SW50ZXJ2YWw/ICAgICAgIHVpbnQzMgogICAgICAgfCAgfCAg ICAgICAgKy0tcm8gYWN0aXZlRmxvd3M/ICAgICAgICAgIHlhbmc6Z2F1Z2UzMgogICAgICAgfCAg fCAgICAgICAgKy0tcm8gdW51c2VkQ2FjaGVFbnRyaWVzPyAgIHlhbmc6Z2F1Z2UzMgogICAgICAg fCAgfCAgICAgICAgKy0tcncgY2FjaGVMYXlvdXQKICAgICAgIHwgIHwgICAgICAgICAgICstLXJ3 IGNhY2hlRmllbGQqIFtuYW1lXQogICAgICAgfCAgfCAgICAgICAgICAgICAgKy0tcncgbmFtZSAg ICAgICAgICAgICAgICAgIG5hbWVUeXBlCiAgICAgICB8ICB8ICAgICAgICAgICAgICArLS1ydyAo bmFtZU9ySWQpCiAgICAgICB8ICB8ICAgICAgICAgICAgICB8ICArLS06KGllTmFtZSkKICAgICAg IHwgIHwgICAgICAgICAgICAgIHwgIHwgICstLXJ3IGllTmFtZT8gICAgICAgICAgICAgICBpZU5h bWVUeXBlCiAgICAgICB8ICB8ICAgICAgICAgICAgICB8ICArLS06KGllSWQpCiAgICAgICB8ICB8 ICAgICAgICAgICAgICB8ICAgICArLS1ydyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5cGUK ICAgICAgIHwgIHwgICAgICAgICAgICAgICstLXJ3IGllTGVuZ3RoPyAgICAgICAgICAgICB1aW50 MTYKICAgICAgIHwgIHwgICAgICAgICAgICAgICstLXJ3IGllRW50ZXJwcmlzZU51bWJlcj8gICB1 aW50MzIKICAgICAgIHwgIHwgICAgICAgICAgICAgICstLXJ3IGlzRmxvd0tleT8gICAgICAgICAg ICBlbXB0eQogICAgICAgfCAgKy0tcncgZXhwb3J0aW5nUHJvY2VzcyogICAgICAgICAtPiAvaXBm aXgvZXhwb3J0aW5nUHJvY2Vzcy9uYW1lIHtleHBvcnRlcn0/CiAgICAgICArLS1ydyBleHBvcnRp bmdQcm9jZXNzKiBbbmFtZV0ge2V4cG9ydGVyfT8KICAgICAgICAgICstLXJ3IG5hbWUgICAgICAg ICAgICAgICAgICBuYW1lVHlwZQogICAgICAgICAgKy0tcm8gZXhwb3J0aW5nUHJvY2Vzc0lkPyAg IHVpbnQzMgogICAgICAgICAgKy0tcncgZXhwb3J0TW9kZT8gICAgICAgICAgIGlkZW50aXR5cmVm CiAgICAgICAgICArLS1ydyBkZXN0aW5hdGlvbiogW25hbWVdCiAgICAgICAgICB8ICArLS1ydyBu YW1lICAgICAgICAgICAgbmFtZVR5cGUKICAgICAgICAgIHwgICstLXJ3IChEZXN0aW5hdGlvblBh cmFtZXRlcnMpCiAgICAgICAgICB8ICAgICArLS06KHNjdHBFeHBvcnRlcikKICAgICAgICAgIHwg ICAgIHwgICstLXJ3IHNjdHBFeHBvcnRlcgogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgaXBm aXhWZXJzaW9uPyAgICAgICAgICAgICB1aW50MTYKICAgICAgICAgIHwgICAgIHwgICAgICstLXJ3 IGRlc3RpbmF0aW9uUG9ydD8gICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAgICAgfCAg ICAgfCAgICAgKy0tcncgKGluZGV4T3JOYW1lKT8KICAgICAgICAgIHwgICAgIHwgICAgIHwgICst LTooaWZJbmRleCkKICAgICAgICAgIHwgICAgIHwgICAgIHwgIHwgICstLXJ3IGlmSW5kZXg/ICAg ICAgICAgICAgICAgICAgdWludDMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS06KGlmTmFt ZSkKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJ3IGlmTmFtZT8gICAgICAgICAgICAg ICAgICAgc3RyaW5nCiAgICAgICAgICB8ICAgICB8ICAgICArLS1ydyBzZW5kQnVmZmVyU2l6ZT8g ICAgICAgICAgIHVpbnQzMgogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgcmF0ZUxpbWl0PyAg ICAgICAgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgICstLXJ3IHRyYW5zcG9y dExheWVyU2VjdXJpdHkhCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ydyBsb2NhbENlcnRp ZmljYXRpb25BdXRob3JpdHlETiogICAgc3RyaW5nCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAr LS1ydyBsb2NhbFN1YmplY3RETiogICAgICAgICAgICAgICAgICAgc3RyaW5nCiAgICAgICAgICB8 ICAgICB8ICAgICB8ICArLS1ydyBsb2NhbFN1YmplY3RGUUROKiAgICAgICAgICAgICAgICAgaW5l dDpkb21haW4tbmFtZQogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgcmVtb3RlQ2VydGlm aWNhdGlvbkF1dGhvcml0eUROKiAgIHN0cmluZwogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0t cncgcmVtb3RlU3ViamVjdEROKiAgICAgICAgICAgICAgICAgIHN0cmluZwogICAgICAgICAgfCAg ICAgfCAgICAgfCAgKy0tcncgcmVtb3RlU3ViamVjdEZRRE4qICAgICAgICAgICAgICAgIGluZXQ6 ZG9tYWluLW5hbWUKICAgICAgICAgIHwgICAgIHwgICAgICstLXJvIHRyYW5zcG9ydFNlc3Npb24K ICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIGlwZml4VmVyc2lvbj8gICAgICAgICAgICAg ICAgICAgICAgICB1aW50MTYKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHNvdXJjZUFk ZHJlc3M/ICAgICAgICAgICAgICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgICAgIHwg ICAgIHwgICAgIHwgICstLXJvIGRlc3RpbmF0aW9uQWRkcmVzcz8gICAgICAgICAgICAgICAgICBp bmV0OmlwLWFkZHJlc3MKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHNvdXJjZVBvcnQ/ ICAgICAgICAgICAgICAgICAgICAgICAgICBpbmV0OnBvcnQtbnVtYmVyCiAgICAgICAgICB8ICAg ICB8ICAgICB8ICArLS1ybyBkZXN0aW5hdGlvblBvcnQ/ICAgICAgICAgICAgICAgICAgICAgaW5l dDpwb3J0LW51bWJlcgogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcm8gc2N0cEFzc29jSWQ/ ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMgogICAgICAgICAgfCAgICAgfCAgICAgfCAg Ky0tcm8gc3RhdHVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRyYW5zcG9ydFNlc3Np b25TdGF0dXMKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHJhdGU/ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB5YW5nOmdhdWdlMzIKICAgICAgICAgIHwgICAgIHwgICAgIHwg ICstLXJvIGJ5dGVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2 NAogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcm8gbWVzc2FnZXM/ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1y byBkaXNjYXJkZWRNZXNzYWdlcz8gICAgICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAg ICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHJlY29yZHM/ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcm8gdGVt cGxhdGVzPyAgICAgICAgICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRlcjMyCiAgICAgICAg ICB8ICAgICB8ICAgICB8ICArLS1ybyBvcHRpb25zVGVtcGxhdGVzPyAgICAgICAgICAgICAgICAg ICAgeWFuZzpjb3VudGVyMzIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHRyYW5zcG9y dFNlc3Npb25TdGFydFRpbWU/ICAgICAgICAgICB5YW5nOmRhdGUtYW5kLXRpbWUKICAgICAgICAg IHwgICAgIHwgICAgIHwgICstLXJvIHRyYW5zcG9ydFNlc3Npb25EaXNjb250aW51aXR5VGltZT8g ICB5YW5nOmRhdGUtYW5kLXRpbWUKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHRlbXBs YXRlKgogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgKy0tcm8gb2JzZXJ2YXRpb25Eb21haW5J ZD8gICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJvIHRlbXBs YXRlSWQ/ICAgICAgICAgICAgICAgICAgdWludDE2CiAgICAgICAgICB8ICAgICB8ICAgICB8ICAg ICArLS1ybyBzZXRJZD8gICAgICAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgICAgfCAg ICAgfCAgICAgfCAgICAgKy0tcm8gYWNjZXNzVGltZT8gICAgICAgICAgICAgICAgICB5YW5nOmRh dGUtYW5kLXRpbWUKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJvIHRlbXBsYXRlRGF0 YVJlY29yZHM/ICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgICAgIHwgICAgIHwgICAgIHwg ICAgICstLXJvIHRlbXBsYXRlRGlzY29udGludWl0eVRpbWU/ICAgeWFuZzpkYXRlLWFuZC10aW1l CiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1ybyBmaWVsZCoKICAgICAgICAgIHwgICAg IHwgICAgIHwgICAgICAgICstLXJvIGllSWQ/ICAgICAgICAgICAgICAgICBpZUlkVHlwZQogICAg ICAgICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcm8gaWVMZW5ndGg/ICAgICAgICAgICAgIHVp bnQxNgogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcm8gaWVFbnRlcnByaXNlTnVt YmVyPyAgIHVpbnQzMgogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcm8gaXNGbG93 S2V5PyAgICAgICAgICAgIGVtcHR5CiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICAgICArLS1y byBpc1Njb3BlPyAgICAgICAgICAgICAgZW1wdHkKICAgICAgICAgIHwgICAgIHwgICAgICstLXJ3 IHNvdXJjZUlQQWRkcmVzcyogICAgICAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAgICAgICB8ICAg ICB8ICAgICArLS1ydyBkZXN0aW5hdGlvbklQQWRkcmVzcyogICAgIGluZXQ6aXAtYWRkcmVzcwog ICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgdGltZWRSZWxpYWJpbGl0eT8gICAgICAgICB1aW50 MzIKICAgICAgICAgIHwgICAgICstLToodWRwRXhwb3J0ZXIpCiAgICAgICAgICB8ICAgICB8ICAr LS1ydyB1ZHBFeHBvcnRlciB7dWRwVHJhbnNwb3J0fT8KICAgICAgICAgIHwgICAgIHwgICAgICst LXJ3IGlwZml4VmVyc2lvbj8gICAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgICAgfCAg ICAgfCAgICAgKy0tcncgZGVzdGluYXRpb25Qb3J0PyAgICAgICAgICAgICAgICAgaW5ldDpwb3J0 LW51bWJlcgogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgKGluZGV4T3JOYW1lKT8KICAgICAg ICAgIHwgICAgIHwgICAgIHwgICstLTooaWZJbmRleCkKICAgICAgICAgIHwgICAgIHwgICAgIHwg IHwgICstLXJ3IGlmSW5kZXg/ICAgICAgICAgICAgICAgICAgICAgICAgIHVpbnQzMgogICAgICAg ICAgfCAgICAgfCAgICAgfCAgKy0tOihpZk5hbWUpCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAg ICArLS1ydyBpZk5hbWU/ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcKICAgICAgICAg IHwgICAgIHwgICAgICstLXJ3IHNlbmRCdWZmZXJTaXplPyAgICAgICAgICAgICAgICAgIHVpbnQz MgogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgcmF0ZUxpbWl0PyAgICAgICAgICAgICAgICAg ICAgICAgdWludDMyCiAgICAgICAgICB8ICAgICB8ICAgICArLS1ydyB0cmFuc3BvcnRMYXllclNl Y3VyaXR5IQogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgbG9jYWxDZXJ0aWZpY2F0aW9u QXV0aG9yaXR5RE4qICAgIHN0cmluZwogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgbG9j YWxTdWJqZWN0RE4qICAgICAgICAgICAgICAgICAgIHN0cmluZwogICAgICAgICAgfCAgICAgfCAg ICAgfCAgKy0tcncgbG9jYWxTdWJqZWN0RlFETiogICAgICAgICAgICAgICAgIGluZXQ6ZG9tYWlu LW5hbWUKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJ3IHJlbW90ZUNlcnRpZmljYXRpb25B dXRob3JpdHlETiogICBzdHJpbmcKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJ3IHJlbW90 ZVN1YmplY3RETiogICAgICAgICAgICAgICAgICBzdHJpbmcKICAgICAgICAgIHwgICAgIHwgICAg IHwgICstLXJ3IHJlbW90ZVN1YmplY3RGUUROKiAgICAgICAgICAgICAgICBpbmV0OmRvbWFpbi1u YW1lCiAgICAgICAgICB8ICAgICB8ICAgICArLS1ybyB0cmFuc3BvcnRTZXNzaW9uCiAgICAgICAg ICB8ICAgICB8ICAgICB8ICArLS1ybyBpcGZpeFZlcnNpb24/ICAgICAgICAgICAgICAgICAgICAg ICAgdWludDE2CiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBzb3VyY2VBZGRyZXNzPyAg ICAgICAgICAgICAgICAgICAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAgICAgICB8ICAgICB8ICAg ICB8ICArLS1ybyBkZXN0aW5hdGlvbkFkZHJlc3M/ICAgICAgICAgICAgICAgICAgaW5ldDppcC1h ZGRyZXNzCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBzb3VyY2VQb3J0PyAgICAgICAg ICAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAgICAgfCAgICAgfCAgICAg fCAgKy0tcm8gZGVzdGluYXRpb25Qb3J0PyAgICAgICAgICAgICAgICAgICAgIGluZXQ6cG9ydC1u dW1iZXIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHNjdHBBc3NvY0lkPyAgICAgICAg ICAgICAgICAgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHN0 YXR1cz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0cmFuc3BvcnRTZXNzaW9uU3RhdHVz CiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyByYXRlPyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgeWFuZzpnYXVnZTMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBi eXRlcz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAg ICAgIHwgICAgIHwgICAgIHwgICstLXJvIG1lc3NhZ2VzPyAgICAgICAgICAgICAgICAgICAgICAg ICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcm8gZGlzY2Fy ZGVkTWVzc2FnZXM/ICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICAgICB8 ICAgICB8ICAgICB8ICArLS1ybyByZWNvcmRzPyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg eWFuZzpjb3VudGVyNjQKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHRlbXBsYXRlcz8g ICAgICAgICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXIzMgogICAgICAgICAgfCAgICAg fCAgICAgfCAgKy0tcm8gb3B0aW9uc1RlbXBsYXRlcz8gICAgICAgICAgICAgICAgICAgIHlhbmc6 Y291bnRlcjMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyB0cmFuc3BvcnRTZXNzaW9u U3RhcnRUaW1lPyAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lCiAgICAgICAgICB8ICAgICB8 ICAgICB8ICArLS1ybyB0cmFuc3BvcnRTZXNzaW9uRGlzY29udGludWl0eVRpbWU/ICAgeWFuZzpk YXRlLWFuZC10aW1lCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyB0ZW1wbGF0ZSoKICAg ICAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJvIG9ic2VydmF0aW9uRG9tYWluSWQ/ICAgICAg ICAgdWludDMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1ybyB0ZW1wbGF0ZUlkPyAg ICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgKy0tcm8g c2V0SWQ/ICAgICAgICAgICAgICAgICAgICAgICB1aW50MTYKICAgICAgICAgIHwgICAgIHwgICAg IHwgICAgICstLXJvIGFjY2Vzc1RpbWU/ICAgICAgICAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10 aW1lCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1ybyB0ZW1wbGF0ZURhdGFSZWNvcmRz PyAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1y byB0ZW1wbGF0ZURpc2NvbnRpbnVpdHlUaW1lPyAgIHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAg ICAgfCAgICAgfCAgICAgfCAgICAgKy0tcm8gZmllbGQqCiAgICAgICAgICB8ICAgICB8ICAgICB8 ICAgICAgICArLS1ybyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5cGUKICAgICAgICAgIHwg ICAgIHwgICAgIHwgICAgICAgICstLXJvIGllTGVuZ3RoPyAgICAgICAgICAgICB1aW50MTYKICAg ICAgICAgIHwgICAgIHwgICAgIHwgICAgICAgICstLXJvIGllRW50ZXJwcmlzZU51bWJlcj8gICB1 aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICAgICstLXJvIGlzRmxvd0tleT8gICAg ICAgICAgICBlbXB0eQogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgICAgKy0tcm8gaXNTY29w ZT8gICAgICAgICAgICAgIGVtcHR5CiAgICAgICAgICB8ICAgICB8ICAgICArLS1ydyBzb3VyY2VJ UEFkZHJlc3M/ICAgICAgICAgICAgICAgICBpbmV0OmlwLWFkZHJlc3MKICAgICAgICAgIHwgICAg IHwgICAgICstLXJ3IGRlc3RpbmF0aW9uSVBBZGRyZXNzICAgICAgICAgICAgIGluZXQ6aXAtYWRk cmVzcwogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgbWF4UGFja2V0U2l6ZT8gICAgICAgICAg ICAgICAgICAgdWludDE2CiAgICAgICAgICB8ICAgICB8ICAgICArLS1ydyB0ZW1wbGF0ZVJlZnJl c2hUaW1lb3V0PyAgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgICstLXJ3IG9w dGlvbnNUZW1wbGF0ZVJlZnJlc2hUaW1lb3V0PyAgIHVpbnQzMgogICAgICAgICAgfCAgICAgfCAg ICAgKy0tcncgdGVtcGxhdGVSZWZyZXNoUGFja2V0PyAgICAgICAgICAgdWludDMyCiAgICAgICAg ICB8ICAgICB8ICAgICArLS1ydyBvcHRpb25zVGVtcGxhdGVSZWZyZXNoUGFja2V0PyAgICB1aW50 MzIKICAgICAgICAgIHwgICAgICstLToodGNwRXhwb3J0ZXIpCiAgICAgICAgICB8ICAgICB8ICAr LS1ydyB0Y3BFeHBvcnRlciB7dGNwVHJhbnNwb3J0fT8KICAgICAgICAgIHwgICAgIHwgICAgICst LXJ3IGlwZml4VmVyc2lvbj8gICAgICAgICAgICAgdWludDE2CiAgICAgICAgICB8ICAgICB8ICAg ICArLS1ydyBkZXN0aW5hdGlvblBvcnQ/ICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXIKICAgICAg ICAgIHwgICAgIHwgICAgICstLXJ3IChpbmRleE9yTmFtZSk/CiAgICAgICAgICB8ICAgICB8ICAg ICB8ICArLS06KGlmSW5kZXgpCiAgICAgICAgICB8ICAgICB8ICAgICB8ICB8ICArLS1ydyBpZklu ZGV4PyAgICAgICAgICAgICAgICAgIHVpbnQzMgogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0t OihpZk5hbWUpCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1ydyBpZk5hbWU/ICAgICAg ICAgICAgICAgICAgIHN0cmluZwogICAgICAgICAgfCAgICAgfCAgICAgKy0tcncgc2VuZEJ1ZmZl clNpemU/ICAgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgICstLXJ3IHJhdGVM aW1pdD8gICAgICAgICAgICAgICAgdWludDMyCiAgICAgICAgICB8ICAgICB8ICAgICArLS1ydyB0 cmFuc3BvcnRMYXllclNlY3VyaXR5IQogICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgbG9j YWxDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5RE4qICAgIHN0cmluZwogICAgICAgICAgfCAgICAgfCAg ICAgfCAgKy0tcncgbG9jYWxTdWJqZWN0RE4qICAgICAgICAgICAgICAgICAgIHN0cmluZwogICAg ICAgICAgfCAgICAgfCAgICAgfCAgKy0tcncgbG9jYWxTdWJqZWN0RlFETiogICAgICAgICAgICAg ICAgIGluZXQ6ZG9tYWluLW5hbWUKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJ3IHJlbW90 ZUNlcnRpZmljYXRpb25BdXRob3JpdHlETiogICBzdHJpbmcKICAgICAgICAgIHwgICAgIHwgICAg IHwgICstLXJ3IHJlbW90ZVN1YmplY3RETiogICAgICAgICAgICAgICAgICBzdHJpbmcKICAgICAg ICAgIHwgICAgIHwgICAgIHwgICstLXJ3IHJlbW90ZVN1YmplY3RGUUROKiAgICAgICAgICAgICAg ICBpbmV0OmRvbWFpbi1uYW1lCiAgICAgICAgICB8ICAgICB8ICAgICArLS1ybyB0cmFuc3BvcnRT ZXNzaW9uCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBpcGZpeFZlcnNpb24/ICAgICAg ICAgICAgICAgICAgICAgICAgdWludDE2CiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBz b3VyY2VBZGRyZXNzPyAgICAgICAgICAgICAgICAgICAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAg ICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBkZXN0aW5hdGlvbkFkZHJlc3M/ICAgICAgICAgICAg ICAgICAgaW5ldDppcC1hZGRyZXNzCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyBzb3Vy Y2VQb3J0PyAgICAgICAgICAgICAgICAgICAgICAgICAgaW5ldDpwb3J0LW51bWJlcgogICAgICAg ICAgfCAgICAgfCAgICAgfCAgKy0tcm8gZGVzdGluYXRpb25Qb3J0PyAgICAgICAgICAgICAgICAg ICAgIGluZXQ6cG9ydC1udW1iZXIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIHNjdHBB c3NvY0lkPyAgICAgICAgICAgICAgICAgICAgICAgICB1aW50MzIKICAgICAgICAgIHwgICAgIHwg ICAgIHwgICstLXJvIHN0YXR1cz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0cmFuc3Bv cnRTZXNzaW9uU3RhdHVzCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyByYXRlPyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpnYXVnZTMyCiAgICAgICAgICB8ICAgICB8 ICAgICB8ICArLS1ybyBieXRlcz8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpj b3VudGVyNjQKICAgICAgICAgIHwgICAgIHwgICAgIHwgICstLXJvIG1lc3NhZ2VzPyAgICAgICAg ICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgICAgfCAgICAgfCAgICAg fCAgKy0tcm8gZGlzY2FyZGVkTWVzc2FnZXM/ICAgICAgICAgICAgICAgICAgIHlhbmc6Y291bnRl cjY0CiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyByZWNvcmRzPyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQKICAgICAgICAgIHwgICAgIHwgICAgIHwgICst LXJvIHRlbXBsYXRlcz8gICAgICAgICAgICAgICAgICAgICAgICAgICB5YW5nOmNvdW50ZXIzMgog ICAgICAgICAgfCAgICAgfCAgICAgfCAgKy0tcm8gb3B0aW9uc1RlbXBsYXRlcz8gICAgICAgICAg ICAgICAgICAgIHlhbmc6Y291bnRlcjMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyB0 cmFuc3BvcnRTZXNzaW9uU3RhcnRUaW1lPyAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lCiAg ICAgICAgICB8ICAgICB8ICAgICB8ICArLS1ybyB0cmFuc3BvcnRTZXNzaW9uRGlzY29udGludWl0 eVRpbWU/ICAgeWFuZzpkYXRlLWFuZC10aW1lCiAgICAgICAgICB8ICAgICB8ICAgICB8ICArLS1y byB0ZW1wbGF0ZSoKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICstLXJvIG9ic2VydmF0aW9u RG9tYWluSWQ/ICAgICAgICAgdWludDMyCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1y byB0ZW1wbGF0ZUlkPyAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgICAgfCAgICAgfCAg ICAgfCAgICAgKy0tcm8gc2V0SWQ/ICAgICAgICAgICAgICAgICAgICAgICB1aW50MTYKICAgICAg ICAgIHwgICAgIHwgICAgIHwgICAgICstLXJvIGFjY2Vzc1RpbWU/ICAgICAgICAgICAgICAgICAg eWFuZzpkYXRlLWFuZC10aW1lCiAgICAgICAgICB8ICAgICB8ICAgICB8ICAgICArLS1ybyB0ZW1w bGF0ZURhdGFSZWNvcmRzPyAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICAgICB8ICAgICB8 ICAgICB8ICAgICArLS1ybyB0ZW1wbGF0ZURpc2NvbnRpbnVpdHlUaW1lPyAgIHlhbmc6ZGF0ZS1h bmQtdGltZQogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAgKy0tcm8gZmllbGQqCiAgICAgICAg ICB8ICAgICB8ICAgICB8ICAgICAgICArLS1ybyBpZUlkPyAgICAgICAgICAgICAgICAgaWVJZFR5 cGUKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICAgICstLXJvIGllTGVuZ3RoPyAgICAgICAg ICAgICB1aW50MTYKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICAgICstLXJvIGllRW50ZXJw cmlzZU51bWJlcj8gICB1aW50MzIKICAgICAgICAgIHwgICAgIHwgICAgIHwgICAgICAgICstLXJv IGlzRmxvd0tleT8gICAgICAgICAgICBlbXB0eQogICAgICAgICAgfCAgICAgfCAgICAgfCAgICAg ICAgKy0tcm8gaXNTY29wZT8gICAgICAgICAgICAgIGVtcHR5CiAgICAgICAgICB8ICAgICB8ICAg ICArLS1ydyBzb3VyY2VJUEFkZHJlc3M/ICAgICAgICAgIGluZXQ6aXAtYWRkcmVzcwogICAgICAg ICAgfCAgICAgfCAgICAgKy0tcncgZGVzdGluYXRpb25JUEFkZHJlc3MgICAgICBpbmV0OmlwLWFk ZHJlc3MKICAgICAgICAgIHwgICAgICstLTooZmlsZVdyaXRlcikKICAgICAgICAgIHwgICAgICAg ICstLXJ3IGZpbGVXcml0ZXIge2ZpbGVXcml0ZXJ9PwogICAgICAgICAgfCAgICAgICAgICAgKy0t cncgaXBmaXhWZXJzaW9uPyAgICAgICAgICAgICAgICAgIHVpbnQxNgogICAgICAgICAgfCAgICAg ICAgICAgKy0tcncgZmlsZSAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZXQ6dXJpCiAgICAg ICAgICB8ICAgICAgICAgICArLS1ybyBieXRlcz8gICAgICAgICAgICAgICAgICAgICAgICAgeWFu Zzpjb3VudGVyNjQKICAgICAgICAgIHwgICAgICAgICAgICstLXJvIG1lc3NhZ2VzPyAgICAgICAg ICAgICAgICAgICAgICB5YW5nOmNvdW50ZXI2NAogICAgICAgICAgfCAgICAgICAgICAgKy0tcm8g ZGlzY2FyZGVkTWVzc2FnZXM/ICAgICAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAgICAgICAgICB8 ICAgICAgICAgICArLS1ybyByZWNvcmRzPyAgICAgICAgICAgICAgICAgICAgICAgeWFuZzpjb3Vu dGVyNjQKICAgICAgICAgIHwgICAgICAgICAgICstLXJvIHRlbXBsYXRlcz8gICAgICAgICAgICAg ICAgICAgICB5YW5nOmNvdW50ZXIzMgogICAgICAgICAgfCAgICAgICAgICAgKy0tcm8gb3B0aW9u c1RlbXBsYXRlcz8gICAgICAgICAgICAgIHlhbmc6Y291bnRlcjMyCiAgICAgICAgICB8ICAgICAg ICAgICArLS1ybyBmaWxlV3JpdGVyRGlzY29udGludWl0eVRpbWU/ICAgeWFuZzpkYXRlLWFuZC10 aW1lCiAgICAgICAgICB8ICAgICAgICAgICArLS1ybyB0ZW1wbGF0ZSoKICAgICAgICAgIHwgICAg ICAgICAgICAgICstLXJvIG9ic2VydmF0aW9uRG9tYWluSWQ/ICAgICAgICAgdWludDMyCiAgICAg ICAgICB8ICAgICAgICAgICAgICArLS1ybyB0ZW1wbGF0ZUlkPyAgICAgICAgICAgICAgICAgIHVp bnQxNgogICAgICAgICAgfCAgICAgICAgICAgICAgKy0tcm8gc2V0SWQ/ICAgICAgICAgICAgICAg ICAgICAgICB1aW50MTYKICAgICAgICAgIHwgICAgICAgICAgICAgICstLXJvIGFjY2Vzc1RpbWU/ ICAgICAgICAgICAgICAgICAgeWFuZzpkYXRlLWFuZC10aW1lCiAgICAgICAgICB8ICAgICAgICAg ICAgICArLS1ybyB0ZW1wbGF0ZURhdGFSZWNvcmRzPyAgICAgICAgIHlhbmc6Y291bnRlcjY0CiAg ICAgICAgICB8ICAgICAgICAgICAgICArLS1ybyB0ZW1wbGF0ZURpc2NvbnRpbnVpdHlUaW1lPyAg IHlhbmc6ZGF0ZS1hbmQtdGltZQogICAgICAgICAgfCAgICAgICAgICAgICAgKy0tcm8gZmllbGQq CiAgICAgICAgICB8ICAgICAgICAgICAgICAgICArLS1ybyBpZUlkPyAgICAgICAgICAgICAgICAg aWVJZFR5cGUKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICstLXJvIGllTGVuZ3RoPyAgICAg ICAgICAgICB1aW50MTYKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICstLXJvIGllRW50ZXJw cmlzZU51bWJlcj8gICB1aW50MzIKICAgICAgICAgIHwgICAgICAgICAgICAgICAgICstLXJvIGlz Rmxvd0tleT8gICAgICAgICAgICBlbXB0eQogICAgICAgICAgfCAgICAgICAgICAgICAgICAgKy0t cm8gaXNTY29wZT8gICAgICAgICAgICAgIGVtcHR5CiAgICAgICAgICArLS1ydyBvcHRpb25zKiBb bmFtZV0KICAgICAgICAgICAgICstLXJ3IG5hbWUgICAgICAgICAgICAgIG5hbWVUeXBlCiAgICAg ICAgICAgICArLS1ydyBvcHRpb25zVHlwZSAgICAgICBpZGVudGl0eXJlZgogICAgICAgICAgICAg Ky0tcncgb3B0aW9uc1RpbWVvdXQ/ICAgdWludDMyCg== --_004_BY2PR0501MB173415D2260734074DD777CA9C1F0BY2PR0501MB1734_-- From nobody Tue Jan 9 08:02:03 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F7B12D852 for ; Tue, 9 Jan 2018 08:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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-bpeYfAIi47 for ; Tue, 9 Jan 2018 08:01:59 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0660B126D0C for ; Tue, 9 Jan 2018 08:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18728; q=dns/txt; s=iport; t=1515513719; x=1516723319; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bAwJIz1s0C6voiP5lfha09pkngvDMyakO6xf3TkSt9I=; b=HpyTBMiipEpYQtV7Y868a9MTHNYcA92/+aEAjFWpg1hmzsod8ahWizaD 2A0nUWowMwyHc6YzcLgc+ELfTC3MWAiLB5dt8Efs4HONqFjB6Bme6c4no y0XnQ/e7JYht+kxRWBR3iOlGNSwaQOSplPRmjJkMc9h7+PHDFHM7kySCz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQBA5lRa/xbLJq1TChoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCSoFcdCePH6ktChgBDIUWAoR8FQEBAQEBAQEBAWsohSQCBAEBK0E?= =?us-ascii?q?bC0YnMAYBDAYCAQGKLRCxMCaKGwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhCCDb?= =?us-ascii?q?IFpKYMFgUmBZgGBQ4YnBYpaFYc3h0qJb4gKjTeCF4IAiAiHaophglSBXYgHgTw?= =?us-ascii?q?1I4FQMhoIGxU9giqCYIF4QDcBAYsoAQEB?= X-IronPort-AV: E=Sophos;i="5.46,336,1511827200"; d="scan'208,217";a="1310643" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jan 2018 16:01:57 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w09G1uJZ027673; Tue, 9 Jan 2018 16:01:56 GMT To: Marta Seda , "ipfix@ietf.org" References: From: Benoit Claise Message-ID: <91a9c743-8d4c-9fd9-c854-09ffeb09fc41@cisco.com> Date: Tue, 9 Jan 2018 17:01:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F6BE62A56D6563CDB3254B79" Content-Language: en-US Archived-At: Subject: Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 16:02:01 -0000 This is a multi-part message in MIME format. --------------F6BE62A56D6563CDB3254B79 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Marta, > > Hello, > > I am reaching out to the IETF IPFIX mailing list on some issues I > have run into with respect to RFC 6728 Configuration Data Model for > the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) > Protocols > > 1. RFC 6728 doesnt meet the latest Yang Best Practices > (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). > Leaf identifiers are camel case (e.g., destinationAddress instead > of destination-address). Are there any ongoing efforts to update > RFC 6728 to meet the latest best practices? > Not as far as I know. Regards, Benoit > > 1. > > Identifiers SHOULD follow a consistent naming pattern throughout the > > module. Only lower-case letters, numbers, and dashes SHOULD be used > > in identifier names. Upper-case characters and the underscore > > character MAY be used if the identifier represents a well-known value > > that uses these characters. > > Identifiers SHOULD include complete words and/or well-known acronyms > > or abbreviations. Child nodes within a container or list SHOULD NOT > > replicate the parent identifier. YANG identifiers are hierarchical > > and are only meant to be unique within the the set of sibling nodes > > defined in the same module namespace. > > It is permissible to use common identifiers such as "name" or "id" in > > data definition statements, especially if these data nodes share a > > common data type. > > Identifiers SHOULD NOT carry any special semantics that identify data > > modelling properties. Only YANG statements and YANG extension > > statements are designed to convey machine readable data modelling > > properties. For example, naming an object "config" or "state" does > > not change whether it is configuration data or state data. Only > > defined YANG statements or YANG extension statements can be used to > > assign semantics in a machine readable format in YANG. > > 2. I generated the RFC 6728 yang tree (see attached). The tcp and > udp exporting processes support a destinationIPAddress (line 400, > 455) which is mandatory. The type is inet:ip-address. > 1. A collector may be doing load balancing. Rather than managing > ip-addresses, the collector may be using DNS (an exporter > could resolve from the domain name where the collector is > located). > 2. The collector address may be learnt via other methods (e.g., > through DHCP options) > 3. A choice statement to select what method to use seems more > appropriate than what is presently in RFC 6728. For example > (use some shorthand) > > choice destination-method{ > > case destination-address{ > > leaf destination-address// rw with type inet:host > > } > > case dhcp-acquired-address{ > > container dcp-acquired-address{ > > leaf destination-ip-address inet-address //ro > > } > > } > > However I cant augment to ietf-ipfix > because destinationIPAddress is mandatory. Can the group suggest > methods to (a) change the destinationIPAddress type and (b) allow a > choice? > > 3. RFC 6728 mandates SCTP transport. I understand the logic behind > this (IETF prefers use of SCTP). There are situations where sctp > is unnecessary and not supported (e.g., point to point > connection). During netconf negotiations you can announce your > feature set (currently sctptransport is not a feature). Is there > ongoing work in updating RFC 6728 to include sctptransport as a > feature (so that the device can announce whether or not it > supports sctptransport)? > > Regards > > Marta Seda > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------F6BE62A56D6563CDB3254B79 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Marta,

Hello,

I am reaching out to the IETF IPFIX mailing list on some issues I have run into with respect to RFC 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols

  1. RFC 6728 doesnt meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address). Are there any ongoing efforts to update RFC 6728 to meet the latest best practices?
Not as far as I know.

Regards, Benoit

Identifiers SHOULD follow a consistent naming pattern throughout the

module. Only lower-case letters, numbers, and dashes SHOULD be used

in identifier names. Upper-case characters and the underscore

character MAY be used if the identifier represents a well-known value

that uses these characters.

Identifiers SHOULD include complete words and/or well-known acronyms

or abbreviations. Child nodes within a container or list SHOULD NOT

replicate the parent identifier. YANG identifiers are hierarchical

and are only meant to be unique within the the set of sibling nodes

defined in the same module namespace.

It is permissible to use common identifiers such as "name" or "id" in

data definition statements, especially if these data nodes share a

common data type.

Identifiers SHOULD NOT carry any special semantics that identify data

modelling properties. Only YANG statements and YANG extension

statements are designed to convey machine readable data modelling

properties. For example, naming an object "config" or "state" does

not change whether it is configuration data or state data. Only

defined YANG statements or YANG extension statements can be used to

assign semantics in a machine readable format in YANG.

  1. I generated the RFC 6728 yang tree (see attached). The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory. The type is inet:ip-address.
    1. A collector may be doing load balancing. Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located).
    2. The collector address may be learnt via other methods (e.g., through DHCP options)
    3. A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand)

choice destination-method{

case destination-address{

leaf destination-address// rw with type inet:host

}

case dhcp-acquired-address{

container dcp-acquired-address{

leaf destination-ip-address inet-address //ro

}

}

However I cant augment to ietf-ipfix because destinationIPAddress is mandatory. Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice?

  1. RFC 6728 mandates SCTP transport. I understand the logic behind this (IETF prefers use of SCTP). There are situations where sctp is unnecessary and not supported (e.g., point to point connection). During netconf negotiations you can announce your feature set (currently sctptransport is not a feature). Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)?

Regards

Marta Seda



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------F6BE62A56D6563CDB3254B79-- From nobody Tue Jan 9 13:55:20 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81951126BFD for ; Tue, 9 Jan 2018 13:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 0W1fZlqJ7wT9 for ; Tue, 9 Jan 2018 13:55:15 -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 C6AE11241FC for ; Tue, 9 Jan 2018 13:55:15 -0800 (PST) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id w09LlcaF041496; Tue, 9 Jan 2018 16:55:11 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 2fd5r10f5f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Jan 2018 16:55:11 -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 w09LtAv2006122; Tue, 9 Jan 2018 16:55:10 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w09Lt2R5006009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jan 2018 16:55:06 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Tue, 9 Jan 2018 21:54:49 GMT Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 29C65167F63; Tue, 9 Jan 2018 21:54:49 +0000 (GMT) Received: from gbcdccas01.intl.att.com (unknown [135.76.180.9]) by zlp27125.vci.att.com (Service) with ESMTPS id 91FBE16A59D; Tue, 9 Jan 2018 21:54:48 +0000 (GMT) Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Tue, 9 Jan 2018 21:54:46 +0000 From: "Aitken, Paul" To: "'Marta Seda'" , "'Benoit Claise'" CC: "'ipfix@ietf.org'" Thread-Topic: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion Thread-Index: AQHTiW6HO5P8h+Eqi0udiioCX0RAqKNryleQ Date: Tue, 9 Jan 2018 21:54:46 +0000 Message-ID: References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.160.174.88] Content-Type: multipart/alternative; boundary="_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-09_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801090297 Archived-At: Subject: Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 21:55:18 -0000 --_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marta, Benoit, 1. Are there efforts to update other RFCs to meet the latest YANG best prac= tices? 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t= he IETF. Is there a specific need to update RFC 6728 rather than just recog= nising it as a product of it's time? Note that it's > 5 years old. Also see @PJ inline: On 09/01/2018 16:01, Benoit Claise wrote: Hi Marta, Hello, I am reaching out to the IETF IPFIX mailing list on some issues I have run= into with respect to RFC 6728 "Configuration Data Model for the IP Flow In= formation Export (IPFIX) and Packet Sampling (PSAMP) Protocols" 1. RFC 6728 doesn't meet the latest Yang Best Practices (https://tools.i= etf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead = of destination-address). Are there any ongoing efforts to update RFC 6728 = to meet the latest best practices? Not as far as I know. Regards, Benoit 1. Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lower-case letters, numbers, and dashes SHOULD be used in identifier names. Upper-case characters and the underscore character MAY be used if the identifier represents a well-known value that uses these characters. Identifiers SHOULD include complete words and/or well-known acronyms or abbreviations. Child nodes within a container or list SHOULD NOT replicate the parent identifier. YANG identifiers are hierarchical and are only meant to be unique within the the set of sibling nodes defined in the same module namespace. It is permissible to use common identifiers such as "name" or "id" in data definition statements, especially if these data nodes share a common data type. Identifiers SHOULD NOT carry any special semantics that identify data modelling properties. Only YANG statements and YANG extension statements are designed to convey machine readable data modelling properties. For example, naming an object "config" or "state" does not change whether it is configuration data or state data. Only defined YANG statements or YANG extension statements can be used to assign semantics in a machine readable format in YANG. 1. I generated the RFC 6728 yang tree (see attached). The tcp and udp e= xporting processes support a destinationIPAddress (line 400, 455) which is = mandatory. The type is inet:ip-address. * A collector may be doing load balancing. Rather than managing ip-= addresses, the collector may be using DNS (an exporter could resolve from t= he domain name where the collector is located). @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab= ly a bad idea since templates need to be available on all collectors, and o= ut of step sequence numbers in the data records would cause spurious report= s of lost data. If DNS is used to obtain the collector's address, arguably = it should be a one-time lookup rather than incurring a DNS lookup per expor= t packet. 1. * * The collector address may be learnt via other methods (e.g., throu= gh DHCP options) * A choice statement to select what method to use seems more appropr= iate than what is presently in RFC 6728. For example (use some shorthand) choice destination-method{ case destination-address{ leaf destination-address// rw with type ine= t:host } case dhcp-acquired-address{ container dcp-acquired-address{ leaf destination-ip-address= inet-address //ro } } However I can't augment to ietf-ipfix becau= se destinationIPAddress is mandatory. Can the group suggest methods to (a)= change the destinationIPAddress type and (b) allow a choice? @PJ: The selection could also be done out of band so the exporter need not = know how the address is determined. eg a configuration system could determi= ne the address by any of these methods or otherwise, and impose that addres= s using the current model. 1. RFC 6728 mandates SCTP transport. I understand the logic behind this= (IETF prefers use of SCTP). There are situations where sctp is unnecessar= y and not supported (e.g., point to point connection). During netconf nego= tiations you can announce your feature set (currently sctptransport is not = a feature). Is there ongoing work in updating RFC 6728 to include sctptran= sport as a feature (so that the device can announce whether or not it suppo= rts sctptransport)? @PJ Same answer as point (2) above, ie is this necessary and useful? P. --_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marta, Benoit,


1. Are there efforts to update other RFCs to meet the latest YANG best prac= tices?

2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t= he IETF. Is there a specific need to update RFC 6728 rather than just recog= nising it as a product of it's time? Note that it's > 5 years old.<= /o:p>


Also see @PJ inline:


On 09/01/2018 16:01, Benoit Claise wrote:

Hi Marta,

Hello,

I am reaching out to the IETF IPFIX mailing list &nb= sp;on some issues I have run into with respect to RFC 6728 “Configura= tion Data Model for the IP Flow Information Export (IPFIX)  and Packet= Sampling (PSAMP) Protocols”

 

  1. R= FC 6728 doesn’t meet the latest Yang Best Practices (https://tools.ietf.org/html/draft= -ietf-netmod-rfc6087bis-15#section-4.3.1).   Leaf identifiers are camel case (e.g., destinationAddress instead of desti= nation-address).  Are there any ongoing efforts to update RFC 6728 to = meet the latest best practices?

Not as far as I know.

Regards, Benoit

  1. <= o:p> 

 

   Identifiers SHOULD follow = a consistent naming pattern throughout the

   module.  Only lower-c= ase letters, numbers, and dashes SHOULD be used

   in identifier names. = Upper-case characters and the underscore

   character MAY be used if t= he identifier represents a well-known value

   that uses these characters= .

 

   Identifiers SHOULD include= complete words and/or well-known acronyms

   or abbreviations.  Ch= ild nodes within a container or list SHOULD NOT

   replicate the parent ident= ifier.  YANG identifiers are hierarchical

   and are only meant to be u= nique within the the set of sibling nodes

   defined in the same module= namespace.

 

   It is permissible to use c= ommon identifiers such as "name" or "id" in=

   data definition statements= , especially if these data nodes share a

   common data type.

 

   Identifiers SHOULD NOT car= ry any special semantics that identify data

   modelling properties. = ; Only YANG statements and YANG extension

   statements are designed to= convey machine readable data modelling

   properties.  For exam= ple, naming an object "config" or "state" does

   not change whether it is c= onfiguration data or state data.  Only

   defined YANG statements or= YANG extension statements can be used to

   assign semantics in a mach= ine readable format in YANG.

 

  1. I= generated the RFC 6728 yang tree (see attached).  The tcp and udp exp= orting processes support a destinationIPAddress (line 400, 455) which is ma= ndatory.  The type is inet:ip-address. 
    1. A= collector may be doing load balancing.  Rather than managing ip-addre= sses, the collector may be using DNS (an exporter could resolve from the do= main name where the collector is located). 


@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab= ly a bad idea since templates need to be available on all collectors, and o= ut of step sequence numbers in the data records would cause spurious report= s of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup ra= ther than incurring a DNS lookup per export packet.


  1. <= o:p> 
    1. <= o:p> 
    2. The collector address may be learnt via other methods (= e.g., through DHCP options)
    3. A choice statement to select what= method to use seems more appropriate than what is presently in RFC 6728.&n= bsp; For example (use some shorthand)

 

choice destination-meth= od{

    = ;            case de= stination-address{

    = ;            &n= bsp;            = ;   leaf destination-address// rw with type inet:host

    = ;            }<= /o:p>

    = ;            case dh= cp-acquired-address{

    = ;            &n= bsp;            = ;   container dcp-acquired-address{

    = ;            &n= bsp;            = ;            &n= bsp;      leaf destination-ip-address inet-address= //ro

    = ;            }<= /o:p>

}

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;          However I can&#= 8217;t augment to ietf-ipfix because destinationIPAddress is mandatory.&nbs= p; Can the group suggest methods to (a) change the destinationIPAddress typ= e and (b) allow a choice?


@PJ: The selection could also be done out of band so the exporter need not = know how the address is determined. eg a configuration system could determi= ne the address by any of these methods or otherwise, and impose that addres= s using the current model.

 

  1. R= FC 6728 mandates SCTP transport.  I understand the logic behind this (= IETF prefers use of SCTP).  There are situations where sctp is unneces= sary and not supported (e.g., point to point connection).  During netconf negotiations you can announce your feature set (currently s= ctptransport is not a feature).  Is there ongoing work in updating RFC= 6728 to include sctptransport as a feature (so that the device can announc= e whether or not it supports sctptransport)?


@PJ Same answer as point (2) above, ie is this necessary and useful?

P.

--_000_A3625616CA873B4DAA779ABEFA624F1C8BE3CAgbcdcmbx03intlatt_-- From nobody Tue Jan 9 23:34:00 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EB21243F3 for ; Tue, 9 Jan 2018 23:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.511 X-Spam-Level: X-Spam-Status: No, score=-12.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 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 ybp18_eiTPH7 for ; Tue, 9 Jan 2018 23:33:56 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A564124319 for ; Tue, 9 Jan 2018 23:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28329; q=dns/txt; s=iport; t=1515569636; x=1516779236; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=cAihRJH6wta1Oaa9jieN8CSrzNWRkmqNigydtMYwN98=; b=HY5uEECQ1ZtW+Ut9WcRFZoy5eYqxUDN1OoTGMoe86YsTZC0TDZRAeHqv 6FXal4qh3Z+WuVy666T5BiEwuq/2dDwUx8ct7atSNGVLOJ/Lh5aZscWtm aIPCjivjr4Z++AmBW39Qka1aJS14hiC3gRfg7Bs+jaetzzM2l9vBEKED/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQBGwVVa/xbLJq1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSoFddCePH49FJ5lFCiKFGQKEfRUBAQEBAQEBAQFrKIUkAQU?= =?us-ascii?q?tQQsQCxggAQ1XBgEMCAEBii8QsUomihUBAQEBAQEBAQEBAQEBAQEBAQEBAQEYB?= =?us-ascii?q?YQgg2yBaSkMgnmBSYFmAQEXgStXhVAFilsVhzeHSolwiAqNOYIXggCIB4dqimG?= =?us-ascii?q?CVYFeiAeBPDUjJYErMhoIGxU9giuCGkWBeEA3AQEBAYtcAQEB?= X-IronPort-AV: E=Sophos;i="5.46,339,1511827200"; d="scan'208,217";a="1317030" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 07:33:53 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0A7XrET012042; Wed, 10 Jan 2018 07:33:53 GMT To: "Aitken, Paul" , "'Marta Seda'" Cc: "'ipfix@ietf.org'" References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> From: Benoit Claise Message-ID: Date: Wed, 10 Jan 2018 08:33:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C8F2BFE7A4363DF54C351EBA" Content-Language: en-US Archived-At: Subject: Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 07:34:00 -0000 This is a multi-part message in MIME format. --------------C8F2BFE7A4363DF54C351EBA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, > > Marta, Benoit, > > > 1. Are there efforts to update other RFCs to meet the latest YANG best > practices? > Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09 ) YANG modules > > > 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work > in the IETF. Is there a specific need to update RFC 6728 rather than > just recognising it as a product of it's time? > This type of feedback should come from implementation experience. Regards, Benoit > > Note that it's > 5 years old. > > > Also see @PJ inline: > > > On 09/01/2018 16:01, Benoit Claise wrote: > > Hi Marta, > > Hello, > > I am reaching out to the IETF IPFIX mailing list on some > issues I have run into with respect to RFC 6728 Configuration > Data Model for the IP Flow Information Export (IPFIX) and > Packet Sampling (PSAMP) Protocols > > 1. RFC 6728 doesnt meet the latest Yang Best Practices > (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1 > ). > Leaf identifiers are camel case (e.g., destinationAddress > instead of destination-address). Are there any ongoing > efforts to update RFC 6728 to meet the latest best practices? > > Not as far as I know. > > Regards, Benoit > > 2. > > Identifiers SHOULD follow a consistent naming pattern > throughout the > > module. Only lower-case letters, numbers, and dashes > SHOULD be used > > in identifier names. Upper-case characters and the underscore > > character MAY be used if the identifier represents a > well-known value > > that uses these characters. > > Identifiers SHOULD include complete words and/or well-known > acronyms > > or abbreviations. Child nodes within a container or list > SHOULD NOT > > replicate the parent identifier. YANG identifiers are > hierarchical > > and are only meant to be unique within the the set of > sibling nodes > > defined in the same module namespace. > > It is permissible to use common identifiers such as "name" > or "id" in > > data definition statements, especially if these data nodes > share a > > common data type. > > Identifiers SHOULD NOT carry any special semantics that > identify data > > modelling properties. Only YANG statements and YANG extension > > statements are designed to convey machine readable data > modelling > > properties. For example, naming an object "config" or > "state" does > > not change whether it is configuration data or state data. > Only > > defined YANG statements or YANG extension statements can be > used to > > assign semantics in a machine readable format in YANG. > > 3. I generated the RFC 6728 yang tree (see attached). The > tcp and udp exporting processes support a > destinationIPAddress (line 400, 455) which is mandatory. > The type is inet:ip-address. > > 1. A collector may be doing load balancing. Rather than > managing ip-addresses, the collector may be using DNS > (an exporter could resolve from the domain name where > the collector is located). > > > @PJ: Load balancing and DNS are independent. Load balancing IPFIX is > probably a bad idea since templates need to be available on all > collectors, and out of step sequence numbers in the data records would > cause spurious reports of lost data. If DNS is used to obtain the > collector's address, arguably it should be a one-time lookup rather > than incurring a DNS lookup per export packet. > > > 4. > > 1. > 2. The collector address may be learnt via other methods > (e.g., through DHCP options) > 3. A choice statement to select what method to use seems > more appropriate than what is presently in RFC 6728. > For example (use some shorthand) > > choice destination-method{ > > case destination-address{ > > leaf destination-address// rw with type inet:host > > } > > case dhcp-acquired-address{ > > container dcp-acquired-address{ > > leaf destination-ip-address inet-address //ro > > } > > } > > However I cant augment to ietf-ipfix because > destinationIPAddress is mandatory. Can the group suggest > methods to (a) change the destinationIPAddress type and (b) > allow a choice? > > > @PJ: The selection could also be done out of band so the exporter need > not know how the address is determined. eg a configuration system > could determine the address by any of these methods or otherwise, and > impose that address using the current model. > > 5. RFC 6728 mandates SCTP transport. I understand the logic > behind this (IETF prefers use of SCTP). There are > situations where sctp is unnecessary and not supported > (e.g., point to point connection). During netconf > negotiations you can announce your feature set (currently > sctptransport is not a feature). Is there ongoing work in > updating RFC 6728 to include sctptransport as a feature > (so that the device can announce whether or not it > supports sctptransport)? > > > @PJ Same answer as point (2) above, ie is this necessary and useful? > > P. > --------------C8F2BFE7A4363DF54C351EBA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,

Marta, Benoit,


1. Are there efforts to update other RFCs to meet the latest YANG best practices?

Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09) YANG modules


2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time?

This type of feedback should come from implementation experience.

Regards, Benoit

Note that it's > 5 years old.


Also see @PJ inline:


On 09/01/2018 16:01, Benoit Claise wrote:

Hi Marta,

Hello,

I am reaching out to the IETF IPFIX mailing list on some issues I have run into with respect to RFC 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols

  1. RFC 6728 doesnt meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address). Are there any ongoing efforts to update RFC 6728 to meet the latest best practices?

Not as far as I know.

Regards, Benoit

Identifiers SHOULD follow a consistent naming pattern throughout the

module. Only lower-case letters, numbers, and dashes SHOULD be used

in identifier names. Upper-case characters and the underscore

character MAY be used if the identifier represents a well-known value

that uses these characters.

Identifiers SHOULD include complete words and/or well-known acronyms

or abbreviations. Child nodes within a container or list SHOULD NOT

replicate the parent identifier. YANG identifiers are hierarchical

and are only meant to be unique within the the set of sibling nodes

defined in the same module namespace.

It is permissible to use common identifiers such as "name" or "id" in

data definition statements, especially if these data nodes share a

common data type.

Identifiers SHOULD NOT carry any special semantics that identify data

modelling properties. Only YANG statements and YANG extension

statements are designed to convey machine readable data modelling

properties. For example, naming an object "config" or "state" does

not change whether it is configuration data or state data. Only

defined YANG statements or YANG extension statements can be used to

assign semantics in a machine readable format in YANG.

  1. I generated the RFC 6728 yang tree (see attached). The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory. The type is inet:ip-address.
    1. A collector may be doing load balancing. Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located).


@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet.


    2. The collector address may be learnt via other methods (e.g., through DHCP options)
    3. A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand)

choice destination-method{

case destination-address{

leaf destination-address// rw with type inet:host

}

case dhcp-acquired-address{

container dcp-acquired-address{

leaf destination-ip-address inet-address //ro

}

}

However I cant augment to ietf-ipfix because destinationIPAddress is mandatory. Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice?


@PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model.

  1. RFC 6728 mandates SCTP transport. I understand the logic behind this (IETF prefers use of SCTP). There are situations where sctp is unnecessary and not supported (e.g., point to point connection). During netconf negotiations you can announce your feature set (currently sctptransport is not a feature). Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)?


@PJ Same answer as point (2) above, ie is this necessary and useful?

P.


--------------C8F2BFE7A4363DF54C351EBA-- From nobody Sat Jan 13 01:43:47 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2FD126D74 for ; Sat, 13 Jan 2018 01:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, T_KAM_HTML_FONT_INVALID=0.01, 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 eJ-uPVqyv9Nb for ; Sat, 13 Jan 2018 01:43:42 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD301200C1 for ; Sat, 13 Jan 2018 01:43:42 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.net.in.tum.de (Postfix) with ESMTPSA id 173CB28; Sat, 13 Jan 2018 10:43:34 +0100 (CET) To: Benoit Claise , "Aitken, Paul" , 'Marta Seda' Cc: "'ipfix@ietf.org'" References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> From: Gerhard Muenz Message-ID: <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> Date: Sat, 13 Jan 2018 10:43:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------184F48FA7CC1D6397CB01FC2" Content-Language: en-US Archived-At: Subject: Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jan 2018 09:43:46 -0000 This is a multi-part message in MIME format. --------------184F48FA7CC1D6397CB01FC2 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Marta, all, A few additional thoughts regarding your questions: 1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist. 2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set. 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#section-10.1 Best regards, Gerhard On 10.01.2018 08:33, Benoit Claise wrote: > Hi, >> >> Marta, Benoit, >> >> >> 1. Are there efforts to update other RFCs to meet the latest YANG >> best practices? >> > Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ > The goal is to specify NMDA-compliant > (draft-ietf-netmod-revised-datastores-09 > ) > YANG modules >> >> >> 2. Since the IPFIX WG closed, there has been little ongoing IPFIX >> work in the IETF. Is there a specific need to update RFC 6728 rather >> than just recognising it as a product of it's time? >> > This type of feedback should come from implementation experience. > > Regards, Benoit >> >> Note that it's > 5 years old. >> >> >> Also see @PJ inline: >> >> >> On 09/01/2018 16:01, Benoit Claise wrote: >> >> Hi Marta, >> >> Hello, >> >> I am reaching out to the IETF IPFIX mailing list on some >> issues I have run into with respect to RFC 6728 >> Configuration Data Model for the IP Flow Information Export >> (IPFIX) and Packet Sampling (PSAMP) Protocols >> >> 1. RFC 6728 doesnt meet the latest Yang Best Practices >> (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1 >> ). >> Leaf identifiers are camel case (e.g., destinationAddress >> instead of destination-address). Are there any ongoing >> efforts to update RFC 6728 to meet the latest best practices? >> >> Not as far as I know. >> >> Regards, Benoit >> >> 2. >> >> Identifiers SHOULD follow a consistent naming pattern >> throughout the >> >> module. Only lower-case letters, numbers, and dashes >> SHOULD be used >> >> in identifier names. Upper-case characters and the underscore >> >> character MAY be used if the identifier represents a >> well-known value >> >> that uses these characters. >> >> Identifiers SHOULD include complete words and/or >> well-known acronyms >> >> or abbreviations. Child nodes within a container or list >> SHOULD NOT >> >> replicate the parent identifier. YANG identifiers are >> hierarchical >> >> and are only meant to be unique within the the set of >> sibling nodes >> >> defined in the same module namespace. >> >> It is permissible to use common identifiers such as "name" >> or "id" in >> >> data definition statements, especially if these data nodes >> share a >> >> common data type. >> >> Identifiers SHOULD NOT carry any special semantics that >> identify data >> >> modelling properties. Only YANG statements and YANG extension >> >> statements are designed to convey machine readable data >> modelling >> >> properties. For example, naming an object "config" or >> "state" does >> >> not change whether it is configuration data or state >> data. Only >> >> defined YANG statements or YANG extension statements can >> be used to >> >> assign semantics in a machine readable format in YANG. >> >> 3. I generated the RFC 6728 yang tree (see attached). The >> tcp and udp exporting processes support a >> destinationIPAddress (line 400, 455) which is mandatory. >> The type is inet:ip-address. >> >> 1. A collector may be doing load balancing. Rather than >> managing ip-addresses, the collector may be using DNS >> (an exporter could resolve from the domain name where >> the collector is located). >> >> >> @PJ: Load balancing and DNS are independent. Load balancing IPFIX is >> probably a bad idea since templates need to be available on all >> collectors, and out of step sequence numbers in the data records >> would cause spurious reports of lost data. If DNS is used to obtain >> the collector's address, arguably it should be a one-time lookup >> rather than incurring a DNS lookup per export packet. >> >> >> 4. >> >> 1. >> 2. The collector address may be learnt via other methods >> (e.g., through DHCP options) >> 3. A choice statement to select what method to use seems >> more appropriate than what is presently in RFC 6728. >> For example (use some shorthand) >> >> choice destination-method{ >> >> case destination-address{ >> >> leaf destination-address// rw with type inet:host >> >> } >> >> case dhcp-acquired-address{ >> >> container dcp-acquired-address{ >> >> leaf destination-ip-address inet-address //ro >> >> } >> >> } >> >> However I cant augment to ietf-ipfix because >> destinationIPAddress is mandatory. Can the group suggest >> methods to (a) change the destinationIPAddress type and (b) >> allow a choice? >> >> >> @PJ: The selection could also be done out of band so the exporter >> need not know how the address is determined. eg a configuration >> system could determine the address by any of these methods or >> otherwise, and impose that address using the current model. >> >> 5. RFC 6728 mandates SCTP transport. I understand the logic >> behind this (IETF prefers use of SCTP). There are >> situations where sctp is unnecessary and not supported >> (e.g., point to point connection). During netconf >> negotiations you can announce your feature set (currently >> sctptransport is not a feature). Is there ongoing work >> in updating RFC 6728 to include sctptransport as a >> feature (so that the device can announce whether or not >> it supports sctptransport)? >> >> >> @PJ Same answer as point (2) above, ie is this necessary and useful? >> >> P. >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------184F48FA7CC1D6397CB01FC2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Marta, all,

A few additional thoughts regarding your questions:

1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist.

2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set.

3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#section-10.1

Best regards,
Gerhard



On 10.01.2018 08:33, Benoit Claise wrote:
Hi,

Marta, Benoit,


1. Are there efforts to update other RFCs to meet the latest YANG best practices?

Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09) YANG modules


2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time?

This type of feedback should come from implementation experience.

Regards, Benoit

Note that it's > 5 years old.


Also see @PJ inline:


On 09/01/2018 16:01, Benoit Claise wrote:

Hi Marta,

Hello,

I am reaching out to the IETF IPFIX mailing list on some issues I have run into with respect to RFC 6728 Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols

  1. RFC 6728 doesnt meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address). Are there any ongoing efforts to update RFC 6728 to meet the latest best practices?

Not as far as I know.

Regards, Benoit

Identifiers SHOULD follow a consistent naming pattern throughout the

module. Only lower-case letters, numbers, and dashes SHOULD be used

in identifier names. Upper-case characters and the underscore

character MAY be used if the identifier represents a well-known value

that uses these characters.

Identifiers SHOULD include complete words and/or well-known acronyms

or abbreviations. Child nodes within a container or list SHOULD NOT

replicate the parent identifier. YANG identifiers are hierarchical

and are only meant to be unique within the the set of sibling nodes

defined in the same module namespace.

It is permissible to use common identifiers such as "name" or "id" in

data definition statements, especially if these data nodes share a

common data type.

Identifiers SHOULD NOT carry any special semantics that identify data

modelling properties. Only YANG statements and YANG extension

statements are designed to convey machine readable data modelling

properties. For example, naming an object "config" or "state" does

not change whether it is configuration data or state data. Only

defined YANG statements or YANG extension statements can be used to

assign semantics in a machine readable format in YANG.

  1. I generated the RFC 6728 yang tree (see attached). The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory. The type is inet:ip-address.
    1. A collector may be doing load balancing. Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located).


@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet.


    2. The collector address may be learnt via other methods (e.g., through DHCP options)
    3. A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand)

choice destination-method{

case destination-address{

leaf destination-address// rw with type inet:host

}

case dhcp-acquired-address{

container dcp-acquired-address{

leaf destination-ip-address inet-address //ro

}

}

However I cant augment to ietf-ipfix because destinationIPAddress is mandatory. Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice?


@PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model.

  1. RFC 6728 mandates SCTP transport. I understand the logic behind this (IETF prefers use of SCTP). There are situations where sctp is unnecessary and not supported (e.g., point to point connection). During netconf negotiations you can announce your feature set (currently sctptransport is not a feature). Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)?


@PJ Same answer as point (2) above, ie is this necessary and useful?

P.




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------184F48FA7CC1D6397CB01FC2-- From nobody Mon Jan 15 10:09:29 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981E512EADB for ; Mon, 15 Jan 2018 10:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 U0zk6WTwxkzG for ; Mon, 15 Jan 2018 10:09:23 -0800 (PST) Received: from mx1.plixer.com (mx1.plixer.com [64.140.243.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69E7C12EAEE for ; Mon, 15 Jan 2018 10:09:23 -0800 (PST) Received: from PLXRDC01.plxr.local ([::1]) by PLXRDC01.plxr.local ([::1]) with mapi id 14.03.0351.000; Mon, 15 Jan 2018 13:09:21 -0500 From: Andrew Feren To: Gerhard Muenz , Benoit Claise , "Aitken, Paul" , 'Marta Seda' CC: "'ipfix@ietf.org'" Thread-Topic: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion Thread-Index: AQHTiW6H/UhqDUnGS1y9w5Kq6vABEqNryleQgAFBWICABNs4AIADXPMD Date: Mon, 15 Jan 2018 18:09:20 +0000 Message-ID: <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> , <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> In-Reply-To: <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.140.243.149] Content-Type: multipart/alternative; boundary="_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 18:09:27 -0000 --_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In particular renaming identifiers would break any implementations of RFC 7= 373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract = Data Types". -Andrew ________________________________ From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz [muenz@net.= in.tum.de] Sent: Saturday, January 13, 2018 4:43 AM To: Benoit Claise; Aitken, Paul; 'Marta Seda' Cc: 'ipfix@ietf.org' Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion Marta, all, A few additional thoughts regarding your questions: 1) I would not expect that not following current naming convention hinders = implementation of RFC 6728. On the other hand, if we change just the names = of the identifiers, we lose interoperability with older implementations tha= t may exist. 2) I think that it is reasonable that destinationIPAddress is mandatory bec= ause network management systems should be able to query the IP address to w= hich an Exporting Process sends data. As Paul stated, RFC 6728 does not say= how the destination IP address is set. 3) SCTP is still a mandatory transport for a compliant implementation of an= IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#sect= ion-10.1 Best regards, Gerhard On 10.01.2018 08:33, Benoit Claise wrote: Hi, Marta, Benoit, 1. Are there efforts to update other RFCs to meet the latest YANG best prac= tices? Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores= -09) YANG modules 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t= he IETF. Is there a specific need to update RFC 6728 rather than just recog= nising it as a product of it's time? This type of feedback should come from implementation experience. Regards, Benoit Note that it's > 5 years old. Also see @PJ inline: On 09/01/2018 16:01, Benoit Claise wrote: Hi Marta, Hello, I am reaching out to the IETF IPFIX mailing list on some issues I have run= into with respect to RFC 6728 =93Configuration Data Model for the IP Flow = Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols=94 1. RFC 6728 doesn=92t meet the latest Yang Best Practices (https://tools= .ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are c= amel case (e.g., destinationAddress instead of destination-address). Are t= here any ongoing efforts to update RFC 6728 to meet the latest best practic= es? Not as far as I know. Regards, Benoit 1. Identifiers SHOULD follow a consistent naming pattern throughout the module. Only lower-case letters, numbers, and dashes SHOULD be used in identifier names. Upper-case characters and the underscore character MAY be used if the identifier represents a well-known value that uses these characters. Identifiers SHOULD include complete words and/or well-known acronyms or abbreviations. Child nodes within a container or list SHOULD NOT replicate the parent identifier. YANG identifiers are hierarchical and are only meant to be unique within the the set of sibling nodes defined in the same module namespace. It is permissible to use common identifiers such as "name" or "id" in data definition statements, especially if these data nodes share a common data type. Identifiers SHOULD NOT carry any special semantics that identify data modelling properties. Only YANG statements and YANG extension statements are designed to convey machine readable data modelling properties. For example, naming an object "config" or "state" does not change whether it is configuration data or state data. Only defined YANG statements or YANG extension statements can be used to assign semantics in a machine readable format in YANG. 1. I generated the RFC 6728 yang tree (see attached). The tcp and udp e= xporting processes support a destinationIPAddress (line 400, 455) which is = mandatory. The type is inet:ip-address. * A collector may be doing load balancing. Rather than managing ip-= addresses, the collector may be using DNS (an exporter could resolve from t= he domain name where the collector is located). @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab= ly a bad idea since templates need to be available on all collectors, and o= ut of step sequence numbers in the data records would cause spurious report= s of lost data. If DNS is used to obtain the collector's address, arguably = it should be a one-time lookup rather than incurring a DNS lookup per expor= t packet. 1. * * The collector address may be learnt via other methods (e.g., throu= gh DHCP options) * A choice statement to select what method to use seems more appropr= iate than what is presently in RFC 6728. For example (use some shorthand) choice destination-method{ case destination-address{ leaf destination-address// rw with type ine= t:host } case dhcp-acquired-address{ container dcp-acquired-address{ leaf destination-ip-address= inet-address //ro } } However I can=92t augment to ietf-ipfix bec= ause destinationIPAddress is mandatory. Can the group suggest methods to (= a) change the destinationIPAddress type and (b) allow a choice? @PJ: The selection could also be done out of band so the exporter need not = know how the address is determined. eg a configuration system could determi= ne the address by any of these methods or otherwise, and impose that addres= s using the current model. 1. RFC 6728 mandates SCTP transport. I understand the logic behind this= (IETF prefers use of SCTP). There are situations where sctp is unnecessar= y and not supported (e.g., point to point connection). During netconf nego= tiations you can announce your feature set (currently sctptransport is not = a feature). Is there ongoing work in updating RFC 6728 to include sctptran= sport as a feature (so that the device can announce whether or not it suppo= rts sctptransport)? @PJ Same answer as point (2) above, ie is this necessary and useful? P. _______________________________________________ IPFIX mailing list IPFIX@ietf.org https://www.ietf.org/mailman/listinfo/ipfix --_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In particular renaming identifiers would break any implementations o= f RFC 7373 "Textual Representation of IP Flow Information Export (IPFI= X) Abstract Data Types".

-Andrew

From: IPFIX [ipfix-bounces@ietf.org] on beh= alf of Gerhard Muenz [muenz@net.in.tum.de]
Sent: Saturday, January 13, 2018 4:43 AM
To: Benoit Claise; Aitken, Paul; 'Marta Seda'
Cc: 'ipfix@ietf.org'
Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion


Marta, all,

A few additional thoughts regarding your questions:

1) I would not expect that not following current naming convention hinders = implementation of RFC 6728. On the other hand, if we change just the names = of the identifiers, we lose interoperability with older implementations tha= t may exist.

2) I think that it is reasonable that destinationIPAddress is mandatory bec= ause network management systems should be able to query the IP address to w= hich an Exporting Process sends data. As Paul stated, RFC 6728 does not say= how the destination IP address is set.

3) SCTP is still a mandatory transport for a compliant implementation of an= IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#section-10.1

Best regards,
Gerhard



On 10.01.2018 08:33, Benoit Claise wrote:
Hi,

Marta, Benoit,


1. Are there efforts to update other RFCs to meet the latest YANG best prac= tices?

Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/
The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09) YANG modules


2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in t= he IETF. Is there a specific need to update RFC 6728 rather than just recog= nising it as a product of it's time?

This type of feedback should come from implementation experience.

Regards, Benoit

Note that it's > 5 years old.


Also see @PJ inline:


On 09/01/2018 16:01, Benoit Claise wrote:

Hi Marta,

Hello,

I am reaching out to the IETF IPFIX mailing list &nb= sp;on some issues I have run into with respect to RFC 6728 =93Configuration= Data Model for the IP Flow Information Export (IPFIX)  and Packet Sam= pling (PSAMP) Protocols=94

 

  1. RFC 6728 doesn=92t meet t= he latest Yang Best Practices (https://tools.ietf.= org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1).   Leaf identifiers are camel case (e.g., destinationAddress instead of desti= nation-address).  Are there any ongoing efforts to update RFC 6728 to = meet the latest best practices?

Not as far as I know.

Regards, Benoit

  1.  

 

   Identifiers SHOULD fol= low a consistent naming pattern throughout the

   module.  Only low= er-case letters, numbers, and dashes SHOULD be used

   in identifier names.&n= bsp; Upper-case characters and the underscore

   character MAY be used = if the identifier represents a well-known value

   that uses these charac= ters.

 

   Identifiers SHOULD inc= lude complete words and/or well-known acronyms

   or abbreviations. = ; Child nodes within a container or list SHOULD NOT

   replicate the parent i= dentifier.  YANG identifiers are hierarchical

   and are only meant to = be unique within the the set of sibling nodes

   defined in the same mo= dule namespace.

 

   It is permissible to u= se common identifiers such as "name" or "id" in<= /p>

   data definition statem= ents, especially if these data nodes share a

   common data type.

 

   Identifiers SHOULD NOT= carry any special semantics that identify data

   modelling properties.&= nbsp; Only YANG statements and YANG extension

   statements are designe= d to convey machine readable data modelling

   properties.  For = example, naming an object "config" or "state" does

   not change whether it = is configuration data or state data.  Only

   defined YANG statement= s or YANG extension statements can be used to

   assign semantics in a = machine readable format in YANG.

 

  1. I generated the RFC 6728 = yang tree (see attached).  The tcp and udp exporting processes support= a destinationIPAddress (line 400, 455) which is mandatory.  The type = is inet:ip-address. 
    1. A collector may be doing = load balancing.  Rather than managing ip-addresses, the collector may = be using DNS (an exporter could resolve from the domain name where the coll= ector is located). 


@PJ: Load balancing and DNS are independent. Load balancing IPFIX is probab= ly a bad idea since templates need to be available on all collectors, and o= ut of step sequence numbers in the data records would cause spurious report= s of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup ra= ther than incurring a DNS lookup per export packet.


  1.  
    1.  
    2. The collector address may be learnt vi= a other methods (e.g., through DHCP options)
    3. A choice statement t= o select what method to use seems more appropriate than what is presently i= n RFC 6728.  For example (use some shorthand)

 

choice destination-meth= od{

    = ;            case de= stination-address{

    = ;            &n= bsp;            = ;   leaf destination-address// rw with type inet:host

    = ;            }

    = ;            case dh= cp-acquired-address{

    = ;            &n= bsp;            = ;   container dcp-acquired-address{

    = ;            &n= bsp;            = ;            &n= bsp;      leaf destination-ip-address inet-address= //ro

    = ;            }

}

        &nbs= p;            &= nbsp;         

        &nbs= p;            &= nbsp;          However I can= =92t augment to ietf-ipfix because destinationIPAddress is mandatory. = Can the group suggest methods to (a) change the destinationIPAddress type = and (b) allow a choice?


@PJ: The selection could also be done out of band so the exporter need not = know how the address is determined. eg a configuration system could determi= ne the address by any of these methods or otherwise, and impose that addres= s using the current model.

 

  1. RFC 6728 mandates SCTP tr= ansport.  I understand the logic behind this (IETF prefers use of SCTP= ).  There are situations where sctp is unnecessary and not supported (= e.g., point to point connection).  During netconf negotiations you can announce your feature set (currently sctptransport is= not a feature).  Is there ongoing work in updating RFC 6728 to includ= e sctptransport as a feature (so that the device can announce whether or no= t it supports sctptransport)?


@PJ Same answer as point (2) above, ie is this necessary and useful?

P.




_______________________________________________=0A=
IPFIX mailing list=0A=
IPFIX@ietf.org=0A=
https://www.ietf.org=
/mailman/listinfo/ipfix=0A=

--_000_8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429PLXRDC01plxrloc_-- From nobody Mon Jan 15 10:51:10 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC25D12EB61 for ; Mon, 15 Jan 2018 10:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 8MmSa1nPH6zJ for ; Mon, 15 Jan 2018 10:51:05 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BBD12EB5F for ; Mon, 15 Jan 2018 10:50:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ACF5260; Mon, 15 Jan 2018 19:50:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id NlesdZwMM0kx; Mon, 15 Jan 2018 19:50:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Jan 2018 19:50:46 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E1A72013F; Mon, 15 Jan 2018 19:50:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id l_14knuReEJT; Mon, 15 Jan 2018 19:50:45 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3316B2013E; Mon, 15 Jan 2018 19:50:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 001D94210A43; Mon, 15 Jan 2018 19:50:43 +0100 (CET) Date: Mon, 15 Jan 2018 19:50:43 +0100 From: Juergen Schoenwaelder To: Andrew Feren Cc: Gerhard Muenz , Benoit Claise , "Aitken, Paul" , 'Marta Seda' , "'ipfix@ietf.org'" Message-ID: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andrew Feren , Gerhard Muenz , Benoit Claise , "Aitken, Paul" , 'Marta Seda' , "'ipfix@ietf.org'" References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 18:51:09 -0000 I fail to see why this would be the case. (But I agree that renaming identifiers for the sake of renaming them is having little value.) /js On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote: > In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types". > > -Andrew > > ________________________________ > From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz [muenz@net.in.tum.de] > Sent: Saturday, January 13, 2018 4:43 AM > To: Benoit Claise; Aitken, Paul; 'Marta Seda' > Cc: 'ipfix@ietf.org' > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion > > > Marta, all, > > A few additional thoughts regarding your questions: > > 1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist. > > 2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set. > > 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://tools.ietf.org/html/rfc7011#section-10.1 > > Best regards, > Gerhard > > > > On 10.01.2018 08:33, Benoit Claise wrote: > Hi, > Marta, Benoit, > > 1. Are there efforts to update other RFCs to meet the latest YANG best practices? > Yes. Ex: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ > The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09) YANG modules > > 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time? > This type of feedback should come from implementation experience. > > Regards, Benoit > Note that it's > 5 years old. > > Also see @PJ inline: > > > On 09/01/2018 16:01, Benoit Claise wrote: > Hi Marta, > Hello, > I am reaching out to the IETF IPFIX mailing list on some issues I have run into with respect to RFC 6728 “Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols” > > > 1. RFC 6728 doesn’t meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address). Are there any ongoing efforts to update RFC 6728 to meet the latest best practices? > Not as far as I know. > > Regards, Benoit > > > 1. > > Identifiers SHOULD follow a consistent naming pattern throughout the > module. Only lower-case letters, numbers, and dashes SHOULD be used > in identifier names. Upper-case characters and the underscore > character MAY be used if the identifier represents a well-known value > that uses these characters. > > Identifiers SHOULD include complete words and/or well-known acronyms > or abbreviations. Child nodes within a container or list SHOULD NOT > replicate the parent identifier. YANG identifiers are hierarchical > and are only meant to be unique within the the set of sibling nodes > defined in the same module namespace. > > It is permissible to use common identifiers such as "name" or "id" in > data definition statements, especially if these data nodes share a > common data type. > > Identifiers SHOULD NOT carry any special semantics that identify data > modelling properties. Only YANG statements and YANG extension > statements are designed to convey machine readable data modelling > properties. For example, naming an object "config" or "state" does > not change whether it is configuration data or state data. Only > defined YANG statements or YANG extension statements can be used to > assign semantics in a machine readable format in YANG. > > > 1. I generated the RFC 6728 yang tree (see attached). The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory. The type is inet:ip-address. > > * A collector may be doing load balancing. Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located). > > @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet. > > > > 1. > > * > * The collector address may be learnt via other methods (e.g., through DHCP options) > * A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand) > > choice destination-method{ > case destination-address{ > leaf destination-address// rw with type inet:host > } > case dhcp-acquired-address{ > container dcp-acquired-address{ > leaf destination-ip-address inet-address //ro > } > } > > However I can’t augment to ietf-ipfix because destinationIPAddress is mandatory. Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice? > > @PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model. > > > > 1. RFC 6728 mandates SCTP transport. I understand the logic behind this (IETF prefers use of SCTP). There are situations where sctp is unnecessary and not supported (e.g., point to point connection). During netconf negotiations you can announce your feature set (currently sctptransport is not a feature). Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)? > > @PJ Same answer as point (2) above, ie is this necessary and useful? > > P. > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jan 15 12:35:38 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3597112EC13 for ; Mon, 15 Jan 2018 12:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=calix.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 UWITpMX-BuuG for ; Mon, 15 Jan 2018 12:35:32 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3754B12EC20 for ; Mon, 15 Jan 2018 12:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com; s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ugsqf2mTGefPD7LPWpM3GZi7CLMFuE5xivtsjviMnHc=; b=hpAF5QaWBN4a7u6StawELhN78V03GMHW0+w6niAUlQnEIhNph/cQMuqrKl3kiRs72lUxVzm0BYpG5FcXVBDDZQngQK9HuOr/ksRLUwqAkDeGGvmsRaAkBO6z390btSMwoZea1CoPt8M2RBh4MY69xXV+dkJd1JMzHsKffCMKuSc= Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB2152.namprd05.prod.outlook.com (10.163.198.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.9; Mon, 15 Jan 2018 20:35:23 +0000 Received: from BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) with mapi id 15.20.0428.014; Mon, 15 Jan 2018 20:35:23 +0000 From: Marta Seda To: Juergen Schoenwaelder , Andrew Feren CC: Gerhard Muenz , Benoit Claise , "Aitken, Paul" , "'ipfix@ietf.org'" Thread-Topic: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion Thread-Index: AQHTjjHEd5EiqXm9BU+CpNAukXBHqKN1SjPg Date: Mon, 15 Jan 2018 20:35:22 +0000 Message-ID: References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> <20180115185043.vj3ikpfqhsuycdm4@elstar.local> In-Reply-To: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marta.Seda@calix.com; x-originating-ip: [23.118.53.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0501MB2152; 7:eoE0mBNzpCJxQYxyjubY2TPnaOZ5zPxiOnxSVUSKXt7tKGBP1umBhomRbrcq4E9P3EBXMmOa6Z7onL3MtnFjVcpyNZ1mcZfRY6qYODRVSGpz6LVwPZq1hTNFDOp4eeTtbBskgfEN+g++eS8SCpZ2mnPIU5XSSkl6JL3h7jzE/vStWrRxGfPFJ5IPaUwFccOq4QKokXsi9xrAC75BMF1yGH1DruGlLsx18cIZPPXunbumJMBLzy1Vq9aJ+jT31wnp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a69f91ea-3ae7-4911-f121-08d55c57807c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR0501MB2152; x-ms-traffictypediagnostic: BY2PR0501MB2152: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(10436049006162)(120809045254105)(97927398514766)(95692535739014)(162037286835866); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041268)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR0501MB2152; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BY2PR0501MB2152; x-forefront-prvs: 0553CBB77A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(376002)(39850400004)(366004)(396003)(189003)(199004)(24454002)(13464003)(51444003)(102836004)(81166006)(25786009)(81156014)(7696005)(8936002)(74316002)(76176011)(106356001)(2906002)(105586002)(2900100001)(229853002)(97736004)(33656002)(3280700002)(3846002)(93886005)(3660700001)(6116002)(6436002)(72206003)(55016002)(9686003)(99286004)(14454004)(6306002)(966005)(7736002)(6246003)(305945005)(5660300001)(66066001)(110136005)(53546011)(316002)(54906003)(478600001)(6506007)(59450400001)(53936002)(68736007)(77096006)(2950100002)(4326008)(8676002)(86362001)(5890100001)(575784001)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB2152; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: calix.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: bfaBg0LJarSJs7MzgjwqgvOeHbMrgQUNtMnwrN76gm6zmH5HdDSIEvfiillkODc9dCV3jBxczlsYbjC6a/1VFA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: calix.com X-MS-Exchange-CrossTenant-Network-Message-Id: a69f91ea-3ae7-4911-f121-08d55c57807c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2018 20:35:22.8656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2152 Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 20:35:36 -0000 SnVzdCBhIGZldyB0aGluZ3MgdG8gY29uc2lkZXIgYWJvdXQgUkZDIDY3MjggKHdoaWNoIGlzIFlh bmcgMS4wIGNvbXBsaWFudCkuICBGb2xsb3dpbmcgYmVzdCBwcmFjdGljZXMgaXMgbm90IHRoZSBv bmx5IGlzc3VlIHdpdGggUkZDIDY3MjguICBJdCBkb2VzIG5vdCBzdXBwb3J0IFlhbmcgMS4xIChv ciBSRkMgNzg5NSBOZXRjb25mIGxpYnJhcnkpLiAgSSBhbSBub3QgcHJvbW90aW5nIHRoZSBpZGVh IG9mIHVwZGF0aW5nIFJGQyA2NzI4ICh0aGF0IGlzIGFuIElFVEYgZGVjaXNpb24pIGJ1dCB3YXMg dHJ5aW5nIHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUgd2VyZSBhbnkgZnV0dXJlIHBsYW5zIHRvIGFk ZHJlc3MgdGhlIGlzc3VlcyBJIGJyb3VnaHQgdXAuICAgIFNvbWUgYWRkaXRpb25hbCBwb2ludHMg dG8gdGhpbmsgYWJvdXQ6DQoNCkFsbCBTRE9zIChJRUVFLCBJRVRGLCBCQkYsIE1FRiwgZXRjKSBo YXZlIG1pZ3JhdGVkIHRvIFlhbmcgMS4xLiAgWWFuZyAxLjEgc3VwcG9ydHMgdGhlIGlldGYtbGli cmFyeSBtb2R1bGUgKHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg5NSkuICBJ biB0aGUgImh5cG90aGV0aWNhbCIgY2FzZSB3aGVyZSB5b3Ugd2VyZSBkZXZlbG9waW5nIGEgYnJh bmQgbmV3IGlwZml4IG1vZHVsZSwgeW91IGNvdWxkIGNyZWF0ZSBtdWx0aXBsZSBzdWJtb2R1bGVz IChlLmcuLCBvbmUgZm9yIGV4cG9ydGVyLCBhbm90aGVyIGZvciBjb2xsZWN0b3IsIGV0YykuICBB IGRldmljZSB3b3VsZCBpbXBvcnQgb25seSB0aG9zZSBtb2R1bGVzIGl0IHN1cHBvcnRzIChhbmQg dXNlIHRoZSBuZXRjb25mIGxpYnJhcnkgdG8gZXhwbGljaXRseSBzaG93IGRldmlhdGlvbnMpLiAg IFRoYXQgd291bGQgYmUgYSAibmljZSIgaW1wcm92ZW1lbnQgKHJpZ2h0IG5vdyBSRkMgNjcyOCBp cyBvbmUgYmlnIG1vZHVsZSBjb250YWluaW5nIGV2ZXJ5dGhpbmcpLiAgSG93ZXZlciBnb2luZyBi YWNrIHRvIHJlYWxpdHksIGl0IHdvdWxkIGJlIGEgbm9uLWJhY2t3YXJkcyBjb21wYXRpYmxlIGNo YW5nZSBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZXMgbWF5IGJlIHRoZSByZWFzb24g Zm9yIGRlY2lkaW5nIG5vdCB0byBkbyBjaGFuZ2VzIHRvIGlwZml4IHBzYW1wIHlhbmcuDQoNCklm IGEgdmVuZG9yIG5lZWRzIHRvIHN1cHBvcnQgcHNhbXAsIHlhbmcgMS4xIGFuZCB5YW5nIGJlc3Qg cHJhY3RpY2VzLCBvbmUgb3B0aW9uIGlzIHRvIGNyZWF0ZSB0aGVpciBvd24geWFuZyBtb2R1bGUg KGFuZCBsZWF2ZSBSRkMgNjcyOCBiZWhpbmQpIG9yIHByb21vdGUgdGhlIGlkZWEgdG8gYW5vdGhl ciBTRE8gKHdobyBtYXkgYmUgY3JlYXRpbmcgbmV3IHlhbmcgbW9kdWxlcyB0byBzdXBwb3J0IGlw Zml4IGJleW9uZCB3aGF0IFJGQyA2NzI4IGRlZmluZXMgdG9kYXkpIHRvIHBpY2sgdXAgdGhlIGFj dGl2aXR5IG9mIHJlZm9ybXVsYXRpbmcgcHNhbXAgeWFuZyB0byB0YWtlIGFkdmFudGFnZSBvZiBu ZXdlciBJRVRGIGZ1bmN0aW9ucyAoeWFuZyAxLjEgYW5kIGJlc3QgcHJhY3RpY2VzKS4gIFRoYXQg YXNzdW1lcyBvZiBjb3Vyc2UgaWYgSUVURiBkZWNpZGVzIHRoZXJlIGlzIG5vIG5lZWQgdG8gdXBk YXRlIFJGQyA2NzI4ICh3aGljaCBJIHRoaW5rIGlzIHdoYXQgSSBhbSBoZWFyaW5nIGluIHRoaXMg dGhyZWFkIC0gbm8gdXBkYXRlcyBpbiBSRkMgNjcyOCkuDQoNClJlZ2FyZHMsDQoNCk1hcnRhIFNl ZGENCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdIA0KU2VudDog TW9uZGF5LCBKYW51YXJ5IDE1LCAyMDE4IDEwOjUxIEFNDQpUbzogQW5kcmV3IEZlcmVuIDxhbmRy ZXcuZmVyZW5AcGxpeGVyLmNvbT4NCkNjOiBHZXJoYXJkIE11ZW56IDxtdWVuekBuZXQuaW4udHVt LmRlPjsgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+OyBBaXRrZW4sIFBhdWwgPHBh dWwuYWl0a2VuQGludGwuYXR0LmNvbT47IE1hcnRhIFNlZGEgPE1hcnRhLlNlZGFAY2FsaXguY29t PjsgJ2lwZml4QGlldGYub3JnJyA8aXBmaXhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lQRklY XSBbUVVBUl0gUmU6IFJGQyA2NzI4IElFVEYgSVBGSVggWWFuZyBEaXNjdXNzaW9uDQoNCkkgZmFp bCB0byBzZWUgd2h5IHRoaXMgd291bGQgYmUgdGhlIGNhc2UuIChCdXQgSSBhZ3JlZSB0aGF0IHJl bmFtaW5nIGlkZW50aWZpZXJzIGZvciB0aGUgc2FrZSBvZiByZW5hbWluZyB0aGVtIGlzIGhhdmlu ZyBsaXR0bGUgdmFsdWUuKQ0KDQovanMNCg0KT24gTW9uLCBKYW4gMTUsIDIwMTggYXQgMDY6MDk6 MjBQTSArMDAwMCwgQW5kcmV3IEZlcmVuIHdyb3RlOg0KPiBJbiBwYXJ0aWN1bGFyIHJlbmFtaW5n IGlkZW50aWZpZXJzIHdvdWxkIGJyZWFrIGFueSBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIDczNzMg IlRleHR1YWwgUmVwcmVzZW50YXRpb24gb2YgSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQgKElQ RklYKSBBYnN0cmFjdCBEYXRhIFR5cGVzIi4NCj4gDQo+IC1BbmRyZXcNCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IElQRklYIFtpcGZpeC1ib3VuY2VzQGll dGYub3JnXSBvbiBiZWhhbGYgb2YgR2VyaGFyZCBNdWVueiANCj4gW211ZW56QG5ldC5pbi50dW0u ZGVdDQo+IFNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDEzLCAyMDE4IDQ6NDMgQU0NCj4gVG86IEJl bm9pdCBDbGFpc2U7IEFpdGtlbiwgUGF1bDsgJ01hcnRhIFNlZGEnDQo+IENjOiAnaXBmaXhAaWV0 Zi5vcmcnDQo+IFN1YmplY3Q6IFtRVUFSXSBSZTogW0lQRklYXSBSRkMgNjcyOCBJRVRGIElQRklY IFlhbmcgRGlzY3Vzc2lvbg0KPiANCj4gDQo+IE1hcnRhLCBhbGwsDQo+IA0KPiBBIGZldyBhZGRp dGlvbmFsIHRob3VnaHRzIHJlZ2FyZGluZyB5b3VyIHF1ZXN0aW9uczoNCj4gDQo+IDEpIEkgd291 bGQgbm90IGV4cGVjdCB0aGF0IG5vdCBmb2xsb3dpbmcgY3VycmVudCBuYW1pbmcgY29udmVudGlv biBoaW5kZXJzIGltcGxlbWVudGF0aW9uIG9mIFJGQyA2NzI4LiBPbiB0aGUgb3RoZXIgaGFuZCwg aWYgd2UgY2hhbmdlIGp1c3QgdGhlIG5hbWVzIG9mIHRoZSBpZGVudGlmaWVycywgd2UgbG9zZSBp bnRlcm9wZXJhYmlsaXR5IHdpdGggb2xkZXIgaW1wbGVtZW50YXRpb25zIHRoYXQgbWF5IGV4aXN0 Lg0KPiANCj4gMikgSSB0aGluayB0aGF0IGl0IGlzIHJlYXNvbmFibGUgdGhhdCBkZXN0aW5hdGlv bklQQWRkcmVzcyBpcyBtYW5kYXRvcnkgYmVjYXVzZSBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVt cyBzaG91bGQgYmUgYWJsZSB0byBxdWVyeSB0aGUgSVAgYWRkcmVzcyB0byB3aGljaCBhbiBFeHBv cnRpbmcgUHJvY2VzcyBzZW5kcyBkYXRhLiBBcyBQYXVsIHN0YXRlZCwgUkZDIDY3MjggZG9lcyBu b3Qgc2F5IGhvdyB0aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzcyBpcyBzZXQuDQo+IA0KPiAzKSBT Q1RQIGlzIHN0aWxsIGEgbWFuZGF0b3J5IHRyYW5zcG9ydCBmb3IgYSBjb21wbGlhbnQgaW1wbGVt ZW50YXRpb24gDQo+IG9mIGFuIElQRklYIGRldmljZSwgbm90IGEgZmVhdHVyZS4gU2VlOiANCj4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcwMTEjc2VjdGlvbi0xMC4xPGh0dHBzOi8v bGlua3Byb3RlY3QuYw0KPiB1ZGFzdmMuY29tL3VybD9hPWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM3MDExJTIzc2VjdGlvbi0xMC4xJmM9DQo+IEUsMSxyM282ZmoxU1hvdDhUUUlQZ2V2 WE54NXlmTDhRdmxGOTgyQ2g5RFgyN01CeWp6N2JBZEVhRjl0akRvRHpqMVhnV3QNCj4gVFhZZk4x WjltWGlGeTgxYksxQXEzM2ZZRnpHbDVXLTJEaF8teGVQb3E5R056emFQR2RZajBvJnR5cG89MT4N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gR2VyaGFyZA0KPiANCj4gDQo+IA0KPiBPbiAxMC4wMS4y MDE4IDA4OjMzLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPiBIaSwNCj4gTWFydGEsIEJlbm9pdCwN Cj4gDQo+IDEuIEFyZSB0aGVyZSBlZmZvcnRzIHRvIHVwZGF0ZSBvdGhlciBSRkNzIHRvIG1lZXQg dGhlIGxhdGVzdCBZQU5HIGJlc3QgcHJhY3RpY2VzPw0KPiBZZXMuIEV4OiANCj4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNzIyM2Jpcy88aHR0 cHM6Lw0KPiAvbGlua3Byb3RlY3QuY3VkYXN2Yy5jb20vdXJsP2E9aHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtDQo+IGlldGYtbmV0bW9kLXJmYzcyMjNiaXMvJmM9RSwxLDk5 MEh0Q3l2U0tCSHdRT1M3anBIa2VTcHN2QzJNN2lLRGxJX2JmcUkNCj4gZ1cyZ3BhRU9ZaG5nQVNv aThMUlJodU02N2JSZEhTMkh5aTdjVkh5WER1aWhlQVJXRnhTcGFwX2l6blo2OFprbkpnRmJpeg0K PiBGSm9sZ1UmdHlwbz0xPiBUaGUgZ29hbCBpcyB0byBzcGVjaWZ5IE5NREEtY29tcGxpYW50IA0K PiAoZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTA5PGh0dHBzOi8vbGlua3By b3RlY3QuY3VkYXN2Yy5jDQo+IG9tL3VybD9hPWh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGENCj4gdGFzdG9yZXMvJmM9RSwxLEJ5S3hW RmVIZjhrMFliMWt6emtRblFnMzNWZnJSMTJIeTZkSnpRVGJrZ1N0WFp0M056ZkNpNw0KPiBsOTgx VnZYQ0NNM0wzaXdRM0ZGOGx6NzdtVDRDNXl1WkVmVmUtNzh1WEVzNXhEWnFsMnktLTRpRGxtT1VR LCZ0eXBvPTE+DQo+ICkgWUFORyBtb2R1bGVzDQo+IA0KPiAyLiBTaW5jZSB0aGUgSVBGSVggV0cg Y2xvc2VkLCB0aGVyZSBoYXMgYmVlbiBsaXR0bGUgb25nb2luZyBJUEZJWCB3b3JrIGluIHRoZSBJ RVRGLiBJcyB0aGVyZSBhIHNwZWNpZmljIG5lZWQgdG8gdXBkYXRlIFJGQyA2NzI4IHJhdGhlciB0 aGFuIGp1c3QgcmVjb2duaXNpbmcgaXQgYXMgYSBwcm9kdWN0IG9mIGl0J3MgdGltZT8NCj4gVGhp cyB0eXBlIG9mIGZlZWRiYWNrIHNob3VsZCBjb21lIGZyb20gaW1wbGVtZW50YXRpb24gZXhwZXJp ZW5jZS4NCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiBOb3RlIHRoYXQgaXQncyA+IDUgeWVhcnMg b2xkLg0KPiANCj4gQWxzbyBzZWUgQFBKIGlubGluZToNCj4gDQo+IA0KPiBPbiAwOS8wMS8yMDE4 IDE2OjAxLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPiBIaSBNYXJ0YSwNCj4gSGVsbG8sDQo+IEkg YW0gcmVhY2hpbmcgb3V0IHRvIHRoZSBJRVRGIElQRklYIG1haWxpbmcgbGlzdCAgb24gc29tZSBp c3N1ZXMgSSBoYXZlIHJ1biBpbnRvIHdpdGggcmVzcGVjdCB0byBSRkMgNjcyOCDigJxDb25maWd1 cmF0aW9uIERhdGEgTW9kZWwgZm9yIHRoZSBJUCBGbG93IEluZm9ybWF0aW9uIEV4cG9ydCAoSVBG SVgpICBhbmQgUGFja2V0IFNhbXBsaW5nIChQU0FNUCkgUHJvdG9jb2xz4oCdDQo+IA0KPiANCj4g ICAxLiAgUkZDIDY3MjggZG9lc27igJl0IG1lZXQgdGhlIGxhdGVzdCBZYW5nIEJlc3QgUHJhY3Rp Y2VzIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjA4 N2Jpcy0xNSNzZWN0aW9uLTQuMy4xPGh0dHBzOi8vbGlua3Byb3RlY3QuY3VkYXN2Yy5jb20vdXJs P2E9aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybCUzZnUlM2RodHRwcy0z QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRuZXRtb2QtMkRyZmM2MDg3Ymlz LTJEMTUtMjNzZWN0aW9uLTJENC4zLjElMjZkJTNkRHdNRC1nJTI2YyUzZExGWVotbzlfSFVNZU1U U1FpY3ZqSWclMjZyJTNkZjhGOHl6cnFCVHc2RVB0UjFyYmliT19WRkljLWNkbmpJSjloZV9xdTd4 cyUyNm0lM2QwYzVBVGp1VDAtNElsRHpMWU05aF9SYlBqQ0JRVXZfNmFFeFJMX2ZsLTVNJTI2cyUz ZEhoaTdWNm5qQ0ZOQmJTc2pDNnNQZ05mVnU1REE4aVF6ZHpzbkFfaVFCelElMjZlJTNkJmM9RSwx LDVac204bGxoSWVmX2pUWlUyYUFZMmZqX0t2bUpzLXpCejJISWZWRWtyaFk3VXdXc2czVW55a2ND UHpDVU03Yl9MNkNUbWtfVlkxLVRvN3Q4YVRNN1JCejJheUdoZTNPcnhiQms3X095Nkk3Z1FTa0tE QzhFaWcsLCZ0eXBvPTE+KS4gICBMZWFmIGlkZW50aWZpZXJzIGFyZSBjYW1lbCBjYXNlIChlLmcu LCBkZXN0aW5hdGlvbkFkZHJlc3MgaW5zdGVhZCBvZiBkZXN0aW5hdGlvbi1hZGRyZXNzKS4gIEFy ZSB0aGVyZSBhbnkgb25nb2luZyBlZmZvcnRzIHRvIHVwZGF0ZSBSRkMgNjcyOCB0byBtZWV0IHRo ZSBsYXRlc3QgYmVzdCBwcmFjdGljZXM/DQo+IE5vdCBhcyBmYXIgYXMgSSBrbm93Lg0KPiANCj4g UmVnYXJkcywgQmVub2l0DQo+IA0KPiANCj4gICAxLg0KPiANCj4gICAgSWRlbnRpZmllcnMgU0hP VUxEIGZvbGxvdyBhIGNvbnNpc3RlbnQgbmFtaW5nIHBhdHRlcm4gdGhyb3VnaG91dCB0aGUNCj4g ICAgbW9kdWxlLiAgT25seSBsb3dlci1jYXNlIGxldHRlcnMsIG51bWJlcnMsIGFuZCBkYXNoZXMg U0hPVUxEIGJlIHVzZWQNCj4gICAgaW4gaWRlbnRpZmllciBuYW1lcy4gIFVwcGVyLWNhc2UgY2hh cmFjdGVycyBhbmQgdGhlIHVuZGVyc2NvcmUNCj4gICAgY2hhcmFjdGVyIE1BWSBiZSB1c2VkIGlm IHRoZSBpZGVudGlmaWVyIHJlcHJlc2VudHMgYSB3ZWxsLWtub3duIHZhbHVlDQo+ICAgIHRoYXQg dXNlcyB0aGVzZSBjaGFyYWN0ZXJzLg0KPiANCj4gICAgSWRlbnRpZmllcnMgU0hPVUxEIGluY2x1 ZGUgY29tcGxldGUgd29yZHMgYW5kL29yIHdlbGwta25vd24gYWNyb255bXMNCj4gICAgb3IgYWJi cmV2aWF0aW9ucy4gIENoaWxkIG5vZGVzIHdpdGhpbiBhIGNvbnRhaW5lciBvciBsaXN0IFNIT1VM RCBOT1QNCj4gICAgcmVwbGljYXRlIHRoZSBwYXJlbnQgaWRlbnRpZmllci4gIFlBTkcgaWRlbnRp ZmllcnMgYXJlIGhpZXJhcmNoaWNhbA0KPiAgICBhbmQgYXJlIG9ubHkgbWVhbnQgdG8gYmUgdW5p cXVlIHdpdGhpbiB0aGUgdGhlIHNldCBvZiBzaWJsaW5nIG5vZGVzDQo+ICAgIGRlZmluZWQgaW4g dGhlIHNhbWUgbW9kdWxlIG5hbWVzcGFjZS4NCj4gDQo+ICAgIEl0IGlzIHBlcm1pc3NpYmxlIHRv IHVzZSBjb21tb24gaWRlbnRpZmllcnMgc3VjaCBhcyAibmFtZSIgb3IgImlkIiBpbg0KPiAgICBk YXRhIGRlZmluaXRpb24gc3RhdGVtZW50cywgZXNwZWNpYWxseSBpZiB0aGVzZSBkYXRhIG5vZGVz IHNoYXJlIGENCj4gICAgY29tbW9uIGRhdGEgdHlwZS4NCj4gDQo+ICAgIElkZW50aWZpZXJzIFNI T1VMRCBOT1QgY2FycnkgYW55IHNwZWNpYWwgc2VtYW50aWNzIHRoYXQgaWRlbnRpZnkgZGF0YQ0K PiAgICBtb2RlbGxpbmcgcHJvcGVydGllcy4gIE9ubHkgWUFORyBzdGF0ZW1lbnRzIGFuZCBZQU5H IGV4dGVuc2lvbg0KPiAgICBzdGF0ZW1lbnRzIGFyZSBkZXNpZ25lZCB0byBjb252ZXkgbWFjaGlu ZSByZWFkYWJsZSBkYXRhIG1vZGVsbGluZw0KPiAgICBwcm9wZXJ0aWVzLiAgRm9yIGV4YW1wbGUs IG5hbWluZyBhbiBvYmplY3QgImNvbmZpZyIgb3IgInN0YXRlIiBkb2VzDQo+ICAgIG5vdCBjaGFu Z2Ugd2hldGhlciBpdCBpcyBjb25maWd1cmF0aW9uIGRhdGEgb3Igc3RhdGUgZGF0YS4gIE9ubHkN Cj4gICAgZGVmaW5lZCBZQU5HIHN0YXRlbWVudHMgb3IgWUFORyBleHRlbnNpb24gc3RhdGVtZW50 cyBjYW4gYmUgdXNlZCB0bw0KPiAgICBhc3NpZ24gc2VtYW50aWNzIGluIGEgbWFjaGluZSByZWFk YWJsZSBmb3JtYXQgaW4gWUFORy4NCj4gDQo+IA0KPiAgIDEuICBJIGdlbmVyYXRlZCB0aGUgUkZD IDY3MjggeWFuZyB0cmVlIChzZWUgYXR0YWNoZWQpLiAgVGhlIHRjcCBhbmQgdWRwIGV4cG9ydGlu ZyBwcm9jZXNzZXMgc3VwcG9ydCBhIGRlc3RpbmF0aW9uSVBBZGRyZXNzIChsaW5lIDQwMCwgNDU1 KSB3aGljaCBpcyBtYW5kYXRvcnkuICBUaGUgdHlwZSBpcyBpbmV0OmlwLWFkZHJlc3MuDQo+IA0K PiAgICAgICogICBBIGNvbGxlY3RvciBtYXkgYmUgZG9pbmcgbG9hZCBiYWxhbmNpbmcuICBSYXRo ZXIgdGhhbiBtYW5hZ2luZyBpcC1hZGRyZXNzZXMsIHRoZSBjb2xsZWN0b3IgbWF5IGJlIHVzaW5n IEROUyAoYW4gZXhwb3J0ZXIgY291bGQgcmVzb2x2ZSBmcm9tIHRoZSBkb21haW4gbmFtZSB3aGVy ZSB0aGUgY29sbGVjdG9yIGlzIGxvY2F0ZWQpLg0KPiANCj4gQFBKOiBMb2FkIGJhbGFuY2luZyBh bmQgRE5TIGFyZSBpbmRlcGVuZGVudC4gTG9hZCBiYWxhbmNpbmcgSVBGSVggaXMgcHJvYmFibHkg YSBiYWQgaWRlYSBzaW5jZSB0ZW1wbGF0ZXMgbmVlZCB0byBiZSBhdmFpbGFibGUgb24gYWxsIGNv bGxlY3RvcnMsIGFuZCBvdXQgb2Ygc3RlcCBzZXF1ZW5jZSBudW1iZXJzIGluIHRoZSBkYXRhIHJl Y29yZHMgd291bGQgY2F1c2Ugc3B1cmlvdXMgcmVwb3J0cyBvZiBsb3N0IGRhdGEuIElmIEROUyBp cyB1c2VkIHRvIG9idGFpbiB0aGUgY29sbGVjdG9yJ3MgYWRkcmVzcywgYXJndWFibHkgaXQgc2hv dWxkIGJlIGEgb25lLXRpbWUgbG9va3VwIHJhdGhlciB0aGFuIGluY3VycmluZyBhIEROUyBsb29r dXAgcGVyIGV4cG9ydCBwYWNrZXQuDQo+IA0KPiANCj4gDQo+ICAgMS4NCj4gDQo+ICAgICAgKg0K PiAgICAgICogICBUaGUgY29sbGVjdG9yIGFkZHJlc3MgbWF5IGJlIGxlYXJudCB2aWEgb3RoZXIg bWV0aG9kcyAoZS5nLiwgdGhyb3VnaCBESENQIG9wdGlvbnMpDQo+ICAgICAgKiAgIEEgY2hvaWNl IHN0YXRlbWVudCB0byBzZWxlY3Qgd2hhdCBtZXRob2QgdG8gdXNlIHNlZW1zIG1vcmUgYXBwcm9w cmlhdGUgdGhhbiB3aGF0IGlzIHByZXNlbnRseSBpbiBSRkMgNjcyOC4gIEZvciBleGFtcGxlICh1 c2Ugc29tZSBzaG9ydGhhbmQpDQo+IA0KPiBjaG9pY2UgZGVzdGluYXRpb24tbWV0aG9kew0KPiAg ICAgICAgICAgICAgICAgY2FzZSBkZXN0aW5hdGlvbi1hZGRyZXNzew0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGxlYWYgZGVzdGluYXRpb24tYWRkcmVzcy8vIHJ3IHdpdGggdHlw ZSBpbmV0Omhvc3QNCj4gICAgICAgICAgICAgICAgIH0NCj4gICAgICAgICAgICAgICAgIGNhc2Ug ZGhjcC1hY3F1aXJlZC1hZGRyZXNzew0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGNvbnRhaW5lciBkY3AtYWNxdWlyZWQtYWRkcmVzc3sNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVhZiBkZXN0aW5hdGlvbi1pcC1hZGRyZXNzIGlu ZXQtYWRkcmVzcyAvL3JvDQo+ICAgICAgICAgICAgICAgICB9DQo+IH0NCj4gDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSG93ZXZlciBJIGNhbuKAmXQgYXVnbWVudCB0byBpZXRm LWlwZml4IGJlY2F1c2UgZGVzdGluYXRpb25JUEFkZHJlc3MgaXMgbWFuZGF0b3J5LiAgQ2FuIHRo ZSBncm91cCBzdWdnZXN0IG1ldGhvZHMgdG8gKGEpIGNoYW5nZSB0aGUgZGVzdGluYXRpb25JUEFk ZHJlc3MgdHlwZSBhbmQgKGIpIGFsbG93IGEgY2hvaWNlPw0KPiANCj4gQFBKOiBUaGUgc2VsZWN0 aW9uIGNvdWxkIGFsc28gYmUgZG9uZSBvdXQgb2YgYmFuZCBzbyB0aGUgZXhwb3J0ZXIgbmVlZCBu b3Qga25vdyBob3cgdGhlIGFkZHJlc3MgaXMgZGV0ZXJtaW5lZC4gZWcgYSBjb25maWd1cmF0aW9u IHN5c3RlbSBjb3VsZCBkZXRlcm1pbmUgdGhlIGFkZHJlc3MgYnkgYW55IG9mIHRoZXNlIG1ldGhv ZHMgb3Igb3RoZXJ3aXNlLCBhbmQgaW1wb3NlIHRoYXQgYWRkcmVzcyB1c2luZyB0aGUgY3VycmVu dCBtb2RlbC4NCj4gDQo+IA0KPiANCj4gICAxLiAgUkZDIDY3MjggbWFuZGF0ZXMgU0NUUCB0cmFu c3BvcnQuICBJIHVuZGVyc3RhbmQgdGhlIGxvZ2ljIGJlaGluZCB0aGlzIChJRVRGIHByZWZlcnMg dXNlIG9mIFNDVFApLiAgVGhlcmUgYXJlIHNpdHVhdGlvbnMgd2hlcmUgc2N0cCBpcyB1bm5lY2Vz c2FyeSBhbmQgbm90IHN1cHBvcnRlZCAoZS5nLiwgcG9pbnQgdG8gcG9pbnQgY29ubmVjdGlvbiku ICBEdXJpbmcgbmV0Y29uZiBuZWdvdGlhdGlvbnMgeW91IGNhbiBhbm5vdW5jZSB5b3VyIGZlYXR1 cmUgc2V0IChjdXJyZW50bHkgc2N0cHRyYW5zcG9ydCBpcyBub3QgYSBmZWF0dXJlKS4gIElzIHRo ZXJlIG9uZ29pbmcgd29yayBpbiB1cGRhdGluZyBSRkMgNjcyOCB0byBpbmNsdWRlIHNjdHB0cmFu c3BvcnQgYXMgYSBmZWF0dXJlIChzbyB0aGF0IHRoZSBkZXZpY2UgY2FuIGFubm91bmNlIHdoZXRo ZXIgb3Igbm90IGl0IHN1cHBvcnRzIHNjdHB0cmFuc3BvcnQpPw0KPiANCj4gQFBKIFNhbWUgYW5z d2VyIGFzIHBvaW50ICgyKSBhYm92ZSwgaWUgaXMgdGhpcyBuZWNlc3NhcnkgYW5kIHVzZWZ1bD8N Cj4gDQo+IFAuDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBJUEZJWCBtYWlsaW5nIGxpc3QNCj4gSVBGSVhAaWV0Zi5v cmc8bWFpbHRvOklQRklYQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwZml4PGh0dHBzOi8vbGlua3Byb3RlY3QuY3VkYXN2DQo+IGMuY29tL3VybD9h PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgmYz1FLDEsUWNTYU9S RzQNCj4gRU5FQ29qa1hhd3R5a0tkcXFHYUtkSVFDQVhVX2s3RFVvaW1ieHA0cDlLaG9FcHBRbFEx THN3SzFFNXlZNWt2SUw4WFl5cQ0KPiBNYkNwaElFeXY4YUJndHl5UWJiTjMxZm5icng5SSwmdHlw bz0xPg0KPiANCj4gDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gSVBGSVggbWFpbGluZyBsaXN0DQo+IElQRklYQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBmaXgNCg0KDQotLSANCkp1ZXJnZW4g U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQ aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt ZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= From nobody Mon Jan 15 13:10:13 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5273912D856 for ; Mon, 15 Jan 2018 13:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 QTiMxPX_MiGW for ; Mon, 15 Jan 2018 13:10:06 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 AE2D112D77C for ; Mon, 15 Jan 2018 13:10:06 -0800 (PST) Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0FL9V7v043846 for ; Mon, 15 Jan 2018 16:10:05 -0500 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fgx91pyu0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Jan 2018 16:10:05 -0500 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 15 Jan 2018 21:10:04 -0000 Received: from us1a3-smtp08.a3.dal06.isc4sb.com (10.146.103.57) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Mon, 15 Jan 2018 21:10:01 -0000 Received: from us1a3-mail64.a3.dal09.isc4sb.com ([10.142.3.135]) by us1a3-smtp08.a3.dal06.isc4sb.com with ESMTP id 2018011521100136-995231 ; Mon, 15 Jan 2018 21:10:01 +0000 In-Reply-To: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> From: "Wayne Tackabury" To: j.schoenwaelder@jacobs-university.de Cc: ipfix@ietf.org Date: Mon, 15 Jan 2018 21:10:01 +0000 Sensitivity: MIME-Version: 1.0 References: <20180115185043.vj3ikpfqhsuycdm4@elstar.local>, <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 15909-1273 | IBM Domino Build SCN1734600_20171212T0033_FP3 January 05, 2018 at 15:38 X-LLNOutbound: False X-Disclaimed: 10555 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 x-cbid: 18011521-3107-0000-0000-0000049D0EB3 X-IBM-SpamModules-Scores: BY=0.294031; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.394815; ST=0; TS=0; UL=0; ISC=; MB=0.454028 X-IBM-SpamModules-Versions: BY=3.00008384; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00975528; UDB=6.00494440; IPR=6.00755456; BA=6.00005778; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019054; XFM=3.00000015; UTC=2018-01-15 21:10:03 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-01-15 19:58:38 - 6.00007912 x-cbparentid: 18011521-3108-0000-0000-00007DD61069 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-15_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 21:10:12 -0000
Regarding SCTP, a= s of this writing, it is not and can not be mandatory.  Not many comme= rcial collectors support it.  I've found this to be a bit of an "eleph= ant in the room" on the RFC directions.
 
To be perfectly practical, as things have emerged since t= he days of RFC[s] 510x, SCTP has not been made sufficiently stable in linux= kernel and user interfaces that it could support carrier-grade flow convey= ance dependencies.  There are probably other nontechnical barriers to = acceptance. To be sure, this is unfortunate, since SCTP still admirably mee= ts the original design goals.
 
Without getting into it, where I'm aware of implementatio= ns that meed tp make use of the "messaging" benefits of SCTP over UDP, the = less-than-standard path of TCP over some defacto standard port  has be= en used.  Others may know of different implementations, but this is ba= sed on subjective, but voluminous, input from implementations I've seen at = customer sites and discussions with colleagues at different vendor enterpri= ses.  Again, this is not an editorial on technical merit.
 
Regards,
Wayne
 
 
----- Original message -----
From: Juergen Schoenwael= der <j.schoenwaelder@jacobs-university.de>
Sent by: "IPFIX" <ip= fix-bounces@ietf.org>
To: Andrew Feren <andrew.feren@plixer.com>= ;
Cc: 'Marta Seda' <Marta.Seda@calix.com>, "Aitken, Paul" <paul= .aitken@intl.att.com>, "'ipfix@ietf.org'" <ipfix@ietf.org>
Subj= ect: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Date: Mo= n, Jan 15, 2018 1:51 PM
 
I fail to see why this would be the case. (But I agree that renamingidentifiers for the sake of renaming them is having little value.)
/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:> In particular renaming identifiers would break any implementations o= f RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Ab= stract Data Types".
>
> -Andrew
>
> =5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F
> From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Mu= enz [muenz@net.in.tum.de]
> Sent: Saturday, January 13, 2018 4:43 AM<= br>> To: Benoit Claise; Aitken, Paul; 'Marta Seda'
> Cc: 'ipfix@ie= tf.org'
> Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discus= sion
>
>
> Marta, all,
>
> A few additional t= houghts regarding your questions:
>
> 1) I would not expect tha= t not following current naming convention hinders implementation of RFC 672= 8. On the other hand, if we change just the names of the identifiers, we lo= se interoperability with older implementations that may exist.
>
&= gt; 2) I think that it is reasonable that destinationIPAddress is mandatory= because network management systems should be able to query the IP address = to which an Exporting Process sends data. As Paul stated, RFC 6728 does not= say how the destination IP address is set.
>
> 3) SCTP is stil= l a mandatory transport for a compliant implementation of an IPFIX device, = not a feature. See: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Ftools= .ietf.org=5Fhtml=5Frfc7011-23section-2D10.1&d=3DDwIGaQ&c=3Djf=5FiaS= HvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5Fk= E&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DqunYBh7bv5ABG= GsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=3D<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fl= inkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Ftools.ietf.org=5Fhtml=5Frf= c7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch= 9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxeP= oq9GNzzaPGdYj0o-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&= amp;r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94EL= pPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DM0CgR7V3IlBqkpQDo2Brx-bewHWnHX= =5Fa5l7YChB32BI&e=3D>
>
> Best regards,
> Gerh= ard
>
>
>
> On 10.01.2018 08:33, Benoit Claise wrot= e:
> Hi,
> Marta, Benoit,
>
> 1. Are there efforts = to update other RFCs to meet the latest YANG best practices?
> Yes. E= x: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fdatat= racker.ietf.org=5Fdoc=5Fdraft-2Dietf-2Dnetmod-2Drfc7223bis=5F&d=3DDwIGa= Q&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F= =5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&am= p;s=3DDml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w=5Fzw&e=3D<https://urldefense.proofpoint= .com/v2/url?u=3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A= =5F=5Fdatatracker.ietf.org=5Fdoc=5Fdraft-2Dietf-2Dnetmod-2Drfc7223bis=5F-26= c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRh= uM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d= =3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw= 4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOL= L3H8&s=3DwhhuVEyPDEyPYoboty-rb0h=5FRQBoHKqNmiQoGwpLBlw&e=3D>=
> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-d= atastores-09<https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Flinkprotec= t.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Fdatatracker.ietf.org=5Fdoc=5Fdraft-= 2Dietf-2Dnetmod-2Drevised-2Ddatastores=5F-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzk= QnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D7= 8uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHv= JObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&= amp;m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DgGNMKyVcGZrZBCb= Vl5XjjnnyJnRDUxt8jU3e24fcQBU&e=3D>) YANG modules
>
>= 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in = the IETF. Is there a specific need to update RFC 6728 rather than just reco= gnising it as a product of it's time?
> This type of feedback should = come from implementation experience.
>
> Regards, Benoit
>= ; Note that it's > 5 years old.
>
> Also see @PJ inline:
= >
>
> On 09/01/2018 16:01, Benoit Claise wrote:
> Hi M= arta,
> Hello,
> I am reaching out to the IETF IPFIX mailing li= st  on some issues I have run into with respect to RFC 6728 =E2=80=9CC= onfiguration Data Model for the IP Flow Information Export (IPFIX)  an= d Packet Sampling (PSAMP) Protocols=E2=80=9D
>
>
>  = 1.  RFC 6728 doesn=E2=80=99t meet the latest Yang Best Practices (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F= =5Ftools.ietf.org=5Fhtml=5Fdraft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23sectio= n-2D4.3.1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9= l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWh= v6uxVZ5pB5BvoOLL3H8&s=3DSSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&= ;e=3D<https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3= A=5F=5Furldefense.proofpoint.com=5Fv2=5Furl-253fu-253dhttps-2D3A-5F-5Ftools= .ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23sect= ion-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r= -253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-= 2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPg= NfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj= -5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2= ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf= =5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6= Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3Doj6Kq-4= SRjuodk73yxC5K1cDKw8XP95L=5FH=5Fm3ErUuQM&e=3D>).   Leaf ide= ntifiers are camel case (e.g., destinationAddress instead of destination-ad= dress).  Are there any ongoing efforts to update RFC 6728 to meet the = latest best practices?
> Not as far as I know.
>
> Regard= s, Benoit
>
>
>   1.
>
>    Id= entifiers SHOULD follow a consistent naming pattern throughout the
> =    module.  Only lower-case letters, numbers, and dashes SHO= ULD be used
>    in identifier names.  Upper-case char= acters and the underscore
>    character MAY be used if the= identifier represents a well-known value
>    that uses th= ese characters.
>
>    Identifiers SHOULD include com= plete words and/or well-known acronyms
>    or abbreviation= s.  Child nodes within a container or list SHOULD NOT
>   &= nbsp;replicate the parent identifier.  YANG identifiers are hierarchic= al
>    and are only meant to be unique within the the set = of sibling nodes
>    defined in the same module namespace.=
>
>    It is permissible to use common identifiers s= uch as "name" or "id" in
>    data definition statements, e= specially if these data nodes share a
>    common data type= .
>
>    Identifiers SHOULD NOT carry any special sem= antics that identify data
>    modelling properties.  = Only YANG statements and YANG extension
>    statements are= designed to convey machine readable data modelling
>    pr= operties.  For example, naming an object "config" or "state" does
&= gt;    not change whether it is configuration data or state data.=  Only
>    defined YANG statements or YANG extension = statements can be used to
>    assign semantics in a machin= e readable format in YANG.
>
>
>   1.  I genera= ted the RFC 6728 yang tree (see attached).  The tcp and udp exporting = processes support a destinationIPAddress (line 400, 455) which is mandatory= .  The type is inet:ip-address.
>
>      * =   A collector may be doing load balancing.  Rather than managing = ip-addresses, the collector may be using DNS (an exporter could resolve fro= m the domain name where the collector is located).
>
> @PJ: Loa= d balancing and DNS are independent. Load balancing IPFIX is probably a bad= idea since templates need to be available on all collectors, and out of st= ep sequence numbers in the data records would cause spurious reports of los= t data. If DNS is used to obtain the collector's address, arguably it shoul= d be a one-time lookup rather than incurring a DNS lookup per export packet= .
>
>
>
>   1.
>
>     &= nbsp;*
>      *   The collector address may be le= arnt via other methods (e.g., through DHCP options)
>     &= nbsp;*   A choice statement to select what method to use seems more ap= propriate than what is presently in RFC 6728.  For example (use some s= horthand)
>
> choice destination-method{
>     =             case destination-address{
>=                     &nbs= p;           leaf destination-address// rw with ty= pe inet:host
>                = ; }
>                 case dh= cp-acquired-address{
>             &nbs= p;                   container= dcp-acquired-address{
>             &n= bsp;                     =               leaf destination-ip-addres= s inet-address //ro
>              = ;   }
> }
>
>           &nb= sp;                     H= owever I can=E2=80=99t augment to ietf-ipfix because destinationIPAddress i= s mandatory.  Can the group suggest methods to (a) change the destinat= ionIPAddress type and (b) allow a choice?
>
> @PJ: The selectio= n could also be done out of band so the exporter need not know how the addr= ess is determined. eg a configuration system could determine the address by= any of these methods or otherwise, and impose that address using the curre= nt model.
>
>
>
>   1.  RFC 6728 mandates= SCTP transport.  I understand the logic behind this (IETF prefers use= of SCTP).  There are situations where sctp is unnecessary and not sup= ported (e.g., point to point connection).  During netconf negotiations= you can announce your feature set (currently sctptransport is not a featur= e).  Is there ongoing work in updating RFC 6728 to include sctptranspo= rt as a feature (so that the device can announce whether or not it supports= sctptransport)?
>
> @PJ Same answer as point (2) above, ie is = this necessary and useful?
>
> P.
>
>
>
&g= t;
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
> IPFIX mailing list
> IPFIX@ietf.org<mailto:IPFIX@ietf.org>
> = https://urldefense.p= roofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fwww.ietf.org=5Fmailman=5Flistinfo=5F= ipfix&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y= 0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6ux= VZ5pB5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e= =3D<https://urldefense.proofpoint.com/v2/url?u= =3Dhttps-3A=5F=5Flinkprotect.cudasvc.com=5Furl-3Fa-3Dhttps-3A=5F=5Fwww.ietf= .org=5Fmailman=5Flistinfo=5Fipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGa= KdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31= fnbrx9I-2C-26typo-3D1&d=3DDwIGaQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r= =3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5B= moxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DcQFI-IsxLhklEI0w-JcCksB=5FYNvx9v06C= pqsjQys0N8&e=3D>
>
>

> =5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> IPFIX mailing list=
> IPFIX@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A=5F=5Fw= ww.ietf.org=5Fmailman=5Flistinfo=5Fipfix&d=3DDwIGaQ&c=3Djf=5FiaSHvJ= ObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6Qa=5FkE&a= mp;m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYs= X7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D


--
Juergen Schoenwae= lder           Jacobs University Bremen gGmbH
P= hone: +49 421 200 3587         Campus Ring 1 | 28759 Br= emen | Germany
Fax:   +49 421 200 3103         = <https://urldefense.proofpo= int.com/v2/url?u=3Dhttps-3A=5F=5Fwww.jacobs-2Duniversity.de=5F&d=3DDwIG= aQ&c=3Djf=5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F= =5FJt3CBhpQR6Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&am= p;s=3DcC8C3QfrkIEC1Vo-QLwKrh955-evz=5FTr3MYoFDTmD1A&e=3D>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
IP= FIX mailing list
IPFIX@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A= =5F=5Fwww.ietf.org=5Fmailman=5Flistinfo=5Fipfix&d=3DDwIGaQ&c=3Djf= =5FiaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR=5FUtUw4WaW=5F=5FJt3CBhpQR6= Qa=5FkE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DzSpyB0I= g1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D
 
 

From nobody Mon Jan 15 13:18:40 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A4412EC2F for ; Mon, 15 Jan 2018 13:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.528 X-Spam-Level: X-Spam-Status: No, score=-13.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 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 U6FaKo5A4CHb for ; Mon, 15 Jan 2018 13:18:34 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAE3120713 for ; Mon, 15 Jan 2018 13:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44593; q=dns/txt; s=iport; t=1516051113; x=1517260713; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rIbqj41pXrsV65DqMD8PM76jyLBHNvsv6nz2P4FLRe4=; b=lYZSMTC1q2LLG4Pfvb+PGUicr7Bi5nAEMxNd2DHqqF9strmXFRzfciHu LOVxRqxWj+NWsOTGJHY/2LZIVBMIqoR/4Yf6PcYeueqSt/fazJAUqjcBe MfyO1yenSiMzOAdz5LdxnJA7f+LG5BGLcaf3RaFdt/VlUZI8aHxFdt9di w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAFGl1a/xbLJq1SBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkqBXXQnhBOLGI9tlyyCFgoYAQ2FFQKFEhYBAQEBAQEBAQF?= =?us-ascii?q?rKIUjAQEBBAEBGAlEBwsFCQIJAg4CAQMBAQEBIAEGAwICGwwfCQgGAQwGAgEBi?= =?us-ascii?q?i8Qik6dcIInJokkAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWII4FpKYMFgUmBZgE?= =?us-ascii?q?BAhmBKzsQAQsbglCCZQWKcIc3kT2IDI0/ghlniSWHa4poglaBXogJgTwmBS2BU?= =?us-ascii?q?DIaCBsVPYIqCYJXgXhANwEBAQGNCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,365,1511827200"; d="scan'208,217";a="1415674" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2018 21:18:30 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0FLIURQ030690; Mon, 15 Jan 2018 21:18:30 GMT To: Wayne Tackabury , j.schoenwaelder@jacobs-university.de Cc: ipfix@ietf.org References: <20180115185043.vj3ikpfqhsuycdm4@elstar.local> <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> From: Benoit Claise Message-ID: Date: Mon, 15 Jan 2018 22:18:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2B03182A9B4EFD4EF83D802A" Content-Language: en-US Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 21:18:39 -0000 This is a multi-part message in MIME format. --------------2B03182A9B4EFD4EF83D802A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 1/15/2018 10:10 PM, Wayne Tackabury wrote: > Regarding SCTP, as of this writing, it is not and can not be=20 > mandatory.=C2=A0 Not many commercial collectors support it.=C2=A0 I've = found=20 > this to be a bit of an "elephant in the room" on the RFC directions. No disagreement. http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-= standardization-explained-2/ Regards, B. > To be perfectly practical, as things have emerged since the days of=20 > RFC[s] 510x, SCTP has not been made sufficiently stable in linux=20 > kernel and user interfaces that it could support carrier-grade flow=20 > conveyance dependencies. There are probably other nontechnical=20 > barriers to acceptance. To be sure, this is unfortunate, since SCTP=20 > still admirably meets the original design goals. > Without getting into it, where I'm aware of implementations that meed=20 > tp make use of the "messaging" benefits of SCTP over UDP, the=20 > less-than-standard path of TCP over some defacto standard port=C2=A0 ha= s=20 > been used.=C2=A0 Others may know of different implementations, but this= is=20 > based on subjective, but voluminous, input from implementations I've=20 > seen at customer sites and discussions with colleagues at different=20 > vendor enterprises.=C2=A0 Again, this is not an editorial on technical = merit. > Regards, > Wayne > > ----- Original message ----- > From: Juergen Schoenwaelder > Sent by: "IPFIX" > To: Andrew Feren > Cc: 'Marta Seda' , "Aitken, Paul" > , "'ipfix@ietf.org'" > Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion= > Date: Mon, Jan 15, 2018 1:51 PM > I fail to see why this would be the case. (But I agree that renamin= g > identifiers for the sake of renaming them is having little value.) > > /js > > On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote: > > In particular renaming identifiers would break any > implementations of RFC 7373 "Textual Representation of IP Flow > Information Export (IPFIX) Abstract Data Types". > > > > -Andrew > > > > ________________________________ > > From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz > [muenz@net.in.tum.de] > > Sent: Saturday, January 13, 2018 4:43 AM > > To: Benoit Claise; Aitken, Paul; 'Marta Seda' > > Cc: 'ipfix@ietf.org' > > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion > > > > > > Marta, all, > > > > A few additional thoughts regarding your questions: > > > > 1) I would not expect that not following current naming > convention hinders implementation of RFC 6728. On the other hand, > if we change just the names of the identifiers, we lose > interoperability with older implementations that may exist. > > > > 2) I think that it is reasonable that destinationIPAddress is > mandatory because network management systems should be able to > query the IP address to which an Exporting Process sends data. As > Paul stated, RFC 6728 does not say how the destination IP address > is set. > > > > 3) SCTP is still a mandatory transport for a compliant > implementation of an IPFIX device, not a feature. See: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.o= rg_html_rfc7011-23section-2D10.1&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3D= eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv= 6uxVZ5pB5BvoOLL3H8&s=3DqunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=3D > > > > Best regards, > > Gerhard > > > > > > > > On 10.01.2018 08:33, Benoit Claise wrote: > > Hi, > > Marta, Benoit, > > > > 1. Are there efforts to update other RFCs to meet the latest > YANG best practices? > > Yes. Ex: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.= ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=3DDwIGaQ&c=3Djf_iaSHvJ= ObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94EL= pPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DDml5zgSWzeUBwS1XyKmCG-y3bWePHxpz= t3PCej4w_zw&e=3D > > The goal is to specify NMDA-compliant > (draft-ietf-netmod-revised-datastores-09) > YANG modules > > > > 2. Since the IPFIX WG closed, there has been little ongoing > IPFIX work in the IETF. Is there a specific need to update RFC > 6728 rather than just recognising it as a product of it's time? > > This type of feedback should come from implementation experience.= > > > > Regards, Benoit > > Note that it's > 5 years old. > > > > Also see @PJ inline: > > > > > > On 09/01/2018 16:01, Benoit Claise wrote: > > Hi Marta, > > Hello, > > I am reaching out to the IETF IPFIX mailing list =C2=A0on some is= sues > I have run into with respect to RFC 6728 =E2=80=9CConfiguration Dat= a Model > for the IP Flow Information Export (IPFIX) =C2=A0and Packet Samplin= g > (PSAMP) Protocols=E2=80=9D > > > > > > =C2=A0 1. =C2=A0RFC 6728 doesn=E2=80=99t meet the latest Yang Bes= t Practices > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.= org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=3DDw= IGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR= 6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=3DSSYo4WM-xFfyPg= rSh-cja-jQFQEucW4daULPdwg2zSI&e=3D). > =C2=A0 Leaf identifiers are camel case (e.g., destinationAddress > instead of destination-address). =C2=A0Are there any ongoing effort= s to > update RFC 6728 to meet the latest best practices? > > Not as far as I know. > > > > Regards, Benoit > > > > > > =C2=A0 1. > > > > =C2=A0 =C2=A0Identifiers SHOULD follow a consistent naming patter= n > throughout the > > =C2=A0 =C2=A0module. =C2=A0Only lower-case letters, numbers, and = dashes SHOULD > be used > > =C2=A0 =C2=A0in identifier names. =C2=A0Upper-case characters and= the underscore > > =C2=A0 =C2=A0character MAY be used if the identifier represents a= > well-known value > > =C2=A0 =C2=A0that uses these characters. > > > > =C2=A0 =C2=A0Identifiers SHOULD include complete words and/or wel= l-known > acronyms > > =C2=A0 =C2=A0or abbreviations. =C2=A0Child nodes within a contain= er or list > SHOULD NOT > > =C2=A0 =C2=A0replicate the parent identifier. =C2=A0YANG identifi= ers are > hierarchical > > =C2=A0 =C2=A0and are only meant to be unique within the the set o= f sibling > nodes > > =C2=A0 =C2=A0defined in the same module namespace. > > > > =C2=A0 =C2=A0It is permissible to use common identifiers such as = "name" or > "id" in > > =C2=A0 =C2=A0data definition statements, especially if these data= nodes > share a > > =C2=A0 =C2=A0common data type. > > > > =C2=A0 =C2=A0Identifiers SHOULD NOT carry any special semantics t= hat > identify data > > =C2=A0 =C2=A0modelling properties. =C2=A0Only YANG statements and= YANG extension > > =C2=A0 =C2=A0statements are designed to convey machine readable d= ata modelling > > =C2=A0 =C2=A0properties. =C2=A0For example, naming an object "con= fig" or > "state" does > > =C2=A0 =C2=A0not change whether it is configuration data or state= data. =C2=A0Only > > =C2=A0 =C2=A0defined YANG statements or YANG extension statements= can be > used to > > =C2=A0 =C2=A0assign semantics in a machine readable format in YAN= G. > > > > > > =C2=A0 1. =C2=A0I generated the RFC 6728 yang tree (see attached)= =2E =C2=A0The > tcp and udp exporting processes support a destinationIPAddress > (line 400, 455) which is mandatory. =C2=A0The type is inet:ip-addre= ss. > > > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 A collector may be doing load balanc= ing. =C2=A0Rather than > managing ip-addresses, the collector may be using DNS (an exporter > could resolve from the domain name where the collector is located).= > > > > @PJ: Load balancing and DNS are independent. Load balancing > IPFIX is probably a bad idea since templates need to be available > on all collectors, and out of step sequence numbers in the data > records would cause spurious reports of lost data. If DNS is used > to obtain the collector's address, arguably it should be a > one-time lookup rather than incurring a DNS lookup per export packe= t. > > > > > > > > =C2=A0 1. > > > > =C2=A0 =C2=A0 =C2=A0* > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 The collector address may be learnt = via other methods > (e.g., through DHCP options) > > =C2=A0 =C2=A0 =C2=A0* =C2=A0 A choice statement to select what me= thod to use seems > more appropriate than what is presently in RFC 6728. =C2=A0For exam= ple > (use some shorthand) > > > > choice destination-method{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case dest= ination-address{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf destination-address// = rw > with type inet:host > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case dhcp= -acquired-address{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container dcp-acquired-addr= ess{ > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf > destination-ip-address inet-address //ro > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > > } > > > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 However I can=E2=80=99t aug= ment to > ietf-ipfix because destinationIPAddress is mandatory. =C2=A0Can the= > group suggest methods to (a) change the destinationIPAddress type > and (b) allow a choice? > > > > @PJ: The selection could also be done out of band so the > exporter need not know how the address is determined. eg a > configuration system could determine the address by any of these > methods or otherwise, and impose that address using the current mod= el. > > > > > > > > =C2=A0 1. =C2=A0RFC 6728 mandates SCTP transport. =C2=A0I underst= and the logic > behind this (IETF prefers use of SCTP). =C2=A0There are situations > where sctp is unnecessary and not supported (e.g., point to point > connection). =C2=A0During netconf negotiations you can announce you= r > feature set (currently sctptransport is not a feature). =C2=A0Is th= ere > ongoing work in updating RFC 6728 to include sctptransport as a > feature (so that the device can announce whether or not it > supports sctptransport)? > > > > @PJ Same answer as point (2) above, ie is this necessary and usef= ul? > > > > P. > > > > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D > > > -- > Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs Uni= versity Bremen gGmbH > Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1 |= 28759 Bremen | Germany > Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_ipfix&d=3DDwIGaQ&c=3Djf_iaSHvJObTbx-siA1ZOg&r=3DeSiUkUZ= U9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=3DAqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5p= B5BvoOLL3H8&s=3DzSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=3D > > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://www.ietf.org/mailman/listinfo/ipfix --------------2B03182A9B4EFD4EF83D802A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/15/2018 10:10 PM, Wayne Tackabury wrote:
Regarding SCTP, as of this writing, it is not and can not be mandatory.  Not many commercial collectors support it.  I've found this to be a bit of an "elephant in the room" on the RFC directions.
No disagreement.
http://www.claise.be/2015/06/from-netflow-to-ipfix-via-psamp-13-years-of-standardization-explained-2/

Regards, B.
 
To be perfectly practical, as things have emerged since the days of RFC[s] 510x, SCTP has not been made sufficiently stable in linux kernel and user interfaces that it could support carrier-grade flow conveyance dependencies.  There are probably other nontechnical barriers to acceptance. To be sure, this is unfortunate, since SCTP still admirably meets the original design goals.
 
Without getting into it, where I'm aware of implementations that meed tp make use of the "messaging" benefits of SCTP over UDP, the less-than-standard path of TCP over some defacto standard port  has been used.  Others may know of different implementations, but this is based on subjective, but voluminous, input from implementations I've seen at customer sites and discussions with colleagues at different vendor enterprises.  Again, this is not an editorial on technical merit.
 
Regards,
Wayne
 
 
----- Original message -----
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Sent by: "IPFIX" <ipfix-bounces@ietf.org>
To: Andrew Feren <andrew.feren@plixer.com>
Cc: 'Marta Seda' <Marta.Seda@calix.com>, "Aitken, Paul" <paul.aitken@intl.att.com>, "'ipfix@ietf.org'" <ipfix@ietf.org>
Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion
Date: Mon, Jan 15, 2018 1:51 PM
 
I fail to see why this would be the case. (But I agree that renaming
identifiers for the sake of renaming them is having little value.)

/js

On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote:
> In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types".
>
> -Andrew
>
> ________________________________
> From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz [muenz@net.in.tum.de]
> Sent: Saturday, January 13, 2018 4:43 AM
> To: Benoit Claise; Aitken, Paul; 'Marta Seda'
> Cc: 'ipfix@ietf.org'
> Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion
>
>
> Marta, all,
>
> A few additional thoughts regarding your questions:
>
> 1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist.
>
> 2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set.
>
> 3) SCTP is still a mandatory transport for a compliant implementation of an IPFIX device, not a feature. See: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7011-23section-2D10.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=qunYBh7bv5ABGGsiP6-CjGVRw8xFMTnuuwuibkkNfBE&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__tools.ietf.org_html_rfc7011-2523section-2D10.1-26c-3DE-2C1-2Cr3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWtTXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2D2Dh-5F-2DxePoq9GNzzaPGdYj0o-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=M0CgR7V3IlBqkpQDo2Brx-bewHWnHX_a5l7YChB32BI&e=>
>
> Best regards,
> Gerhard
>
>
>
> On 10.01.2018 08:33, Benoit Claise wrote:
> Hi,
> Marta, Benoit,
>
> 1. Are there efforts to update other RFCs to meet the latest YANG best practices?
> Yes. Ex: https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=Dml5zgSWzeUBwS1XyKmCG-y3bWePHxpzt3PCej4w_zw&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drfc7223bis_-26c-3DE-2C1-2C990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI-5FbfqIgW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap-5FiznZ68ZknJgFbizFJolgU-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=whhuVEyPDEyPYoboty-rb0h_RQBoHKqNmiQoGwpLBlw&e=>
> The goal is to specify NMDA-compliant (draft-ietf-netmod-revised-datastores-09<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Drevised-2Ddatastores_-26c-3DE-2C1-2CByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-2D78uXEs5xDZql2y-2D-2D4iDlmOUQ-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=gGNMKyVcGZrZBCbVl5XjjnnyJnRDUxt8jU3e24fcQBU&e=>) YANG modules
>
> 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time?
> This type of feedback should come from implementation experience.
>
> Regards, Benoit
> Note that it's > 5 years old.
>
> Also see @PJ inline:
>
>
> On 09/01/2018 16:01, Benoit Claise wrote:
> Hi Marta,
> Hello,
> I am reaching out to the IETF IPFIX mailing list  on some issues I have run into with respect to RFC 6728 “Configuration Data Model for the IP Flow Information Export (IPFIX)  and Packet Sampling (PSAMP) Protocols”
>
>
>   1.  RFC 6728 doesn’t meet the latest Yang Best Practices (https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D15-23section-2D4.3.1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=SSYo4WM-xFfyPgrSh-cja-jQFQEucW4daULPdwg2zSI&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__urldefense.proofpoint.com_v2_url-253fu-253dhttps-2D3A-5F-5Ftools.ietf.org-5Fhtml-5Fdraft-2D2Dietf-2D2Dnetmod-2D2Drfc6087bis-2D2D15-2D23section-2D2D4.3.1-2526d-253dDwMD-2Dg-2526c-253dLFYZ-2Do9-5FHUMeMTSQicvjIg-2526r-253df8F8yzrqBTw6EPtR1rbibO-5FVFIc-2DcdnjIJ9he-5Fqu7xs-2526m-253d0c5ATjuT0-2D4IlDzLYM9h-5FRbPjCBQUv-5F6aExRL-5Ffl-2D5M-2526s-253dHhi7V6njCFNBbSsjC6sPgNfVu5DA8iQzdzsnA-5FiQBzQ-2526e-253d-26c-3DE-2C1-2C5Zsm8llhIef-5FjTZU2aAY2fj-5FKvmJs-2DzBz2HIfVEkrhY7UwWsg3UnykcCPzCUM7b-5FL6CTmk-5FVY1-2DTo7t8aTM7RBz2ayGhe3OrxbBk7-5FOy6I7gQSkKDC8Eig-2C-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=oj6Kq-4SRjuodk73yxC5K1cDKw8XP95L_H_m3ErUuQM&e=>).   Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address).  Are there any ongoing efforts to update RFC 6728 to meet the latest best practices?
> Not as far as I know.
>
> Regards, Benoit
>
>
>   1.
>
>    Identifiers SHOULD follow a consistent naming pattern throughout the
>    module.  Only lower-case letters, numbers, and dashes SHOULD be used
>    in identifier names.  Upper-case characters and the underscore
>    character MAY be used if the identifier represents a well-known value
>    that uses these characters.
>
>    Identifiers SHOULD include complete words and/or well-known acronyms
>    or abbreviations.  Child nodes within a container or list SHOULD NOT
>    replicate the parent identifier.  YANG identifiers are hierarchical
>    and are only meant to be unique within the the set of sibling nodes
>    defined in the same module namespace.
>
>    It is permissible to use common identifiers such as "name" or "id" in
>    data definition statements, especially if these data nodes share a
>    common data type.
>
>    Identifiers SHOULD NOT carry any special semantics that identify data
>    modelling properties.  Only YANG statements and YANG extension
>    statements are designed to convey machine readable data modelling
>    properties.  For example, naming an object "config" or "state" does
>    not change whether it is configuration data or state data.  Only
>    defined YANG statements or YANG extension statements can be used to
>    assign semantics in a machine readable format in YANG.
>
>
>   1.  I generated the RFC 6728 yang tree (see attached).  The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory.  The type is inet:ip-address.
>
>      *   A collector may be doing load balancing.  Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located).
>
> @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet.
>
>
>
>   1.
>
>      *
>      *   The collector address may be learnt via other methods (e.g., through DHCP options)
>      *   A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728.  For example (use some shorthand)
>
> choice destination-method{
>                 case destination-address{
>                                 leaf destination-address// rw with type inet:host
>                 }
>                 case dhcp-acquired-address{
>                                 container dcp-acquired-address{
>                                                 leaf destination-ip-address inet-address //ro
>                 }
> }
>
>                                 However I can’t augment to ietf-ipfix because destinationIPAddress is mandatory.  Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice?
>
> @PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model.
>
>
>
>   1.  RFC 6728 mandates SCTP transport.  I understand the logic behind this (IETF prefers use of SCTP).  There are situations where sctp is unnecessary and not supported (e.g., point to point connection).  During netconf negotiations you can announce your feature set (currently sctptransport is not a feature).  Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)?
>
> @PJ Same answer as point (2) above, ie is this necessary and useful?
>
> P.
>
>
>
>
> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org<mailto:IPFIX@ietf.org>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=<https://urldefense.proofpoint.com/v2/url?u=https-3A__linkprotect.cudasvc.com_url-3Fa-3Dhttps-3A__www.ietf.org_mailman_listinfo_ipfix-26c-3DE-2C1-2CQcSaORG4ENECojkXawtykKdqqGaKdIQCAXU-5Fk7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyqMbCphIEyv8aBgtyyQbbN31fnbrx9I-2C-26typo-3D1&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cQFI-IsxLhklEI0w-JcCksB_YNvx9v06CpqsjQys0N8&e=>
>
>

> _______________________________________________
> IPFIX mailing list
> IPFIX@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=


--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=cC8C3QfrkIEC1Vo-QLwKrh955-evz_Tr3MYoFDTmD1A&e=>

_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=eSiUkUZU9l60y0gvR_UtUw4WaW__Jt3CBhpQR6Qa_kE&m=Aqj94ELpPz5BmoxxBT4zFaWhv6uxVZ5pB5BvoOLL3H8&s=zSpyB0Ig1-hgDSYsX7hH1qdwzy0nZuWAMrFjAY3q02U&e=
 
 



_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

--------------2B03182A9B4EFD4EF83D802A-- From nobody Mon Jan 15 14:35:23 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA5412D881 for ; Mon, 15 Jan 2018 14:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 rUty1FbJJYyn for ; Mon, 15 Jan 2018 14:35:20 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 0E0FE124BAC for ; Mon, 15 Jan 2018 14:35:20 -0800 (PST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0FMXnPv138271 for ; Mon, 15 Jan 2018 17:35:16 -0500 Received: from smtp.notes.na.collabserv.com (smtp.notes.na.collabserv.com [192.155.248.73]) by mx0a-001b2d01.pphosted.com with ESMTP id 2fh0a5v8nm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 15 Jan 2018 17:35:16 -0500 Received: from localhost by smtp.notes.na.collabserv.com with smtp.notes.na.collabserv.com ESMTP for from ; Mon, 15 Jan 2018 22:35:15 -0000 Received: from us1a3-smtp03.a3.dal06.isc4sb.com (10.106.154.98) by smtp.notes.na.collabserv.com (10.106.227.90) with smtp.notes.na.collabserv.com ESMTP; Mon, 15 Jan 2018 22:35:12 -0000 Received: from us1a3-mail64.a3.dal09.isc4sb.com ([10.142.3.135]) by us1a3-smtp03.a3.dal06.isc4sb.com with ESMTP id 2018011522351202-1138781 ; Mon, 15 Jan 2018 22:35:12 +0000 In-Reply-To: From: "Wayne Tackabury" To: ipfix@ietf.org Date: Mon, 15 Jan 2018 22:35:12 +0000 Sensitivity: References: MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) X-Mailer: IBM Verse Build 15909-1273 | IBM Domino Build SCN1734600_20171212T0033_FP3 January 05, 2018 at 15:38 X-LLNOutbound: False X-Disclaimed: 42615 X-TNEFEvaluated: 1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 x-cbid: 18011522-3107-0000-0000-0000049D4CCE X-IBM-SpamModules-Scores: BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.423878; ST=0; TS=0; UL=0; ISC=; MB=0.118706 X-IBM-SpamModules-Versions: BY=3.00008385; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000245; SDB=6.00975557; UDB=6.00494457; IPR=6.00755484; BA=6.00005778; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019056; XFM=3.00000015; UTC=2018-01-15 22:35:13 X-IBM-AV-DETECTION: SAVI=unsuspicious REMOTE=unsuspicious XFE=unused X-IBM-AV-VERSION: SAVI=2018-01-15 19:58:38 - 6.00007912 x-cbparentid: 18011522-3108-0000-0000-00007DD653F2 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-15_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [IPFIX] RFC 8158 applicability and breadth X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 22:35:21 -0000
Hi all:
 
I have two questions, and will separate them since they'r= e distinct, IPFIX-wise.
 
I'm noting the presence of RFC 8158, have briefly gone ov= er it.  It addresses IEs for "logging NAT events".
 
My question is this: in the formulation of these entities= , was the intent to have this be strictly the reporting domain for "classic= " NAT implementations, with configured pools and ports and static vs. dynam= ic mappings and all of that? 
 
Or, was there a considered "mission creep" :) to allow th= ese to be used for reporting on things like load balancers, firewall domain= address mapping, and the like, to report what their "pre-translated" addre= ss is on the source of a flow?  Keep in mind, the mapping for such a t= hing has nothing to do with the exporter itself (the exporter may just be d= etecting this from network traffic), so it would be quite wrong to use a so= urce vs. exporter address.
 
If using the RFC 8158 fields for this just seems....wrong= (I mean, it is translation....of an address), is there another (probably s= impler) set of fields for this that come to mind?  To be perfectly tra= nsparent here, if this was to be used for supporting the semantics of the "= Forwarded: " HTTP header as in RFC 7239, this would in fact have to be a li= st of addresses, but I'm just wondering if there was an IPFIX reporting pra= ctice for this using IANA elements even if the forwarded source was a scala= r address.
 
Thanks!
Wayne
 

From nobody Mon Jan 15 17:40:03 2018 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE6312D93E for ; Mon, 15 Jan 2018 17:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 q3JP5yonCAtm for ; Mon, 15 Jan 2018 17:39:58 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F1712D851 for ; Mon, 15 Jan 2018 17:39:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1FC2A60; Tue, 16 Jan 2018 02:39:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id qhMZYTPnrfQd; Tue, 16 Jan 2018 02:39:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 Jan 2018 02:39:55 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1C9B2013F; Tue, 16 Jan 2018 02:39:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lG1rLKsfillr; Tue, 16 Jan 2018 02:39:54 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4EEF02013E; Tue, 16 Jan 2018 02:39:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1A1B34210F23; Tue, 16 Jan 2018 02:39:48 +0100 (CET) Date: Tue, 16 Jan 2018 02:39:48 +0100 From: Juergen Schoenwaelder To: Marta Seda Cc: "'ipfix@ietf.org'" Message-ID: <20180116013948.gfodljd7nna7utut@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Marta Seda , "'ipfix@ietf.org'" References: <085c30b9-5797-863e-a63d-a027396f224f@gmail.com> <167798e2-f7a7-6946-8f3c-6bf996514bec@net.in.tum.de> <8E7542283B89BB4DB672EB49CEE5AAB7CDFB5429@PLXRDC01.plxr.local> <20180115185043.vj3ikpfqhsuycdm4@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2018 01:40:02 -0000 What makes you believe one cannot list a YANG 1.0 module in ietf-yang-library? If someone wants to work on a 'better' IPFIX module (or modules), the best approach is to write one and to post it as an I-D. And for writing a replacement module (or modules), it will be beneficial to have implementation experience. /js On Mon, Jan 15, 2018 at 08:35:22PM +0000, Marta Seda wrote: > Just a few things to consider about RFC 6728 (which is Yang 1.0 compliant). Following best practices is not the only issue with RFC 6728. It does not support Yang 1.1 (or RFC 7895 Netconf library). I am not promoting the idea of updating RFC 6728 (that is an IETF decision) but was trying to understand if there were any future plans to address the issues I brought up. Some additional points to think about: > > All SDOs (IEEE, IETF, BBF, MEF, etc) have migrated to Yang 1.1. Yang 1.1 supports the ietf-library module (see https://tools.ietf.org/html/rfc7895). In the "hypothetical" case where you were developing a brand new ipfix module, you could create multiple submodules (e.g., one for exporter, another for collector, etc). A device would import only those modules it supports (and use the netconf library to explicitly show deviations). That would be a "nice" improvement (right now RFC 6728 is one big module containing everything). However going back to reality, it would be a non-backwards compatible change and backward compatibility issues may be the reason for deciding not to do changes to ipfix psamp yang. > > If a vendor needs to support psamp, yang 1.1 and yang best practices, one option is to create their own yang module (and leave RFC 6728 behind) or promote the idea to another SDO (who may be creating new yang modules to support ipfix beyond what RFC 6728 defines today) to pick up the activity of reformulating psamp yang to take advantage of newer IETF functions (yang 1.1 and best practices). That assumes of course if IETF decides there is no need to update RFC 6728 (which I think is what I am hearing in this thread - no updates in RFC 6728). > > Regards, > > Marta Seda > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, January 15, 2018 10:51 AM > To: Andrew Feren > Cc: Gerhard Muenz ; Benoit Claise ; Aitken, Paul ; Marta Seda ; 'ipfix@ietf.org' > Subject: Re: [IPFIX] [QUAR] Re: RFC 6728 IETF IPFIX Yang Discussion > > I fail to see why this would be the case. (But I agree that renaming identifiers for the sake of renaming them is having little value.) > > /js > > On Mon, Jan 15, 2018 at 06:09:20PM +0000, Andrew Feren wrote: > > In particular renaming identifiers would break any implementations of RFC 7373 "Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types". > > > > -Andrew > > > > ________________________________ > > From: IPFIX [ipfix-bounces@ietf.org] on behalf of Gerhard Muenz > > [muenz@net.in.tum.de] > > Sent: Saturday, January 13, 2018 4:43 AM > > To: Benoit Claise; Aitken, Paul; 'Marta Seda' > > Cc: 'ipfix@ietf.org' > > Subject: [QUAR] Re: [IPFIX] RFC 6728 IETF IPFIX Yang Discussion > > > > > > Marta, all, > > > > A few additional thoughts regarding your questions: > > > > 1) I would not expect that not following current naming convention hinders implementation of RFC 6728. On the other hand, if we change just the names of the identifiers, we lose interoperability with older implementations that may exist. > > > > 2) I think that it is reasonable that destinationIPAddress is mandatory because network management systems should be able to query the IP address to which an Exporting Process sends data. As Paul stated, RFC 6728 does not say how the destination IP address is set. > > > > 3) SCTP is still a mandatory transport for a compliant implementation > > of an IPFIX device, not a feature. See: > > https://tools.ietf.org/html/rfc7011#section-10.1 > udasvc.com/url?a=https://tools.ietf.org/html/rfc7011%23section-10.1&c= > > E,1,r3o6fj1SXot8TQIPgevXNx5yfL8QvlF982Ch9DX27MByjz7bAdEaF9tjDoDzj1XgWt > > TXYfN1Z9mXiFy81bK1Aq33fYFzGl5W-2Dh_-xePoq9GNzzaPGdYj0o&typo=1> > > > > Best regards, > > Gerhard > > > > > > > > On 10.01.2018 08:33, Benoit Claise wrote: > > Hi, > > Marta, Benoit, > > > > 1. Are there efforts to update other RFCs to meet the latest YANG best practices? > > Yes. Ex: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/ > /linkprotect.cudasvc.com/url?a=https://datatracker.ietf.org/doc/draft- > > ietf-netmod-rfc7223bis/&c=E,1,990HtCyvSKBHwQOS7jpHkeSpsvC2M7iKDlI_bfqI > > gW2gpaEOYhngASoi8LRRhuM67bRdHS2Hyi7cVHyXDuiheARWFxSpap_iznZ68ZknJgFbiz > > FJolgU&typo=1> The goal is to specify NMDA-compliant > > (draft-ietf-netmod-revised-datastores-09 > om/url?a=https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-da > > tastores/&c=E,1,ByKxVFeHf8k0Yb1kzzkQnQg33VfrR12Hy6dJzQTbkgStXZt3NzfCi7 > > l981VvXCCM3L3iwQ3FF8lz77mT4C5yuZEfVe-78uXEs5xDZql2y--4iDlmOUQ,&typo=1> > > ) YANG modules > > > > 2. Since the IPFIX WG closed, there has been little ongoing IPFIX work in the IETF. Is there a specific need to update RFC 6728 rather than just recognising it as a product of it's time? > > This type of feedback should come from implementation experience. > > > > Regards, Benoit > > Note that it's > 5 years old. > > > > Also see @PJ inline: > > > > > > On 09/01/2018 16:01, Benoit Claise wrote: > > Hi Marta, > > Hello, > > I am reaching out to the IETF IPFIX mailing list on some issues I have run into with respect to RFC 6728 “Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols” > > > > > > 1. RFC 6728 doesn’t meet the latest Yang Best Practices (https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.3.1). Leaf identifiers are camel case (e.g., destinationAddress instead of destination-address). Are there any ongoing efforts to update RFC 6728 to meet the latest best practices? > > Not as far as I know. > > > > Regards, Benoit > > > > > > 1. > > > > Identifiers SHOULD follow a consistent naming pattern throughout the > > module. Only lower-case letters, numbers, and dashes SHOULD be used > > in identifier names. Upper-case characters and the underscore > > character MAY be used if the identifier represents a well-known value > > that uses these characters. > > > > Identifiers SHOULD include complete words and/or well-known acronyms > > or abbreviations. Child nodes within a container or list SHOULD NOT > > replicate the parent identifier. YANG identifiers are hierarchical > > and are only meant to be unique within the the set of sibling nodes > > defined in the same module namespace. > > > > It is permissible to use common identifiers such as "name" or "id" in > > data definition statements, especially if these data nodes share a > > common data type. > > > > Identifiers SHOULD NOT carry any special semantics that identify data > > modelling properties. Only YANG statements and YANG extension > > statements are designed to convey machine readable data modelling > > properties. For example, naming an object "config" or "state" does > > not change whether it is configuration data or state data. Only > > defined YANG statements or YANG extension statements can be used to > > assign semantics in a machine readable format in YANG. > > > > > > 1. I generated the RFC 6728 yang tree (see attached). The tcp and udp exporting processes support a destinationIPAddress (line 400, 455) which is mandatory. The type is inet:ip-address. > > > > * A collector may be doing load balancing. Rather than managing ip-addresses, the collector may be using DNS (an exporter could resolve from the domain name where the collector is located). > > > > @PJ: Load balancing and DNS are independent. Load balancing IPFIX is probably a bad idea since templates need to be available on all collectors, and out of step sequence numbers in the data records would cause spurious reports of lost data. If DNS is used to obtain the collector's address, arguably it should be a one-time lookup rather than incurring a DNS lookup per export packet. > > > > > > > > 1. > > > > * > > * The collector address may be learnt via other methods (e.g., through DHCP options) > > * A choice statement to select what method to use seems more appropriate than what is presently in RFC 6728. For example (use some shorthand) > > > > choice destination-method{ > > case destination-address{ > > leaf destination-address// rw with type inet:host > > } > > case dhcp-acquired-address{ > > container dcp-acquired-address{ > > leaf destination-ip-address inet-address //ro > > } > > } > > > > However I can’t augment to ietf-ipfix because destinationIPAddress is mandatory. Can the group suggest methods to (a) change the destinationIPAddress type and (b) allow a choice? > > > > @PJ: The selection could also be done out of band so the exporter need not know how the address is determined. eg a configuration system could determine the address by any of these methods or otherwise, and impose that address using the current model. > > > > > > > > 1. RFC 6728 mandates SCTP transport. I understand the logic behind this (IETF prefers use of SCTP). There are situations where sctp is unnecessary and not supported (e.g., point to point connection). During netconf negotiations you can announce your feature set (currently sctptransport is not a feature). Is there ongoing work in updating RFC 6728 to include sctptransport as a feature (so that the device can announce whether or not it supports sctptransport)? > > > > @PJ Same answer as point (2) above, ie is this necessary and useful? > > > > P. > > > > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > c.com/url?a=https://www.ietf.org/mailman/listinfo/ipfix&c=E,1,QcSaORG4 > > ENECojkXawtykKdqqGaKdIQCAXU_k7DUoimbxp4p9KhoEppQlQ1LswK1E5yY5kvIL8XYyq > > MbCphIEyv8aBgtyyQbbN31fnbrx9I,&typo=1> > > > > > > > _______________________________________________ > > IPFIX mailing list > > IPFIX@ietf.org > > https://www.ietf.org/mailman/listinfo/ipfix > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103