From nobody Tue Apr 4 03:09:09 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E831B12946A for ; Tue, 4 Apr 2017 03:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 NiMwWSTnQoZc for ; Tue, 4 Apr 2017 03:09:06 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40095.outbound.protection.outlook.com [40.107.4.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21387129452 for ; Tue, 4 Apr 2017 03:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mq22x1148UbAotox+ea0C4RpHvx5jMPqvkn49v8z+ZE=; b=oUIKkS+Gz3YLEjie8wtnKkIjoLRoTBN9YlF9o9XQYD48M7k+SdyfaCy/nKKaon6A9Ck4qawYBtJMQU5Sd5XBuQ62mASbNKVA0y9TVyRCfPVN/TpeB2+QQEaQ6FeRcpXNXN8rp2gAEqxmpPqb/j9IL/PxScibRpBE6T5Iyb5V4aY= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 10:09:01 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.1019.015; Tue, 4 Apr 2017 10:09:01 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: System management YANG model Thread-Index: AdKtKwNhMMqt8I09QG+baq8II5jbJg== Date: Tue, 4 Apr 2017 10:09:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.3] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0627; 7:fyEaBxdGxlJSXh0XpfNHKVqV81WG8iQglE7fKS8tTmRwqcEygfQbLi+IskTomMnA6YVgSZShaHHngK8ZkZ7zcBn194zRCKGSMKyLydsm5zFogunAESwrbBoGpjwwve996LnP3eCNvWD/nHVdyrwnfCxmfyCfSj1FSO1cDlepZ2iGbGuTis7Ih7URmZImc9852/+SYCiQcUO2w+/lM99uRgfLhAHTWys6h9r6FhU2Nrzob16tzLO55Uo8T2eGWaMuYw1TNMN9JbamBF7RdHFyf/nubc73lpwwNVM6Dl++NKFQ8YXuFXPx+Za0+DUfkHb7x/yNVSw3SnUd8pIF2gWzEw== x-ms-office365-filtering-correlation-id: 2bf98121-9d69-4c33-13b9-08d47b429e05 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM2PR07MB0627; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:AM2PR07MB0627; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0627; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39840400002)(39450400003)(39850400002)(39860400002)(39400400002)(39410400002)(6916009)(74316002)(99936001)(1730700003)(54356999)(50986999)(8936002)(66066001)(6116002)(790700001)(7736002)(102836003)(3480700004)(9326002)(2900100001)(86362001)(81166006)(8676002)(3846002)(53936002)(9686003)(122556002)(2906002)(77096006)(6436002)(6506006)(54896002)(6306002)(7696004)(5640700003)(99286003)(55016002)(2351001)(5660300001)(3280700002)(3660700001)(25786009)(2501003)(110136004)(38730400002)(33656002)(5630700001)(189998001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0627; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A8_01D2AD3C.3D22F5B0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 10:09:01.2240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0627 Archived-At: Subject: [netmod] System management YANG model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:09:08 -0000 ------=_NextPart_000_00A8_01D2AD3C.3D22F5B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A9_01D2AD3C.3D22F5B0" ------=_NextPart_001_00A9_01D2AD3C.3D22F5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, When looking at the system time management part of this model I notice that for ntp only a config true section is foreseen. But assume that we learn at run-time the NTP server (e.g. using DHCP), there is no config false data part to reflect what has been learned dynamically. Storing this in the config true part does not seem to be correct to me since this might get lost because of a copy-config action (in case a NC client never configured something there). Are we not missing a server-list in the state data? Best regards - Vriendelijke groeten, Bart Bogaert ------=_NextPart_001_00A9_01D2AD3C.3D22F5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When looking at the system time management part of this = model I notice that for ntp only a config true section is = foreseen.  But assume that we learn at run-time the NTP server = (e.g. using DHCP), there is no config false data part to reflect what = has been learned dynamically.  Storing this in the config true part = does not seem to be correct to me since this might get lost because of a = copy-config action (in case a NC client never configured something = there).  Are we not missing a server-list in the state = data?

 

Best regards - Vriendelijke groeten,

Bart Bogaert

------=_NextPart_001_00A9_01D2AD3C.3D22F5B0-- ------=_NextPart_000_00A8_01D2AD3C.3D22F5B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MDQxMDA4NThaMCMGCSqGSIb3DQEJBDEWBBQK7zFh Z0sBGeaUKkdWe9ekwLr71TCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAI0CuSbxvRo5EIQtrZ5BCHO2qpUp8P+jY053WSJPK2dJ49x+ty4IVs4wH71C L1GIgvHR99p2EphMiD0lCF2VMh/dqH5R6dFgVytaW/pj2M5ek6MtgwjyEm2LRWyF6cMJLUxlkZXX 9JG+S7l6nKt7peerA/WgXPuK6dn8TDaBCUAhYf/DY0T1xDo2qema4wE9wvtln3GZLeD9XOQ2xB+m Z1Yla7a26p9MCjeQOWtIFXMhjQBSFmBbs1lYRWGGFX+kGBltJNRrx6/6wVXwl4P+nqaBUFlhk3LV dJN0iZipCeDru04aZPIDhljJeIlpZcZNbZwzg+FzQeJWIL5SyPu9rNoAAAAAAAA= ------=_NextPart_000_00A8_01D2AD3C.3D22F5B0-- From nobody Tue Apr 4 03:45:09 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14945128D44 for ; Tue, 4 Apr 2017 03:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCUkh4e2Fxlf for ; Tue, 4 Apr 2017 03:45:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D8D126D73 for ; Tue, 4 Apr 2017 03:45:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6B1651425; Tue, 4 Apr 2017 12:45:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id pBqaMVF_pUyb; Tue, 4 Apr 2017 12:45:00 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 4 Apr 2017 12:45:01 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B200820045; Tue, 4 Apr 2017 12:45:01 +0200 (CEST) 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 TF_le-SkIX9S; Tue, 4 Apr 2017 12:45:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 034CB2003D; Tue, 4 Apr 2017 12:45:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E6B3E3F0DDF9; Tue, 4 Apr 2017 12:45:03 +0200 (CEST) Date: Tue, 4 Apr 2017 12:45:02 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: "netmod@ietf.org" Message-ID: <20170404104502.GA65258@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] System management YANG model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:45:06 -0000 On Tue, Apr 04, 2017 at 10:09:01AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hi, > > When looking at the system time management part of this model I notice that > for ntp only a config true section is foreseen. But assume that we learn at > run-time the NTP server (e.g. using DHCP), there is no config false data > part to reflect what has been learned dynamically. Storing this in the > config true part does not seem to be correct to me since this might get lost > because of a copy-config action (in case a NC client never configured > something there). Are we not missing a server-list in the state data? > Yes, but the good news is that the revised datastore architecture solves this issue without requiring any changes to the model. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 4 03:49:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78541287A0 for ; Tue, 4 Apr 2017 03:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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=-2.796, SPF_HELO_PASS=-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=nokia.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 f0TVPqtU2SRB for ; Tue, 4 Apr 2017 03:49:38 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0117.outbound.protection.outlook.com [104.47.2.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1661127F0E for ; Tue, 4 Apr 2017 03:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MoTbuvBYXrMSix5VYPbza8rkw5ov6o/EvCpSdzzPOuA=; b=hU3QTcmS+8mAxuhvI0ZEGb7ouSg9J7DYWUuPmxC5EzZvC7isahrTXsMB/5okTF0yRLBBuvw8AP5Im9WwfC1vuXzrUNRxietHNcgMey1ehN5X3YzCLxdRMOFBfANMPjt9rDJZUwTzrPSV5ylK7ZcCf0Y23A/xOE16V6PSF0A0UDI= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0625.eurprd07.prod.outlook.com (10.160.54.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Tue, 4 Apr 2017 10:49:35 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([10.160.54.154]) with mapi id 15.01.1019.015; Tue, 4 Apr 2017 10:49:34 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] System management YANG model Thread-Index: AdKtKwNhMMqt8I09QG+baq8II5jbJgABX/oAAAAYpJA= Date: Tue, 4 Apr 2017 10:49:34 +0000 Message-ID: References: <20170404104502.GA65258@elstar.local> In-Reply-To: <20170404104502.GA65258@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.212.3] x-microsoft-exchange-diagnostics: 1; AM2PR07MB0625; 7:TPqg/XrAMh5Wk3Rrh05/A0tDj6B0f/ckC0SId4yVZ/JybZPqXgyT7MVDfFSah1n25A9+ogZC/HZgEhS3RAiZwthcsd8wScXeiYflrpVALB0QWh4KNH7uDp1E0uIlHDmHLwkHIP5aWdqeeL9XfyxXwHOjpfPXt0P8CXdIpAZGZ9TAHJj7r1dbLbNAETN1ecz9Fa6ws16QYomGMEux+0whmnLtLHQlnBoJc+gGCGVFlzq42Uy+VZP7ZlfvcPTi5uuHaAcsBYXY+iu9MOMVJpzlOP5ZTvHeCps9CLiRQQ9oZ2/I3dm6M2feh3GSaGF1vUo3PWxFoVb6V4ev7bY65ikfQg== x-ms-office365-filtering-correlation-id: 5dec5c9d-a611-49ea-4cb3-08d47b484859 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM2PR07MB0625; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM2PR07MB0625; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0625; x-forefront-prvs: 0267E514F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39410400002)(39850400002)(39840400002)(39860400002)(39450400003)(24454002)(2900100001)(3660700001)(3280700002)(2906002)(8676002)(8936002)(81166006)(66066001)(4326008)(38730400002)(6246003)(122556002)(3846002)(102836003)(6116002)(305945005)(7736002)(33656002)(74316002)(5660300001)(189998001)(6306002)(55016002)(99286003)(9686003)(229853002)(53936002)(25786009)(7696004)(2950100002)(6916009)(6506006)(50986999)(54356999)(77096006)(99936001)(86362001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0625; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00E1_01D2AD41.E8914640" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2017 10:49:34.6365 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0625 Archived-At: Subject: Re: [netmod] System management YANG model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 10:49:41 -0000 ------=_NextPart_000_00E1_01D2AD41.E8914640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Apr 04, 2017 at 10:09:01AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hi, > > When looking at the system time management part of this model I notice > that for ntp only a config true section is foreseen. But assume that > we learn at run-time the NTP server (e.g. using DHCP), there is no > config false data part to reflect what has been learned dynamically. > Storing this in the config true part does not seem to be correct to me > since this might get lost because of a copy-config action (in case a > NC client never configured something there). Are we not missing a server-list in the state data? > Yes, but the good news is that the revised datastore architecture solves this issue without requiring any changes to the model. ;-) [Bart Bogaert] Ok, but there is no NC server implementing this yet so this means that everybody needs to solve it in their way if this is needed now? Doesn't this raise an interop issue if different approaches are taken? Regards, Bart /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_00E1_01D2AD41.E8914640 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MDQxMDQ5MzNaMCMGCSqGSIb3DQEJBDEWBBRZC0am dOR3pUQs0k2kog1ku7Nb8jCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAGpDPAu7kajS9a2ax7wdK13AEXBoiaagfx31uSOVM5ErXUQQpLrXDOI7KX6N zCqWdpfE3Qeuwzz476vwtZq/K30pYkV7h8jCBKdTbr3W5WBNfewj24r80Lvc5c5G7wp6KTjeA5sq udp2iqt4/U+HOr0FpxCjC65v+tlZ7OWapGv2RC0Xi+CSnwf4/vdC6aVeCEPVOzRI3LTdVX7Zx/PL Jh90MBxmHr+uXm+c+OGCVr7eFkKGzRiuO4LsAsEeNe6hZ/qKKbbbF+J+2qX6k7NFIHPj3qx/VXPl Ru+4LnE/9GlUO9uQTyREtiFH0e13FQlqhto0+gVLfA5UIKoJUhyFjeUAAAAAAAA= ------=_NextPart_000_00E1_01D2AD41.E8914640-- From nobody Tue Apr 4 04:25:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D346A12957A for ; Tue, 4 Apr 2017 04:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch5Al8PGZIYH for ; Tue, 4 Apr 2017 04:25:05 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C88127843 for ; Tue, 4 Apr 2017 04:25:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AC67B1402; Tue, 4 Apr 2017 13:25:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id D7dCloT64x_r; Tue, 4 Apr 2017 13:25:02 +0200 (CEST) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 4 Apr 2017 13:25:03 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BE5D20044; Tue, 4 Apr 2017 13:25:03 +0200 (CEST) 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 PtpfP284qyuY; Tue, 4 Apr 2017 13:25:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C2492003A; Tue, 4 Apr 2017 13:25:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5C5C43F0DF07; Tue, 4 Apr 2017 13:25:07 +0200 (CEST) Date: Tue, 4 Apr 2017 13:25:07 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: "netmod@ietf.org" Message-ID: <20170404112507.GB65258@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170404104502.GA65258@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] System management YANG model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 11:25:07 -0000 On Tue, Apr 04, 2017 at 10:49:34AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > On Tue, Apr 04, 2017 at 10:09:01AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) > wrote: > > Hi, > > > > When looking at the system time management part of this model I notice > > that for ntp only a config true section is foreseen. But assume that > > we learn at run-time the NTP server (e.g. using DHCP), there is no > > config false data part to reflect what has been learned dynamically. > > Storing this in the config true part does not seem to be correct to me > > since this might get lost because of a copy-config action (in case a > > NC client never configured something there). Are we not missing a > server-list in the state data? > > > > Yes, but the good news is that the revised datastore architecture solves > this issue without requiring any changes to the model. ;-) > > [Bart Bogaert] Ok, but there is no NC server implementing this yet so this > means that everybody needs to solve it in their way if this is needed now? > Doesn't this raise an interop issue if different approaches are taken? There is not standard yet to report an NTP server learned say via DHCP. Reporting a dynamically learned NTP server is simply not part of the system model - so yes you can't expect interoperability for this. I doubt that the system model will be changed to add a specific state object for this given the direction we are moving to. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Apr 4 09:31:55 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7627112422F; Tue, 4 Apr 2017 09:31:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149132350838.1047.3054142067171081053.idtracker@ietfa.amsl.com> Date: Tue, 04 Apr 2017 09:31:48 -0700 Archived-At: Subject: [netmod] Warren Kumari's No Objection on charter-ietf-netmod-08-02: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 16:31:48 -0000 Warren Kumari has entered the following ballot position for charter-ietf-netmod-08-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This seems clear to me. Not sure if this is the place to address this, but the milestones seem, um, aggressive... :-) From nobody Thu Apr 6 10:43:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1CB12422F for ; Thu, 6 Apr 2017 10:43:28 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JucVHMkpKlgv for ; Thu, 6 Apr 2017 10:43:25 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFA7128DE5 for ; Thu, 6 Apr 2017 10:43:25 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id c55so125952wrc.3 for ; Thu, 06 Apr 2017 10:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rkvm5cbUEvF10a6yOvcA/F9McN7WA45NjoH9N/WSAf0=; b=PRUtS1nul1VILBg/RdPl9jPgllHgXgeNMFmMRRMzD3+68Fll4OtoCdMMwr1x5RNgY5 pKT/y9gSROWbR+UIFU+Alr4Z35MPINf3QRPyenkVaMwgtXwu80ZOiRIOoWCq7NzzkWKR 60dkHxJSRixphqyNdiwQIeKAK4cDmSIYyRSgeAt8HHFeXXKdwtW8bvtsLiz2eJJXX9aP j0AHpjoebGDNdJhCgZ3wPPvOY9Ws1YvYpK/8krj6hwsg1i0cd6eLJF+O8pZ86HOJAzpy G3b2HBgPZMKdVtUGL1oAqAX6jerTbsVezYFnRm+NE1dA+OArgFxGnbS83aYRRD/lHy9H nAFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rkvm5cbUEvF10a6yOvcA/F9McN7WA45NjoH9N/WSAf0=; b=jvIwpu+Zlmo0ZtywRsUWHo51+Q/cjfXLkzO9Qd12Du1Oa9fkD8a/kBfOSYGqp5KJTT fOFaeCJttX2JED3dxVLroluL0apUbPbMgYtT3fA9ER+7brfRC0kMy9Ejq2be1dsPgWv5 cdjBbWLpyH6PtyJafujeqNqg+FeQONvxEL7pnvfXWfzjMuEqdQhCdlLtzjwwykqLkL17 QoQcMZx108Xw+NEQ/nUPSqk7mzqUoIXOGlUDrGllWvfnPhokaXXOgx23s5hx9eiN0yL6 XakmoLsm0UkWcQwtbBLGSTieg0l0k1iR8Snfi3jmx5daGTvGNNPsbEAQvoYeQMK2D06o qRLg== X-Gm-Message-State: AFeK/H0MPvY2BSia7dz+zDYNYiCY+sLc0/r89lig0ZeqDhyHzbPGLnuoz/vvVVENTCj+Kemi2FCLmKn0i15tIw== X-Received: by 10.223.161.70 with SMTP id r6mr30043400wrr.65.1491500603978; Thu, 06 Apr 2017 10:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.21 with HTTP; Thu, 6 Apr 2017 10:43:23 -0700 (PDT) From: Andy Bierman Date: Thu, 6 Apr 2017 10:43:23 -0700 Message-ID: To: "netmod@ietf.org" , YANG Doctors Content-Type: multipart/alternative; boundary=f403045e274aaece21054c830bd9 Archived-At: Subject: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:43:28 -0000 --f403045e274aaece21054c830bd9 Content-Type: text/plain; charset=UTF-8 Overall: The document is well-written and almost ready for publication Comments: 1) No examples or guidance for "encaps-type" The document does not really define the standards value for this empty choice. There are no examples showing its use. More work is needed for this part of the module. The following TODO needs to be resolved and the note removed from the document: /* * TODO - Should we introduce an abstract type to make this * extensible to new interface types, or vendor * specific interface types? */ 2) normative overlap The text and layout of sec. 3 is good. The issue is that the YANG module text copies from this section in some places (leafs) and references it in others (feature definitions) Some parts like "half-life" are more detailed in the leaf definition than the plain text in sec. 3 Perhaps the leaf definitions can have reference-stmts added as needed, so it is clear that the YANG leaf is not the entire normative text. The YANG descriptions are good, but maybe not complete wrt/ sec. 3 additional text. sec 3.7 typo: the existing the sub-interface ^^^ remove extra 'the' 3) identity ethSubInterface This identity is used in the encapsulation container when-stmt. It is not clear if this is intended as a base identity (like identity sub-interface) An example for the encapsulation container would help clarify the expected usage This also has 2 bases (sub-interface and l2vlan). Some explanation in the identity-stmt would be helpful (since this is a new YANG 1.1 construct) Andy --f403045e274aaece21054c830bd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Overall:

The document is= well-written and almost ready for publication

Com= ments:

1) No examples or guidance for "encaps-t= ype"

The document does not really define the = standards value
for this empty choice.=C2=A0 There are no example= s showing its use.
More work is needed for this part of the modul= e.

The following TODO needs to be resolved and the= note removed
from the document:

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/*
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 * TODO - Should we introduce an abstract type to make = this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 = =C2=A0 =C2=A0extensible to new interface types, or vendor
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * =C2=A0 =C2=A0 =C2=A0 =C2=A0specific in= terface types?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
=

2) normative overlap

The= text and layout of sec. 3 is good.
The issue is that the YANG mo= dule text copies from this section
in some places (leafs) and ref= erences it in others (feature definitions)

Some pa= rts like "half-life" are more detailed in the leaf definition
than the plain text in sec. 3

Perhaps the l= eaf definitions can have reference-stmts added
as needed, so it i= s clear that the YANG leaf is not the
entire normative text.=C2= =A0 The YANG descriptions are good,
but maybe not complete wrt/ s= ec. 3 additional text.


sec 3.7 typo= :

the existing the sub-interface
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^^^ =C2= =A0remove extra 'the'

3) identity ethSubIn= terface

This identity is used in the encapsu= lation container when-stmt.
It is not clear if this is intended a= s a base identity (like identity sub-interface)
An example for th= e encapsulation container would help clarify the
expected usage

This also has 2 bases (sub-interface and l2vlan).
Some explanation in the identity-stmt would be helpful
(= since this is a new YANG 1.1 construct)


=

Andy

--f403045e274aaece21054c830bd9-- From nobody Fri Apr 7 07:57:18 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AE6129455; Fri, 7 Apr 2017 07:57:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149157703604.11211.13618838228195849786.idtracker@ietfa.amsl.com> Date: Fri, 07 Apr 2017 07:57:16 -0700 Archived-At: Subject: [netmod] Eric Rescorla's No Objection on charter-ietf-netmod-08-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 14:57:16 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-netmod-08-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ There are no remarks associated with this position. From nobody Fri Apr 7 15:50:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553A6128DE7 for ; Fri, 7 Apr 2017 15:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 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, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 CTcRsSPZsSzt for ; Fri, 7 Apr 2017 15:50:35 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30098.outbound.protection.outlook.com [40.107.3.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483F9128B8E for ; Fri, 7 Apr 2017 15:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VmSJmk+qQ2NsAHHBMXMOp71nGwoCpX/tz0j2IF2vLQ8=; b=jRZM/NiV4FKF7zZUQ2OA0QhcBudVo5nGZl+ufPBGFnezlIL4/Dxv/uTtVvUEqxEYg39MQn3kVvgkmenX9ysGBMkwrjdm5i8mSy8YUg94JwSziMi0Rye2FUqz+5aBZxXFvofzmC8RIBrsSXlO40HonLBC2zrwFYiK/yVYkRzn+wI= Received: from HE1PR07MB0843.eurprd07.prod.outlook.com (10.162.24.16) by HE1PR07MB0844.eurprd07.prod.outlook.com (10.162.24.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Fri, 7 Apr 2017 22:50:28 +0000 Received: from HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) by HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) with mapi id 15.01.1034.007; Fri, 7 Apr 2017 22:50:28 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: choice statements and trim vs explicit default handling Thread-Index: AdKv6w7/8xX3pfT5TQy0uN4Yo4P2Tw== Date: Fri, 7 Apr 2017 22:50:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.8] x-microsoft-exchange-diagnostics: 1; HE1PR07MB0844; 7:TVUxU5eaxQvyUq2OQuFyYTaXvV4QI8fs8/ItEkwQuD28hQ0IBsvd/xhDHEgFfHOt/qaE6wUQ9psFIrznkKZQhxHzCG7wIkkKFJFotNsmXvkH+Rw2OeFSAuTNFbS91ddaEFB9K/SdQdYkWD8AWgnDH8RNXkAOePGJy2s9OeFNQp8uE0F6sVIv7nn8WLRiUokqq8klrzacIzJt0yO2WLrCkzs9I50Wwzocu9KAALBljGcOWJUiwjWDZGQ4Syh0HOSIRjkA0RR7ANZkyQj4Vbwfqb7gDT2o+a3U1cw+SGHZItTHO3oA1cGO+0JTVtN8PoUzcoPMH/S5PfC0d/Rg4DhzKQ== x-ms-office365-filtering-correlation-id: 7d0a4f33-2dc6-4dd7-6bc6-08d47e087cd6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:HE1PR07MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:HE1PR07MB0844; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0844; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39840400002)(39450400003)(39850400002)(39860400002)(53754006)(86362001)(2501003)(6306002)(38730400002)(6506006)(189998001)(53936002)(66066001)(25786009)(7696004)(19609705001)(6916009)(2906002)(55016002)(3280700002)(110136004)(3660700001)(54896002)(2351001)(77096006)(33656002)(74316002)(7736002)(5630700001)(6436002)(122556002)(8676002)(5640700003)(9686003)(3846002)(50986999)(102836003)(81156014)(99286003)(8936002)(1730700003)(54356999)(2900100001)(790700001)(6116002)(81166006)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0844; H:HE1PR07MB0843.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB08433E9459870BCF06F754349B0C0HE1PR07MB0843eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 22:50:28.3941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0844 Archived-At: Subject: [netmod] choice statements and trim vs explicit default handling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 22:50:40 -0000 --_000_HE1PR07MB08433E9459870BCF06F754349B0C0HE1PR07MB0843eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, When a server operates in 'trim' mode (rfc6243), setting a leaf to its defa= ult value removes it from the config (i.e. it is indistinguishable from the= case where that leaf was never configured or the case where that leaf was = deleted/removed). (A) Does setting a leaf in one case of a choice to its default value (in a 'tri= m' mode server) cause leafs in other cases to be implicitly deleted ? I as= sume not. For example: choice foo { case aa { leaf some-bool { type Boolean; default "false"; } { case bb { leaf some-num { type int32; } } } If some-num is currently set to 50, and then an edit-config sets some-bool = to "false", does that clear the some-num leaf ? (i.e. does it select case aa ?) RFC 7950 says: "the creation of a node from one case implicitly deletes all= nodes from all other cases". RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim serv= er) doesn't exist. (B) Now how about if the server operates in 'explicit' mode ? Does setting som= e-bool to "false" clear some-num ? I assume it does (but it just seems a l= ittle funny that the behavior on this changes between trim and explicit ser= vers). Regards, Jason --_000_HE1PR07MB08433E9459870BCF06F754349B0C0HE1PR07MB0843eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

When a server operates in ‘trim’ mode (rfc6243), setting = a leaf to its default value removes it from the config (i.e. it is indistin= guishable from the case where that leaf was never configured or the case where that leaf was deleted/removed).

 

(A)

Does setting a leaf in one case of a choice to its default value (in = a ‘trim’ mode server) cause leafs in other cases to be implicit= ly deleted ?  I assume not.

 

For example:

 

choice foo {

  case aa {

    leaf some-bool { type Boolean; default “fals= e”; }

  {

  case bb {

    leaf some-num { type int32; }

  }

}

 

If some-num is currently set to 50, and then an edit-config sets some= -bool to “false”, does that clear the some-num leaf ?

(i.e. does it select case aa ?)

 

RFC 7950 says: “the creation of a node from one case implicitly= deletes all nodes from all other cases”.

RFC 6243 section 2.2.3 describes that a leaf set to default (in a tri= m server) doesn’t exist.

 

(B)

Now how about if the server operates in ‘explicit’ mode ?=   Does setting some-bool to “false” clear some-num ? = I assume it does (but it just seems a little funny that the behavior on th= is changes between trim and explicit servers).

 

 

Regards,

Jason

 

 

 

 

 

--_000_HE1PR07MB08433E9459870BCF06F754349B0C0HE1PR07MB0843eurp_-- From nobody Fri Apr 7 16:23:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BF1127097; Fri, 7 Apr 2017 16:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 9zGBpEM3MDcY; Fri, 7 Apr 2017 16:23:00 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5BE128DE7; Fri, 7 Apr 2017 16:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xylqFWQeFbUUUoeI0RnpdUW7njakszeLzX1yHKzAdoE=; b=NRO9LN7aGDXZCSHv6IuzEM0jJp+baiwJOeAEnzYktvm8IK12uGHzn07IqgbKSdh1p1dXc9XO+EkPp680q6lbpmaXkBIrETl9OC77ecHVnozpGvsQ0HENqGKtaEeWlIvcfHn1Oq845k7atG2XZbcN+IsNCPfl8jvw4wXwikCvNZE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 7 Apr 2017 23:22:52 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1034.005; Fri, 7 Apr 2017 23:22:52 +0000 From: Kent Watsen To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams Thread-Index: AQHSr/Xg1jVz8di74UG+w/RFCeh9Ow== Date: Fri, 7 Apr 2017 23:22:51 +0000 Message-ID: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:Qcll+sWqH6yleKwJoDI+3tcVrmLKVFfDFHfJYIgZj3OgfWIpZkXEMVaXzByxqiRtugUW2xmhblZM+Cev+HFZgRcSZY/a4awkkDfeKX1BBSpEdNdVXcaSnypN+AZ0SLL8pZ8gSUyYCfxmYxoQQa17a5WgFp89/Qv/YlghdXqsetbGY9+ZWA2NGzM8JgawtfdUDopGfB6IMW6QkUohOSFDfF/NIt2F0uHJd8sZ1l9GzSTNyfztGQvzKUDanla9aI9HG6GuZcOhEqxzN2ueC8AyT0v3KLjH+K28XRXyqjBxZNTiFDwN1RHqVWAqURSIUbWQIokOca6R0uDKD79QinTdVQ== x-ms-office365-filtering-correlation-id: a508832f-3bcb-45ff-f208-08d47e0d0347 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39410400002)(39400400002)(39450400003)(39860400002)(6116002)(102836003)(3846002)(82746002)(7736002)(83506001)(6512007)(230783001)(66066001)(110136004)(6916009)(33656002)(86362001)(53936002)(189998001)(122556002)(2900100001)(83716003)(305945005)(5660300001)(2351001)(4326008)(38730400002)(8676002)(81166006)(1730700003)(99286003)(8936002)(2906002)(6506006)(3280700002)(3660700001)(36756003)(50986999)(2501003)(54356999)(5640700003)(6486002)(25786009)(6436002)(450100002)(4001350100001)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <145317187AE23E49B6D211ACF04F4A8B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 23:22:51.9553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:23:08 -0000 QWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvLXdlZWsgcG9sbCBvbiBtYWtpbmcgdGhlIGZv bGxvd2luZyBkcmFmdCBhIA0KTkVUTU9EIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ6DQoNCiAgZHJh ZnQtYmpvcmtsdW5kLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMNCg0KUGxlYXNlIHNlbmQgZW1h aWwgdG8gdGhlIGxpc3QgaW5kaWNhdGluZyAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3QNCnN1 cHBvcnQiLiAgSWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgcmVzZXJ2YXRpb25z IHdpdGggdGhlDQpkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHBy b3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZQ0KdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1 bWVudCBpcyBhIFdHIGRvY3VtZW50Lg0KDQoNClRoYW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFpcnMN Cg0KDQo= From nobody Fri Apr 7 16:25:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF21294A9; Fri, 7 Apr 2017 16:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 tCTpuRKeeFOk; Fri, 7 Apr 2017 16:24:48 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0138.outbound.protection.outlook.com [104.47.42.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64625127097; Fri, 7 Apr 2017 16:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pVYl8UjFU8Dc77oWeUlESbjHaJ4VnO8mRR77qMTJcsY=; b=ObxC9zLLanHuyIh2d3hPCVXqvdYstBDaCRA3UFDO/0yV5WUYhCg4cbL5snc0Jy7hA8v07gO351UByToOVLuh296OXQwDtTbDVPkXOREVz68whYq6NQtcKp6zkByPaDIXlb31AljW6shAOrjka2aMFIWRn/djZrTmt4Arrtyrrqc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 7 Apr 2017 23:24:23 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1034.005; Fri, 7 Apr 2017 23:24:23 +0000 From: Kent Watsen To: "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG adoption poll draft-lhotka-netmod-yang-markup-00 Thread-Index: AQHSr/YXcDS5bbna6UeIPfM5lrW/TA== Date: Fri, 7 Apr 2017 23:24:23 +0000 Message-ID: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:303uyN/lTbMeTtkCzP3ZQmdLIsQdRpV0Zjs6Y/gBrC3udi5ma+ie2Zoys7C+onil4ocUQmXd6arfDb2GoE/PFpuMmNy2iNhGE7VbpfRr4VdxG7942kqr5tqfj4n6mBMC8CqRuzZhir390KjPeKT5t20EGhf5adpk3oVMRmFREgj2Nx07qWFyAr35YZT6/5KhmGADyroCM+8zSfJ+n/ArBbfdb3eVy0+zL2EG87+47F7QspsOUvB8gClJ6KE4FE373ht/0wi9jYcNsQZl674PRclIFW6gDiGcASlR22pK4y9KyILmYENCOMJHhKvfweiIs48NS22u0hzUCW/1vYkpig== x-ms-office365-filtering-correlation-id: 0397403d-a67c-4f84-8dea-08d47e0d39a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39410400002)(39400400002)(39450400003)(39860400002)(6116002)(102836003)(3846002)(82746002)(7736002)(83506001)(6512007)(230783001)(66066001)(110136004)(6916009)(33656002)(86362001)(53936002)(189998001)(122556002)(2900100001)(83716003)(305945005)(5660300001)(2351001)(4326008)(38730400002)(8676002)(81166006)(1730700003)(99286003)(8936002)(2906002)(6506006)(3280700002)(3660700001)(36756003)(50986999)(2501003)(54356999)(5640700003)(6486002)(25786009)(6436002)(450100002)(4001350100001)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5A2D60A865ABF04589AC55EB0C84703F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 23:24:23.2570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:24:55 -0000 QWxsLA0KDQpUaGlzIGlzIHN0YXJ0IG9mIGEgdHdvLXdlZWsgcG9sbCBvbiBtYWtpbmcgdGhlIGZv bGxvd2luZyBkcmFmdCBhIA0KTkVUTU9EIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ6DQoNCiAgZHJh ZnQtbGhvdGthLW5ldG1vZC15YW5nLW1hcmt1cC0wMA0KDQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0 aGUgbGlzdCBpbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdA0Kc3VwcG9ydCIu ICBJZiBpbmRpY2F0aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciByZXNlcnZhdGlvbnMgd2l0aCB0 aGUNCmRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBj b21tZW50cyB5b3UnZCANCmxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBp cyBhIFdHIGRvY3VtZW50Lg0KDQpUaGFuayB5b3UsDQpORVRNT0QgV0cgQ2hhaXJzDQoNCg0K From nobody Fri Apr 7 16:29:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2565129457; Fri, 7 Apr 2017 16:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0Ysv5Bkf7dPU; Fri, 7 Apr 2017 16:29:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B97129459; Fri, 7 Apr 2017 16:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=845; q=dns/txt; s=iport; t=1491607743; x=1492817343; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LbGktFuMJiSZCtOaeigiE8H8DLK5eaWqkNB31NIWfZo=; b=T5iV0BhmTVzFrsufRdykzJ3KaKxH2esZzZSxoaGQo53HDWvlVVxZSyPi iIKTGBCMRmlcaU2TRnu/PP+LKwzbtqFv38tQgbDpUyjXOBmHcRFJMeduB hMZV3jFHyOzBzjdq6G/3NWpbF0NT2llgY/giy8cWJ/crEa2S+4WSDgX5y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQCPH+hY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXKnG4IPHwuFLkqDYD8YAQIBAQEBAQEBayiFFgIBAwE?= =?us-ascii?q?BbAsSAQgOXwsnBAENBYoPDqx8imsBAQEBAQEBAQEBAQEBAQEBAQEBGgWLPoQoE?= =?us-ascii?q?QGGAQWceAGSV4F+hS6KFJN+AR84fQhbFUGGW3WHC4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,168,1488844800"; d="scan'208";a="233929509" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2017 23:29:02 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v37NT2T1008323 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 7 Apr 2017 23:29:02 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Apr 2017 19:29:01 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 7 Apr 2017 19:29:01 -0400 From: "Acee Lindem (acee)" To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams Thread-Index: AQHSr/a8gELRhIh4xECuzVCCjADpgw== Date: Fri, 7 Apr 2017 23:29:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:29:23 -0000 Yes/Support Thanks, Acee P.S. Jeff Tantsura should have trademarked the =B3Yes/Support=B2 reply=8A On 4/7/17, 7:22 PM, "netmod on behalf of Kent Watsen" wrote: >All, > >This is start of a two-week poll on making the following draft a >NETMOD working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > >Please send email to the list indicating "yes/support" or "no/do not >support". If indicating no, please state your reservations with the >document. If yes, please also feel free to provide comments you'd like >to see addressed once the document is a WG document. > > >Thank you, >NETMOD WG Chairs > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 7 16:33:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBBC12943E for ; Fri, 7 Apr 2017 16:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=junipernetworks.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 mv7MLQqIy227 for ; Fri, 7 Apr 2017 16:33:19 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D926129459 for ; Fri, 7 Apr 2017 16:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gLZMN9lwvrlSCfbHJPU2vCf8x7S9fedvtv6Twdx8tI0=; b=BqWPLXPjcGa/2mrR/mVp19Cka4zqvt/6/jjlpK0m34YEBUnQfQv2kpVh3KxiijWbO3pR5Ld3dHYVjRFn15dZ2cv90fIwRc7Co9kXu+Qmeb0HQpop2/xrGVg4cehqmLY7H33v9yCkqOWlWLMjQKMT5JoJbM7eJqo4Xq23j8uR/cw= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 7 Apr 2017 23:33:02 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1034.005; Fri, 7 Apr 2017 23:33:02 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt Thread-Index: AQHSnSlHwAqIi04elk+0OsiclimezKGaqssAgAyBg4CAA4RCAIAPwKaA Date: Fri, 7 Apr 2017 23:33:02 +0000 Message-ID: <5C204D53-ECE0-4632-A34A-9BE96B913BD0@juniper.net> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.12] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:n4fn+6hqIAjXuAM2MYlIvqFVvFhT8mhHD1K3+nPseqFMiVJC73NmmNl17mYZ4CbRbAZeg+3n7uo3k+2rUTgf+EzGTQ3EqZ+qHOwk+lJZ0sxcI0VjNF2hzoexFjqrf3rppVqXJ6Gx7X98zSPJFhNNxwNz5P4BBPMXFqDvfO6ADcilZlOOCftE+mSgXocNhVmIFKNFjX7FWzcgsb4l/NPL0b+vyBiiVuuzS3kFIIbSycqn5hY+ETOt8VTr12kjifoRwq8PsyhtqXEMf6ZvnQKdOwYDfykgDJ1bsTczW+NpO5BaEYhf6azy1q2ttU5HOoWBmUjJKVTAkcIiZKu24VvQEA== x-ms-office365-filtering-correlation-id: 2a9fd2b8-51e5-43bc-60ee-08d47e0e6f1a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(95692535739014)(177428888720325)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0270ED2845 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39840400002)(39410400002)(39400400002)(39450400003)(39860400002)(24454002)(78124002)(76104003)(53824002)(377454003)(377424004)(6116002)(102836003)(3846002)(82746002)(7736002)(236005)(83506001)(6512007)(230783001)(2950100002)(66066001)(110136004)(6916009)(6246003)(33656002)(86362001)(53936002)(229853002)(189998001)(6306002)(7110500001)(54896002)(122556002)(2900100001)(93886004)(83716003)(7906003)(10710500007)(5660300001)(2351001)(4326008)(54906002)(38730400002)(53386004)(8676002)(81166006)(1730700003)(81156014)(99286003)(8936002)(2906002)(14971765001)(6506006)(3280700002)(3660700001)(53546009)(36756003)(39060400002)(50986999)(76176999)(2501003)(54356999)(2420400007)(5640700003)(6486002)(15650500001)(25786009)(606005)(6436002)(4001350100001)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5C204D53ECE04632A34A9BE96B913BD0junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2017 23:33:02.3317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:33:27 -0000 --_000_5C204D53ECE04632A34A9BE96B913BD0junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIHJlY2VpdmVkIHNvbWUgYWRkaXRpb25hbCBvZmYtbGlzdCBjb21tZW50cyByZWdhcmRpbmcg dGhlIGNvbmNlcm5zIERhdmlkDQpyYWlzZWQgYmVsb3cuICBUaGVyZSBpcyBhIHNtYWxsIGdyb3Vw IG9mIGZvbGtzIHRoYXQgYXJlIGZvcm11bGF0aW5nIGEgcmVzcG9uc2UuDQpJIHdhcyBob3Bpbmcg dG8gc2VuZCB0aGUgcmVzcG9uc2UgaXRzZWxmIHRvIHRoZSBsaXN0IGJ5IG5vdywgYnV0IGl0J3Mg bm90IHJlYWR5DQp5ZXQuICBTbywgaW5zdGVhZCwgSSdtIGp1c3Qgc2VuZGluZyB0aGlzIG1lc3Nh Z2UgdG8gbGV0IHlvdSBrbm93IHRoYXQgYSByZXNwb25zZQ0KaXMgZm9ydGhjb21pbmcuDQoNClRo YW5rcywNCktlbnQgIC8vIHNoZXBoZXJkDQoNCg0KT24gMy8yOC8xNywgMjo1OSBQTSwgIkRhdmlk IEJhbm5pc3RlciIgPGRwYkBuZXRmbGl4LmNvbTxtYWlsdG86ZHBiQG5ldGZsaXguY29tPj4gd3Jv dGU6DQoNCkkgd291bGQgYWdyZWUgdGhhdCB0aGUgbWl4IG9mIEwyIGFuZCBMMyBpbiB0aGUgc2Ft ZSBvcGVyYXRpb25hbCBBQ0wgaXMgYSBiaXQgb3V0IG9mIHRoZSBvcmRpbmFyeS4gIEkgY291bGQg c2VlIHdoZXJlIGEgY29tYmluZWQgYXBwcm9hY2ggbWF5IGJlIGFwcGVhbGluZyB0byBzb21lLiAg QXMgYSBuZXR3b3JrIG9wZXJhdG9yIEkgZG8gbm90IHNlZSB0aGlzIGFzIGEgbmVnYXRpdmUuICBJ dCB3b3VsZCBiZSBuaWNlIHRvIGdpdmUgdGhlIHZlbmRvciB0aGUgb3B0aW9uIHRvIGRlZmVyIHRo ZSBMMi8zIGNvbWJpbmF0aW9uIGJ1dCBpdCBkb2VzIG5vdCBsb29rIGF0dGFpbmFibGUgaW4gdGhl IGN1cnJlbnQgbW9kZWwuDQoNCiJhdWdtZW50ZWQgYnkgZWFjaCB2ZW5kb3IiICBUaGVyZSBhcmUg bWFueSB0aGluZ3MgbWlzc2luZyBpbiBJRVRGIG1vZGVscyBhbmQgc29tZSB0aGluZ3Mgd2hpY2gg YXJlIG5vdCB1bmRlciB0aGUgSUVURiB1bWJyZWxsYS4gIEluIHRoaXMgZGlzY3Vzc2lvbiB0aGUg Zmlyc3QgdGhhdCBjb21lcyB0byBtaW5kIGlzIGFuIDgwMi54IG1vZGVsLiAgSXQgaXMgZ29vZCB0 byBzZWUgdGhlcmUgaXMgY3VycmVudGx5IGFuIElFRUUgZWZmb3J0IHRvIGRldmVsb3Agb25lLiAg SG93ZXZlciwgaXQgZG9lcyBub3QgZXhpc3QgdG9kYXkuICBUaGUgdmFyaW91cyBldGhlciB0eXBl cyBhcmUgY292ZXJlZCBpbiBzb21lIG9mIHRoZSB2ZW5kb3IgbW9kZWxzIEkgaGF2ZSBzZWVuLiAg V2UgdGFrZSB0aGUgTmV3Y28gZXhhbXBsZSBpbiB0aGUgZHJhZnQgd2hpY2ggdHlwZWRlZnMgYW4g ZW51bSBvZiAna25vd24tZXRoZXItdHlwZS4nICBNZWFud2hpbGUgT2xkY28gaXMgdXNpbmcgYSB0 eXBlZGVmIG9mICdldGhlcnR5cGUuJyAgQm90aCBOZXcgYW5kIE9sZCBjbyBib3RoIGF1Z21lbnQg dGhpcyBkcmFmdC4gSW4gdGhpcyBzY2VuYXJpbyB0aGUgbmV0d29yayBvcGVyYXRvciBpcyBzdHVj ayBzb3J0aW5nIG91dCB0aGUgbG9naWMgaW4gd2hpY2ggdmVuZG9yIG1vZGVsIHRvIHVzZSBhbmQg aGF2aW5nIHRvIGRlYWwgd2l0aCB0d28gZGF0YSBzdHJ1Y3R1cmVzIGZvciB0aGUgc2FtZSBlbnRp dHkgKGV0aGVyLXR5cGUpLiAgIFVzaW5nIG1vZGVscyB0aGlzIHdheSBkb2VzIG5vdGhpbmcgdG8g c2ltcGxpZnkgbmV0d29yayBjb2RpbmcgYW5kIG1hbmFnZW1lbnQuICBJIGFtIGFnYWluc3QgYXVn bWVudGF0aW9uIGZyb20gdmVuZG9yIG1vZGVscyBmb3IgY29tbW9uIGl0ZW1zIGJ1dCBpdCBpcyBv ayBmb3IgdmVuZG9yIHVuaXF1ZSBpdGVtcy4gIEV0aGVyLXR5cGUgaXMgbm90IHZlbmRvciB1bmlx dWUuICBBdWdtZW50YXRpb24gaGFzIGl0cyBwbGFjZSBidXQgaXQgYXBwZWFycyB0byBiZSBvdmVy dXNlZCBldmVuIHdpdGhpbiB0aGUgY29udGV4dCBvZiBJRVRGIG9ubHkgbW9kZWxzLg0KDQpOb3Qg c3VyZSBpZiBwb2ludGluZyBvdXQgaWV0Zi1yb3V0aW5nIHdhcyBhIGdvb2QgaWRlYS4gRml2ZSB5 ZWFycyBpbiB0aGUgbWFraW5nIGFuZCA0MiBhdWdtZW50aW5nIG1vZGVscy4gOi0pDQoNCklmIHdl IGNhbiBnZXQgdGhlIHdlbGwga25vd24gSUVURiBzdGFuZGFyZGl6ZWQgbWlzc2luZyBiaXRzIGZy b20gTDMsIEw0IGZvciB2NCBhbmQgdjYgaW50byB0aGlzIGl0IHdvdWxkIHdvcmsgZm9yIG1lIGJ1 dCBJIHRoaW5rIHRoZSBJRVRGIG1heSBoYXZlIG1pc3NlZCB0aGUgYm9hdCBvbiB0aGlzIG9uZS4N Cg0KDQoNCg0KT24gU3VuLCBNYXIgMjYsIDIwMTcgYXQgMToxNyBQTSwgS2VudCBXYXRzZW4gPGt3 YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiB3cm90ZToNCkhJ IERhdmlkLA0KDQpJIGJlbGlldmUgYW4gYW5hbG9neSB0byB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVs ZSBjYW4gYW5kIHNob3VsZCBiZSBtYWRlIGhlcmUuICBJbiBib3RoIGNhc2VzLCB0aGUgbW9kdWxl IHByb3ZpZGVzIGEgbWluaW1hbCBza2VsZXRvbiB0aGF0IGlzIGludGVuZGVkIHRvIGJlIGV4dGVu ZGVkIGJ5IGF1Z21lbnRhdGlvbnMuICAgSWYgYW55dGhpbmcsIEkgY291bGQgYXJndWUgdGhhdCB0 aGUgYWNsIG1vZHVsZSBkb2Vzbid0IGdvIGZhciBlbm91Z2gsIGluIHRoYXQgdGhlcmUgaXMgbm8g ZmVhdHVyZSBzdGF0ZW1lbnQgb24gdGhlICJhY2UtaXAiIGFuZCAiYWNlLWV0aCIgY2FzZSBzdGF0 ZW1lbnRzLCBhcyBpZiBpdCdzIGFzc3VtaW5nIHRoYXQgYWxsIHNlcnZlcnMgaW1wbGVtZW50IEwz IGFuZCBMMiBBQ0xzLCB3aGljaCBJIGZpbmQgc3VzcGljaW91cy4uLg0KDQpZb3Ugd3JpdGUgYmVs b3cgImF1Z21lbnRlZCBieSBlYWNoIHZlbmRvciIsIGJ1dCBJIGRvbid0IGJlbGlldmUgdGhhdCB0 aGlzIGlzIHRoZSBpbnRlbnQsIHNvIG11Y2ggYXMgKGp1c3QgbGlrZSB3aXRoIHRoZSBpZXRmLXJv dXRpbmcpIHRoYXQgZnV0dXJlIElFVEYgbW9kdWxlcyB3aWxsIGJlIGRlZmluZWQgdG8gZmxlc2gg aXQgb3V0LiAgSW4gcGFydGljdWxhciwgdGhlIGV4aXN0aW5nICJhY2UtaXAiIGFuZCAiYWNlLWV0 aCIgY2FzZSBzdGF0ZW1lbnRzIGNhbiBiZSBhdWdtZW50ZWQsIGFzIHdlbGwgYXMgYnJhbmQgbmV3 IGNhc2Ugc3RhdGVtZW50cyBhZGRlZC4gICBJIGFncmVlIHRoYXQsIGluIGl0cyBjdXJyZW50IGZv cm0sIHRoaXMgZHJhZnQgaXMgb2YgbGltaXRlZCB1c2UsIGJ1dCBrZWVwIGluIG15IHRoYXQgdGhl IGlldGYtcm91dGluZyBtb2R1bGUgbm93IGhhcyA0MiBvdGhlciBtb2R1bGVzIGF1Z21lbnRpbmcg aXQsIHNvIHRoZXJlJ3MgaG9wZSB0aGF0IHRoZSBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3QgbW9k dWxlIHdpbGwgc2ltaWxhcmx5IGJlIGZsZXNoZWQgb3V0IGluIHNob3J0IG9yZGVyLg0KDQpXaGF0 IGRvIHlvdSB0aGluaz8gIERvIHlvdSB0aGluayB3ZSBzaG91bGQgcHV0IGZlYXR1cmUgc3RhdGVt ZW50cyBvbiB0aGUgdHdvIGNhc2Ugc3RhdGVtZW50cywgb3IgZXZlbiBtb3ZlIHRoZXNlIGludG8g b3RoZXIgbW9kdWxlcyAoaW4gdGhlIHNhbWUgZHJhZnQpIHNvIHRoYXQgdGhlcmUgaXMgbm8gc3Bl Y2lhbG5lc3MgaW1wYXJ0ZWQgb24gdGhlbT8NCg0KV2hhdCBhYm91dCBvdGhlcnM/ICBJJ20gY29u Y2VybmVkIHRoYXQgd2UgbWF5IG5vdCBoYXZlIHN1ZmZpY2llbnQgZG9tYWluIGV4cGVydGlzZSBp biB0aGUgTkVUTU9EIFdHIC0gc2ltaWxhciB0byB0aGUgcm91dGluZy1jZmcgZHJhZnQsIHVudGls IHRoZSBydGd3ZyBzdGFydGVkIHRvIGZvY3VzIG9uIGl0Lg0KDQpLZW50ICAvLyBzaGVwaGVyZA0K DQoNCk9uIDMvMTgvMTcsIDk6MTggQU0sICJEYXZpZCBCYW5uaXN0ZXIiIDxkcGJAbmV0ZmxpeC5j b208bWFpbHRvOmRwYkBuZXRmbGl4LmNvbT4+IHdyb3RlOg0KDQooc2Vjb25kIHRyeSkNClRoZXJl IHdlcmUgbm8gY2hhbmdlcyB0byB0aGUgbW9kZWwgc28gbXkgY29uY2VybnMgcmVtYWluIHRoZSBz YW1lLiAgQXVnbWVudGF0aW9uIGlzIG5vdCBhIHNjYWxhYmxlIHNvbHV0aW9uIHdoZW4gZGVhbGlu ZyB3aXRoIGEgbXV0bGktdmVuZG9yIG9yIGluIHNvbWUgaW5zdGFuY2VzIGEgbXVsdGktYnVzaW5l c3MtdW5pdCBlbnZpcm9ubWVudC4gIFRoZSAnbmV3Y28nIGV4YW1wbGUgaW4gdGhlIGRyYWZ0IGls bHVzdHJhdGVzIHRoaXMgcHJvYmxlbS4gIFRoZSBJRVRGIHByb2R1Y2VzIGEgJ3N0YW5kYXJkJyBm b3IgYW4gQUNMIGRyYWZ0IHdoaWNoIGlzIHNvIHNwYXJzZSBpbiBuYXR1cmUgdGhhdCBpdCBtdXN0 IGJlIGF1Z21lbnRlZCBieSBlYWNoIHZlbmRvci4gIEluIHRoZSBiZXN0IGNhc2UgdGhpcyBnaXZl cyBtZSBhIHVuaXF1ZSBtb2RlbCBwZXIgdmVuZG9yIGJlY2F1c2Ugd2Uga25vdyB0aGUgdmVuZG9y cyBhcmUgbm90IGdvaW5nIHRvIGdldCB0b2dldGhlciB0byBkZWZpbmUgdGhlIG1pc3NpbmcgcGll Y2VzLiAgVGhlIHZlbmRvcnMgd2lsbCB1c2UgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8gY29t cGxldGUgdGhlIG1vZGVsIGZyb20gdXNpbmcgYSBzY3JpcHQgdG8gYnVpbGQgdGhlaXIgbW9kZWxz IGZyb20gc291cmNlIGNvZGUsIGhhbmRsaW5nIHRoZSBtaXNzaW5nIHBpZWNlcyBhcyBhcmJpdHJh cnkgY29kZSAoYW55eG1sKSwgb3IgZXZlcnl0aGluZyBhcyBhIHN0cmluZy4gIFRoZW4gdGhlcmUg aXMgdGhlIHdvcnNlIGNhc2Ugd2hlcmUgYSB2ZW5kb3IgaGFzIG5vIGludGVybmFsIHN0YW5kYXJk aXphdGlvbiAoeW91IGtub3cgd2hvIHlvdSBhcmUpIGFuZCB0aGVpciBvd24gcHJvZHVjdCBsaW5l cyB3aWxsIG5vdCBhbGlnbiBpbnRvIGEgY29tbW9uIG1vZGVsLiAgVGhlIG9iamVjdCBoZXJlLCBm b3IgbWUsIGlzIHRvIGdldCB0byBhIHNpbmdsZSBtb2RlbCBmb3IgYWxsIHZlbmRvcnMgYmFycmlu ZyBhIHVuaXF1ZSBmZWF0dXJlIHRoYXQgYmVsb25ncyB0byBvbmUgdmVuZG9yIGluIHdoaWNoIGNh c2UgYXVnbWVudGF0aW9uIGlzIGFjY2VwdGFibGUuDQoNCkNvdWxkIHlvdSBhZGQgdG8gdGhpcyBp biB0aGUgZnV0dXJlIGFuZCByZXYgdXAgdGhlIFJGQz8gIFN1cmUuICBIb3dldmVyLCBJIGFtIG5v dCBzdXJlIHdoYXQgdmFsdWUgdGhhdCBicmluZ3MgdG8gdGhlIGNvbW11bml0eS4gIEluIGl0cyBj dXJyZW50IGZvcm0gSSB3b3VsZCBub3QgYXNrIGFueSBvZiBteSB2ZW5kb3JzIHRvIGltcGxlbWVu dCB0aGlzIGRyYWZ0LiAgSW5zdGVhZCBJIHdvdWxkIHB1c2ggdGhlbSB0b3dhcmRzIHRoZSBPcGVu Q29uZmlnIEFDTCBtb2RlbC4NCg0KT24gVHVlLCBNYXIgMTQsIDIwMTcgYXQgOToxMiBQTSwgS2Vu dCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+ PiB3cm90ZToNCkhpIERhdmlkLA0KDQpDYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgdGhlIGFk ZGl0aW9uYWwgZXhhbXBsZXMgYWRkcmVzcyB5b3VyIGNvbmNlcm4/ICBBbmQsIGlmIG5vdCwgcGxl YXNlDQpleHBsYWluIGlmIHRoZXJlIGlzIGFueSByZWFzb24gd2h5IHdoYXQgeW91J3JlIGxvb2tp bmcgZm9yIGNvdWxkbid0IGJlIGFkZGVkIG9yIGF1Z21lbnRlZCBpbg0KaW4gdGhlIGZ1dHVyZS4N Cg0KVGhhbmtzLA0KS2VudCAvLyBzaGVwaGVyZA0KDQpPbiAzLzEzLzE3LCA1OjU3IEFNLCAibmV0 bW9kIG9uIGJlaGFsZiBvZiBEZWFuIEJvZ2Rhbm92aWMiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBpdmFuZGVhbkBn bWFpbC5jb208bWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZXJlIGlzIHRo ZSBuZXcgdmVyc2lvbiBvZiB0aGUgQUNMIGRyYWZ0LiBTaW5jZSBEZWNlbWJlciBhbmQgc29tZSBh ZGRpdGlvbmFsIGNvbW1lbnRzIGFib3V0IHRoZSBBQ0wgbW9kZWwsIEkgc3Bva2Ugd2l0aCBtYW55 IG9wZXJhdG9ycyBhbmQgaG93IHRoZXkgdXNlIEFDTHMuIEkgaGF2ZSBhbHNvIHJlY2VpdmVkIGxv dCBvZiBkZXRhaWxlZCBBQ0wgY29uZmlndXJhdGlvbnMuIEluIG1vc3QgY2FzZXMsIHRoZSBtb2Rl bCBpcyBlYXNpbHkgYWRhcHRlZCB0byB0aGUgY3VycmVudCB1c2UgY2FzZXMgaW4gb3BlcmF0aW9u cy4gQnV0IHRvIGFuc3dlciB0aGUgY29tbWVudHMsIHRoZSBhdXRob3JzIGhhdmUgYWRkZWQgYSBk ZXRhaWxlZCBleGFtcGxlIGluIHRoZSBhZGRlbmR1bSBzZWN0aW9uIGhvdyB0aGUgbW9kZWwgY2Fu IGJlIGV4dGVuZGVkIGFuZCBob3cgdGhpcyBtb2RlbCBjYW4gYmUgdXNlZC4NCg0KQ2hlZXJzLA0K DQpEZWFuDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwt MTAudHh0DQpEYXRlOiBNYXJjaCAxMywgMjAxNyBhdCAxMDo1MjozOCBBTSBHTVQrMQ0KVG86IDxu ZXRtb2QtY2hhaXJzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtY2hhaXJzQGlldGYub3JnPj4sICJL aXJhbiBLb3VzaGlrIiA8a2tvdXNoaWtAY2lzY28uY29tPG1haWx0bzpra291c2hpa0BjaXNjby5j b20+PiwgIkxpc2EgSHVhbmciIDxseWlodWFuZzE2QGdtYWlsLmNvbTxtYWlsdG86bHlpaHVhbmcx NkBnbWFpbC5jb20+PiwgIkRlYW4gQm9nZGFub3ZpYyIgPGl2YW5kZWFuQGdtYWlsLmNvbTxtYWls dG86aXZhbmRlYW5AZ21haWwuY29tPj4sICJEYW5hIEJsYWlyIiA8ZGJsYWlyQGNpc2NvLmNvbTxt YWlsdG86ZGJsYWlyQGNpc2NvLmNvbT4+LCAiS2lyYW4gQWdyYWhhcmEgU3JlZW5pdmFzYSIgPGtr b3VzaGlrQGNpc2NvLmNvbTxtYWlsdG86a2tvdXNoaWtAY2lzY28uY29tPj4NCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEZWFuIEJvZ2Rhbm92aWMgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1v ZGVsDQpSZXZpc2lvbjogMTANClRpdGxlOiBOZXR3b3JrIEFjY2VzcyBDb250cm9sIExpc3QgKEFD TCkgWUFORyBEYXRhIE1vZGVsDQpEb2N1bWVudCBkYXRlOiAyMDE3LTAzLTEzDQpHcm91cDogbmV0 bW9kDQpQYWdlczogMzINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9k LWFjbC1tb2RlbC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0xMA0K DQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIEFj Y2VzcyBDb250cm9sIExpc3QgKEFDTCkNCiAgYmFzaWMgYnVpbGRpbmcgYmxvY2tzLg0KDQogIEVk aXRvcmlhbCBOb3RlIChUbyBiZSByZW1vdmVkIGJ5IFJGQyBFZGl0b3IpDQoNCiAgVGhpcyBkcmFm dCBjb250YWlucyBtYW55IHBsYWNlaG9sZGVyIHZhbHVlcyB0aGF0IG5lZWQgdG8gYmUgcmVwbGFj ZWQNCiAgd2l0aCBmaW5hbGl6ZWQgdmFsdWVzIGF0IHRoZSB0aW1lIG9mIHB1YmxpY2F0aW9uLiAg VGhpcyBub3RlDQogIHN1bW1hcml6ZXMgYWxsIG9mIHRoZSBzdWJzdGl0dXRpb25zIHRoYXQgYXJl IG5lZWRlZC4gIFBsZWFzZSBub3RlDQogIHRoYXQgbm8gb3RoZXIgUkZDIEVkaXRvciBpbnN0cnVj dGlvbnMgYXJlIHNwZWNpZmllZCBhbnl3aGVyZSBlbHNlIGluDQogIHRoaXMgZG9jdW1lbnQuDQoN CiAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHNob3J0aGFuZCByZWZlcmVuY2Vz IHRvIGRyYWZ0cyBpbg0KICBwcm9ncmVzcy4gIFBsZWFzZSBhcHBseSB0aGUgZm9sbG93aW5nIHJl cGxhY2VtZW50cw0KDQogIG8gICJYWFhYIiAtLT4gdGhlIGFzc2lnbmVkIFJGQyB2YWx1ZSBmb3Ig dGhpcyBkcmFmdC4NCg0KICBvICBSZXZpc2lvbiBkYXRlIGluIG1vZGVsIChPY3QgMTIsIDIwMTYp IG5lZWRzIHRvIGdldCB1cGRhdGVkIHdpdGgNCiAgICAgdGhlIGRhdGUgdGhlIGRyYWZ0IGdldHMg YXBwcm92ZWQuICBUaGUgZGF0ZSBhbHNvIG5lZWRzIHRvIGdldA0KICAgICByZWZsZWN0ZWQgb24g dGhlIGxpbmUgd2l0aCA8Q09ERSBCRUdJTlM+Lg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg0KDQo= --_000_5C204D53ECE04632A34A9BE96B913BD0junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <4F8EEA534FC09D4F8FFCA7F9E76FB451@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm00NDM3MDk2NzA3Mzk3NzM5NDhtLTU5MjMxNTUx NjAyMzY5OTM2NTZhcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTptXzQ0MzcwOTY3MDcz OTc3Mzk0OG0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPkkgcmVjZWl2ZWQgc29tZSBhZGRpdGlvbmFsIG9mZi1saXN0IGNvbW1lbnRzIHJlZ2Fy ZGluZyB0aGUgY29uY2VybnMgRGF2aWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+cmFpc2VkIGJlbG93 LiZuYnNwOyBUaGVyZSBpcyBhIHNtYWxsIGdyb3VwIG9mIGZvbGtzIHRoYXQgYXJlIGZvcm11bGF0 aW5nIGEgcmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkkgd2FzIGhvcGluZyB0byBzZW5k IHRoZSByZXNwb25zZSBpdHNlbGYgdG8gdGhlIGxpc3QgYnkgbm93LCBidXQgaXQncyBub3QgcmVh ZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+eWV0LiZuYnNwOyBTbywgaW5zdGVhZCwgSSdtIGp1c3Qg c2VuZGluZyB0aGlzIG1lc3NhZ2UgdG8gbGV0IHlvdSBrbm93IHRoYXQgYSByZXNwb25zZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5pcyBmb3J0aGNvbWluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+S2Vu dCAmbmJzcDsvLyBzaGVwaGVyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzLzI4LzE3LCAyOjU5IFBNLCAmcXVvdDtEYXZpZCBCYW5u aXN0ZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcGJAbmV0ZmxpeC5jb20iPmRwYkBuZXRm bGl4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgYWdyZWUgdGhhdCB0aGUgbWl4IG9m IEwyIGFuZCBMMyBpbiB0aGUgc2FtZSBvcGVyYXRpb25hbCBBQ0wgaXMgYSBiaXQgb3V0IG9mIHRo ZSBvcmRpbmFyeS4mbmJzcDsgSSBjb3VsZCBzZWUgd2hlcmUgYSBjb21iaW5lZCBhcHByb2FjaCBt YXkgYmUgYXBwZWFsaW5nIHRvIHNvbWUuJm5ic3A7IEFzIGEgbmV0d29yayBvcGVyYXRvciBJIGRv IG5vdCBzZWUgdGhpcyBhcyBhIG5lZ2F0aXZlLiZuYnNwOyBJdCB3b3VsZCBiZSBuaWNlDQogdG8g Z2l2ZSB0aGUgdmVuZG9yIHRoZSBvcHRpb24gdG8gZGVmZXIgdGhlIEwyLzMgY29tYmluYXRpb24g YnV0IGl0IGRvZXMgbm90IGxvb2sgYXR0YWluYWJsZSBpbiB0aGUgY3VycmVudCBtb2RlbC4NCjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7YXVnbWVu dGVkIGJ5IGVhY2ggdmVuZG9yJnF1b3Q7ICZuYnNwO1RoZXJlIGFyZSBtYW55IHRoaW5ncyBtaXNz aW5nIGluIElFVEYgbW9kZWxzIGFuZCBzb21lIHRoaW5ncyB3aGljaCBhcmUgbm90IHVuZGVyIHRo ZSBJRVRGIHVtYnJlbGxhLiZuYnNwOyBJbiB0aGlzIGRpc2N1c3Npb24gdGhlIGZpcnN0IHRoYXQg Y29tZXMgdG8gbWluZCBpcyBhbiA4MDIueCBtb2RlbC4mbmJzcDsgSXQgaXMgZ29vZCB0byBzZWUg dGhlcmUgaXMgY3VycmVudGx5IGFuDQogSUVFRSBlZmZvcnQgdG8gZGV2ZWxvcCBvbmUuJm5ic3A7 IEhvd2V2ZXIsIGl0IGRvZXMgbm90IGV4aXN0IHRvZGF5LiZuYnNwOyBUaGUgdmFyaW91cyBldGhl ciB0eXBlcyBhcmUgY292ZXJlZCBpbiBzb21lIG9mIHRoZSB2ZW5kb3IgbW9kZWxzIEkgaGF2ZSBz ZWVuLiZuYnNwOyBXZSB0YWtlIHRoZSBOZXdjbyBleGFtcGxlIGluIHRoZSBkcmFmdCB3aGljaCB0 eXBlZGVmcyBhbiBlbnVtIG9mICdrbm93bi1ldGhlci10eXBlLicgJm5ic3A7TWVhbndoaWxlIE9s ZGNvIGlzIHVzaW5nIGENCiB0eXBlZGVmIG9mICdldGhlcnR5cGUuJyAmbmJzcDtCb3RoIE5ldyBh bmQgT2xkIGNvIGJvdGggYXVnbWVudCB0aGlzIGRyYWZ0LiBJbiB0aGlzIHNjZW5hcmlvIHRoZSBu ZXR3b3JrIG9wZXJhdG9yIGlzIHN0dWNrIHNvcnRpbmcgb3V0IHRoZSBsb2dpYyBpbiB3aGljaCB2 ZW5kb3IgbW9kZWwgdG8gdXNlIGFuZCBoYXZpbmcgdG8gZGVhbCB3aXRoIHR3byBkYXRhIHN0cnVj dHVyZXMgZm9yIHRoZSBzYW1lIGVudGl0eSAoZXRoZXItdHlwZSkuICZuYnNwOyBVc2luZyBtb2Rl bHMNCiB0aGlzIHdheSBkb2VzIG5vdGhpbmcgdG8gc2ltcGxpZnkgbmV0d29yayBjb2RpbmcgYW5k IG1hbmFnZW1lbnQuJm5ic3A7IEkgYW0gYWdhaW5zdCBhdWdtZW50YXRpb24gZnJvbSB2ZW5kb3Ig bW9kZWxzIGZvciBjb21tb24gaXRlbXMgYnV0IGl0IGlzIG9rIGZvciB2ZW5kb3IgdW5pcXVlIGl0 ZW1zLiZuYnNwOyBFdGhlci10eXBlIGlzIG5vdCB2ZW5kb3IgdW5pcXVlLiZuYnNwOyBBdWdtZW50 YXRpb24gaGFzIGl0cyBwbGFjZSBidXQgaXQgYXBwZWFycyB0byBiZSBvdmVydXNlZA0KIGV2ZW4g d2l0aGluIHRoZSBjb250ZXh0IG9mIElFVEYgb25seSBtb2RlbHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJlIGlmIHBvaW50aW5n IG91dCBpZXRmLXJvdXRpbmcgd2FzIGEgZ29vZCBpZGVhLiBGaXZlIHllYXJzIGluIHRoZSBtYWtp bmcgYW5kIDQyIGF1Z21lbnRpbmcgbW9kZWxzLiA6LSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgY2FuIGdldCB0aGUgd2VsbCBrbm93 biBJRVRGIHN0YW5kYXJkaXplZCBtaXNzaW5nIGJpdHMgZnJvbSBMMywgTDQgZm9yIHY0IGFuZCB2 NiBpbnRvIHRoaXMgaXQgd291bGQgd29yayBmb3IgbWUgYnV0IEkgdGhpbmsgdGhlIElFVEYgbWF5 IGhhdmUgbWlzc2VkIHRoZSBib2F0IG9uIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE1hciAyNiwgMjAx NyBhdCAxOjE3IFBNLCBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVu aXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5ISSBEYXZpZCw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5JIGJl bGlldmUgYW4gYW5hbG9neSB0byB0aGUgaWV0Zi1yb3V0aW5nIG1vZHVsZSBjYW4gYW5kIHNob3Vs ZCBiZSBtYWRlIGhlcmUuJm5ic3A7IEluIGJvdGggY2FzZXMsIHRoZSBtb2R1bGUgcHJvdmlkZXMg YSBtaW5pbWFsIHNrZWxldG9uIHRoYXQgaXMgaW50ZW5kZWQNCiB0byBiZSBleHRlbmRlZCBieSBh dWdtZW50YXRpb25zLiZuYnNwOyAmbmJzcDtJZiBhbnl0aGluZywgSSBjb3VsZCBhcmd1ZSB0aGF0 IHRoZSBhY2wgbW9kdWxlIGRvZXNuJ3QgZ28gZmFyIGVub3VnaCwgaW4gdGhhdCB0aGVyZSBpcyBu byBmZWF0dXJlIHN0YXRlbWVudCBvbiB0aGUgJnF1b3Q7YWNlLWlwJnF1b3Q7IGFuZCAmcXVvdDth Y2UtZXRoJnF1b3Q7IGNhc2Ugc3RhdGVtZW50cywgYXMgaWYgaXQncyBhc3N1bWluZyB0aGF0IGFs bCBzZXJ2ZXJzIGltcGxlbWVudCBMMyBhbmQgTDIgQUNMcywgd2hpY2gNCiBJIGZpbmQgc3VzcGlj aW91cy4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmkiPllvdSB3cml0ZSBiZWxvdyAmcXVvdDthdWdtZW50ZWQgYnkgZWFjaCB2ZW5kb3ImcXVvdDss IGJ1dCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIGlzIHRoZSBpbnRlbnQsIHNvIG11Y2ggYXMg KGp1c3QgbGlrZSB3aXRoIHRoZSBpZXRmLXJvdXRpbmcpIHRoYXQgZnV0dXJlDQogSUVURiBtb2R1 bGVzIHdpbGwgYmUgZGVmaW5lZCB0byBmbGVzaCBpdCBvdXQuJm5ic3A7IEluIHBhcnRpY3VsYXIs IHRoZSBleGlzdGluZyAmcXVvdDthY2UtaXAmcXVvdDsgYW5kICZxdW90O2FjZS1ldGgmcXVvdDsg Y2FzZSBzdGF0ZW1lbnRzIGNhbiBiZSBhdWdtZW50ZWQsIGFzIHdlbGwgYXMgYnJhbmQgbmV3IGNh c2Ugc3RhdGVtZW50cyBhZGRlZC4mbmJzcDsmbmJzcDsgSSBhZ3JlZSB0aGF0LCBpbiBpdHMgY3Vy cmVudCBmb3JtLCB0aGlzIGRyYWZ0IGlzIG9mIGxpbWl0ZWQgdXNlLCBidXQga2VlcCBpbiBteQ0K IHRoYXQgdGhlIGlldGYtcm91dGluZyBtb2R1bGUgbm93IGhhcyA0MiBvdGhlciBtb2R1bGVzIGF1 Z21lbnRpbmcgaXQsIHNvIHRoZXJlJ3MgaG9wZSB0aGF0IHRoZSBpZXRmLWFjY2Vzcy1jb250cm9s LWxpc3QgbW9kdWxlIHdpbGwgc2ltaWxhcmx5IGJlIGZsZXNoZWQgb3V0IGluIHNob3J0IG9yZGVy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPldo YXQgZG8geW91IHRoaW5rPyZuYnNwOyBEbyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHB1dCBmZWF0dXJl IHN0YXRlbWVudHMgb24gdGhlIHR3byBjYXNlIHN0YXRlbWVudHMsIG9yIGV2ZW4gbW92ZSB0aGVz ZSBpbnRvIG90aGVyIG1vZHVsZXMgKGluIHRoZSBzYW1lDQogZHJhZnQpIHNvIHRoYXQgdGhlcmUg aXMgbm8gc3BlY2lhbG5lc3MgaW1wYXJ0ZWQgb24gdGhlbT88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5XaGF0IGFib3V0IG90aGVycz8mbmJzcDsg SSdtIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBub3QgaGF2ZSBzdWZmaWNpZW50IGRvbWFpbiBleHBl cnRpc2UgaW4gdGhlIE5FVE1PRCBXRyAtIHNpbWlsYXIgdG8gdGhlIHJvdXRpbmctY2ZnIGRyYWZ0 LCB1bnRpbCB0aGUNCiBydGd3ZyBzdGFydGVkIHRvIGZvY3VzIG9uIGl0Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQmbmJzcDsgLy8gc2hl cGhlcmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAzLzE4LzE3LCA5OjE4IEFNLCAmcXVvdDtEYXZp ZCBCYW5uaXN0ZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcGJAbmV0ZmxpeC5jb20iIHRh cmdldD0iX2JsYW5rIj5kcGJAbmV0ZmxpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPihzZWNvbmQgdHJ5KTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij5UaGVyZSB3ZXJlIG5vIGNoYW5nZXMgdG8gdGhlIG1vZGVsIHNvIG15 IGNvbmNlcm5zIHJlbWFpbiB0aGUgc2FtZS4mbmJzcDsgQXVnbWVudGF0aW9uIGlzIG5vdCBhIHNj YWxhYmxlIHNvbHV0aW9uIHdoZW4gZGVhbGluZyB3aXRoIGEgbXV0bGktdmVuZG9yIG9yIGluDQog c29tZSBpbnN0YW5jZXMgYSBtdWx0aS1idXNpbmVzcy11bml0IGVudmlyb25tZW50LiZuYnNwOyBU aGUgJ25ld2NvJyBleGFtcGxlIGluIHRoZSBkcmFmdCBpbGx1c3RyYXRlcyB0aGlzIHByb2JsZW0u Jm5ic3A7IFRoZSBJRVRGIHByb2R1Y2VzIGEgJ3N0YW5kYXJkJyBmb3IgYW4gQUNMIGRyYWZ0IHdo aWNoIGlzIHNvIHNwYXJzZSBpbiBuYXR1cmUgdGhhdCBpdCBtdXN0IGJlIGF1Z21lbnRlZCBieSBl YWNoIHZlbmRvci4mbmJzcDsgSW4gdGhlIGJlc3QgY2FzZSB0aGlzIGdpdmVzDQogbWUgYSB1bmlx dWUgbW9kZWwgcGVyIHZlbmRvciBiZWNhdXNlIHdlIGtub3cgdGhlIHZlbmRvcnMgYXJlIG5vdCBn b2luZyB0byBnZXQgdG9nZXRoZXIgdG8gZGVmaW5lIHRoZSBtaXNzaW5nIHBpZWNlcy4mbmJzcDsg VGhlIHZlbmRvcnMgd2lsbCB1c2UgYSB2YXJpZXR5IG9mIG1lY2hhbmlzbXMgdG8gY29tcGxldGUg dGhlIG1vZGVsIGZyb20gdXNpbmcgYSBzY3JpcHQgdG8gYnVpbGQgdGhlaXIgbW9kZWxzIGZyb20g c291cmNlIGNvZGUsIGhhbmRsaW5nIHRoZQ0KIG1pc3NpbmcgcGllY2VzIGFzIGFyYml0cmFyeSBj b2RlIChhbnl4bWwpLCBvciBldmVyeXRoaW5nIGFzIGEgc3RyaW5nLiZuYnNwOyBUaGVuIHRoZXJl IGlzIHRoZSB3b3JzZSBjYXNlIHdoZXJlIGEgdmVuZG9yIGhhcyBubyBpbnRlcm5hbCBzdGFuZGFy ZGl6YXRpb24gKHlvdSBrbm93IHdobyB5b3UgYXJlKSBhbmQgdGhlaXIgb3duIHByb2R1Y3QgbGlu ZXMgd2lsbCBub3QgYWxpZ24gaW50byBhIGNvbW1vbiBtb2RlbC4mbmJzcDsgVGhlIG9iamVjdCBo ZXJlLCBmb3INCiBtZSwgaXMgdG8gZ2V0IHRvIGEgc2luZ2xlIG1vZGVsIGZvciBhbGwgdmVuZG9y cyBiYXJyaW5nIGEgdW5pcXVlIGZlYXR1cmUgdGhhdCBiZWxvbmdzIHRvIG9uZSB2ZW5kb3IgaW4g d2hpY2ggY2FzZSBhdWdtZW50YXRpb24gaXMgYWNjZXB0YWJsZS4gJm5ic3A7PC9zcGFuPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQi PkNvdWxkIHlvdSBhZGQgdG8gdGhpcyBpbiB0aGUgZnV0dXJlIGFuZCByZXYgdXAgdGhlIFJGQz8m bmJzcDsgU3VyZS4mbmJzcDsgSG93ZXZlciwgSSBhbSBub3Qgc3VyZSB3aGF0IHZhbHVlIHRoYXQg YnJpbmdzIHRvIHRoZSBjb21tdW5pdHkuJm5ic3A7IEluIGl0cyBjdXJyZW50IGZvcm0NCiBJIHdv dWxkIG5vdCBhc2sgYW55IG9mIG15IHZlbmRvcnMgdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQuJm5i c3A7IEluc3RlYWQgSSB3b3VsZCBwdXNoIHRoZW0gdG93YXJkcyB0aGUgT3BlbkNvbmZpZyBBQ0wg bW9kZWwuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgTWFyIDE0LCAyMDE3IGF0IDk6MTIgUE0sIEtl bnQgV2F0c2VuICZsdDs8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCIgdGFyZ2V0 PSJfYmxhbmsiPmt3YXRzZW5AanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj5IaSBEYXZpZCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5DYW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgdGhlIGFkZGl0aW9u YWwgZXhhbXBsZXMgYWRkcmVzcyB5b3VyIGNvbmNlcm4/Jm5ic3A7IEFuZCwgaWYgbm90LCBwbGVh c2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5leHBsYWluIGlmIHRoZXJlIGlzIGFueSByZWFzb24g d2h5IHdoYXQgeW91J3JlIGxvb2tpbmcgZm9yIGNvdWxkbid0IGJlIGFkZGVkIG9yIGF1Z21lbnRl ZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPmluIHRoZSBmdXR1cmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPktlbnQgLy8gc2hlcGhlcmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5PbiAzLzEzLzE3LCA1OjU3IEFNLCAmcXVvdDtuZXRtb2Qgb24g YmVoYWxmIG9mIERlYW4gQm9nZGFub3ZpYyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1v ZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOml2YW5kZWFuQGdtYWlsLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlcmUg aXMgdGhlIG5ldyB2ZXJzaW9uIG9mIHRoZSBBQ0wgZHJhZnQuIFNpbmNlIERlY2VtYmVyIGFuZCBz b21lIGFkZGl0aW9uYWwgY29tbWVudHMgYWJvdXQgdGhlIEFDTCBtb2RlbCwgSSBzcG9rZSB3aXRo IG1hbnkgb3BlcmF0b3JzIGFuZCBob3cgdGhleSB1c2UgQUNMcy4gSSBoYXZlIGFsc28gcmVjZWl2 ZWQNCiBsb3Qgb2YgZGV0YWlsZWQgQUNMIGNvbmZpZ3VyYXRpb25zLiBJbiBtb3N0IGNhc2VzLCB0 aGUgbW9kZWwgaXMgZWFzaWx5IGFkYXB0ZWQgdG8gdGhlIGN1cnJlbnQgdXNlIGNhc2VzIGluIG9w ZXJhdGlvbnMuIEJ1dCB0byBhbnN3ZXIgdGhlIGNvbW1lbnRzLCB0aGUgYXV0aG9ycyBoYXZlIGFk ZGVkIGEgZGV0YWlsZWQgZXhhbXBsZSBpbiB0aGUgYWRkZW5kdW0gc2VjdGlvbiBob3cgdGhlIG1v ZGVsIGNhbiBiZSBleHRlbmRlZCBhbmQgaG93IHRoaXMNCiBtb2RlbCBjYW4gYmUgdXNlZC4gPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hlZXJzLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ RGVhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+ RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5TdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0x MC50eHQ8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDsiPkRhdGU6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+TWFyY2ggMTMsIDIwMTcgYXQgMTA6NTI6MzggQU0g R01UJiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh IE5ldWUmcXVvdDsiPlRvOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWly c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0 OywgJnF1b3Q7S2lyYW4gS291c2hpayZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtrb3VzaGlr QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtrb3VzaGlrQGNpc2NvLmNvbTwvYT4mZ3Q7LCAm cXVvdDtMaXNhIEh1YW5nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bHlpaHVhbmcxNkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5seWlodWFuZzE2QGdtYWlsLmNvbTwvYT4mZ3Q7LA0KICZx dW90O0RlYW4gQm9nZGFub3ZpYyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOml2YW5kZWFuQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPml2YW5kZWFuQGdtYWlsLmNvbTwvYT4mZ3Q7LCAmcXVv dDtEYW5hIEJsYWlyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGJsYWlyQGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRibGFpckBjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7S2lyYW4gQWdy YWhhcmEgU3JlZW5pdmFzYSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtrb3VzaGlrQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmtrb3VzaGlrQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0PGJyPg0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEZWFuIEJvZ2Rhbm92aWMgYW5kIHBvc3Rl ZCB0byB0aGU8YnI+DQpJRVRGIHJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTo8c3BhbiBjbGFz cz0ibTQ0MzcwOTY3MDczOTc3Mzk0OG0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRhYi1zcGFu Ij4gPC9zcGFuPg0KZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsPGJyPg0KUmV2aXNpb246PHNw YW4gY2xhc3M9Im00NDM3MDk2NzA3Mzk3NzM5NDhtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10 YWItc3BhbiI+IDwvc3Bhbj4NCjEwPGJyPg0KVGl0bGU6PHNwYW4gY2xhc3M9Im00NDM3MDk2NzA3 Mzk3NzM5NDhtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4NCk5l dHdvcmsgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKSBZQU5HIERhdGEgTW9kZWw8YnI+DQpEb2N1 bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJtNDQzNzA5NjcwNzM5NzczOTQ4bS01OTIzMTU1MTYwMjM2 OTkzNjU2YXBwbGUtdGFiLXNwYW4iPg0KPC9zcGFuPjIwMTctMDMtMTM8YnI+DQpHcm91cDo8c3Bh biBjbGFzcz0ibTQ0MzcwOTY3MDczOTc3Mzk0OG0tNTkyMzE1NTE2MDIzNjk5MzY1NmFwcGxlLXRh Yi1zcGFuIj4gPC9zcGFuPg0KbmV0bW9kPGJyPg0KUGFnZXM6PHNwYW4gY2xhc3M9Im00NDM3MDk2 NzA3Mzk3NzM5NDhtLTU5MjMxNTUxNjAyMzY5OTM2NTZhcHBsZS10YWItc3BhbiI+IDwvc3Bhbj4N CjMyPGJyPg0KVVJMOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5l dG1vZC1hY2wtbW9kZWwtMTAudHh0PC9hPjxicj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLyIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLWFj bC1tb2RlbC88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5l dG1vZC1hY2wtbW9kZWwtMTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwPC9hPjxicj4NCkRpZmY6ICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldG1v ZC1hY2wtbW9kZWwtMTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwPC9hPjxicj4NCjxicj4NCkFi c3RyYWN0Ojxicj4NCiZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgZGF0YSBt b2RlbCBvZiBBY2Nlc3MgQ29udHJvbCBMaXN0IChBQ0wpPGJyPg0KJm5ic3A7Jm5ic3A7YmFzaWMg YnVpbGRpbmcgYmxvY2tzLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO0VkaXRvcmlhbCBOb3RlIChU byBiZSByZW1vdmVkIGJ5IFJGQyBFZGl0b3IpPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7VGhpcyBk cmFmdCBjb250YWlucyBtYW55IHBsYWNlaG9sZGVyIHZhbHVlcyB0aGF0IG5lZWQgdG8gYmUgcmVw bGFjZWQ8YnI+DQombmJzcDsmbmJzcDt3aXRoIGZpbmFsaXplZCB2YWx1ZXMgYXQgdGhlIHRpbWUg b2YgcHVibGljYXRpb24uJm5ic3A7IFRoaXMgbm90ZTxicj4NCiZuYnNwOyZuYnNwO3N1bW1hcml6 ZXMgYWxsIG9mIHRoZSBzdWJzdGl0dXRpb25zIHRoYXQgYXJlIG5lZWRlZC4mbmJzcDsgUGxlYXNl IG5vdGU8YnI+DQombmJzcDsmbmJzcDt0aGF0IG5vIG90aGVyIFJGQyBFZGl0b3IgaW5zdHJ1Y3Rp b25zIGFyZSBzcGVjaWZpZWQgYW55d2hlcmUgZWxzZSBpbjxicj4NCiZuYnNwOyZuYnNwO3RoaXMg ZG9jdW1lbnQuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7QXJ0d29yayBpbiB0aGlzIGRvY3VtZW50 IGNvbnRhaW5zIHNob3J0aGFuZCByZWZlcmVuY2VzIHRvIGRyYWZ0cyBpbjxicj4NCiZuYnNwOyZu YnNwO3Byb2dyZXNzLiZuYnNwOyBQbGVhc2UgYXBwbHkgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVu dHM8YnI+DQo8YnI+DQombmJzcDsmbmJzcDtvICZuYnNwOyZxdW90O1hYWFgmcXVvdDsgLS0mZ3Q7 IHRoZSBhc3NpZ25lZCBSRkMgdmFsdWUgZm9yIHRoaXMgZHJhZnQuPGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7byAmbmJzcDtSZXZpc2lvbiBkYXRlIGluIG1vZGVsIChPY3QgMTIsIDIwMTYpIG5lZWRz IHRvIGdldCB1cGRhdGVkIHdpdGg8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0 aGUgZGF0ZSB0aGUgZHJhZnQgZ2V0cyBhcHByb3ZlZC4mbmJzcDsgVGhlIGRhdGUgYWxzbyBuZWVk cyB0byBnZXQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtyZWZsZWN0ZWQgb24g dGhlIGxpbmUgd2l0aCAmbHQ7Q09ERSBCRUdJTlMmZ3Q7Ljxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NClRoZSBJ RVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5C204D53ECE04632A34A9BE96B913BD0junipernet_-- From nobody Fri Apr 7 16:37:19 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58E5128DE7; Fri, 7 Apr 2017 16:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCJGwO3QCBvm; Fri, 7 Apr 2017 16:37:03 -0700 (PDT) Received: from mail-wr0-x244.google.com (mail-wr0-x244.google.com [IPv6:2a00:1450:400c:c0c::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29BA12943E; Fri, 7 Apr 2017 16:36:51 -0700 (PDT) Received: by mail-wr0-x244.google.com with SMTP id t20so22021319wra.2; Fri, 07 Apr 2017 16:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=hlZB96sxc9OMVMn3BalzDiu5a+wf+98EizDkyiyyx0E=; b=m+iVCZrvAh3zyzyoXFiFqJMFOLb3AQSu7sBqZJ4uy4cxM6L2AMZdAahiUR8uo4MlSI aYxMEc62J5SDNe8fLARxPPHhn/bRkmyBD9UfsxtC3zPHtPTObxjU9DhQTTbucpVxdMDT 5yj7+uDynI+ZFmv6Tq8soMerlrL+9eFenfh2NwiZda+ewgfqufCPRAl7yZXDtxqO03wV U65zD/M2zPQE8joviey2XTLJt1p8HtYM0FRkA+7WVLkbODXviU6IIdQzizKvtnpNvdgh +Ab6eRGH21xsncDAmpAU/y08yyroE0C5QN8DLehny68YmIItdUoOTqtHs/+je1t/d3MJ IxZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=hlZB96sxc9OMVMn3BalzDiu5a+wf+98EizDkyiyyx0E=; b=N+EFMAqZz6XcQZ6xn4+XDTv2v3LkzUiu1QC5nUCTjpCbZaZiifOHMZid4Vs/ls6cFq Mcs0K55wTM030kDy4fGK6Fax7EXFHOViDnuHYM0XopN+483yK3joOS9jvxrrJA/0vclk 8Rm5gVJwKdZ8gr83NjVqzInx+6NhibgxfzE2Q2nxlXdO0SE/Fdlo9gJ+lK1aSlx7OJ// wOvtJXOZDz1RaXKuIaWQT33NmH6bu1YkMHvqzhkFh4mYo5YabNxbKbSfjdOR09RBTEy4 y7TRNkki56VpGBdLzjwvjKxaNIkx4EuguAgvF3afZ7LFux5APXRI6qwbd73qWQqCTn+h Y4zQ== X-Gm-Message-State: AFeK/H3S/0l3vNVPx9Qus5Q5rK2dLhaJAcx0/Rg7ZQUIMVdtgVBDeL0z3CZnH67Ie2jgEw== X-Received: by 10.223.152.67 with SMTP id v61mr15408636wrb.8.1491608210245; Fri, 07 Apr 2017 16:36:50 -0700 (PDT) Received: from [192.168.0.252] (0.205.23.93.rev.sfr.net. [93.23.205.0]) by smtp.gmail.com with ESMTPSA id c18sm7663804wre.48.2017.04.07.16.36.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 16:36:49 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Fri, 07 Apr 2017 16:36:52 -0700 From: Jeff Tantsura To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Message-ID: <8EE83B59-2558-4F3D-97C9-C12A732A6C82@gmail.com> Thread-Topic: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 23:37:11 -0000 yes/support (TM for Acee() Cheers, Jeff On 4/7/17, 7:22 PM, "netmod on behalf of Kent Watsen" wrote: >All, > >This is start of a two-week poll on making the following draft a >NETMOD working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > >Please send email to the list indicating "yes/support" or "no/do not >support". If indicating no, please state your reservations with the >document. If yes, please also feel free to provide comments you'd like >to see addressed once the document is a WG document. > > >Thank you, >NETMOD WG Chairs > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 7 18:16:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAE126DDF; Fri, 7 Apr 2017 18:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ije_K3zmJ4vd; Fri, 7 Apr 2017 18:16:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526921279EB; Fri, 7 Apr 2017 18:16:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKM71545; Sat, 08 Apr 2017 01:16:52 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 8 Apr 2017 02:16:51 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.8]) by SJCEML702-CHM.china.huawei.com ([169.254.4.233]) with mapi id 14.03.0235.001; Fri, 7 Apr 2017 18:16:44 -0700 From: Alexander Clemm To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams Thread-Index: AQHSr/Xg1jVz8di74UG+w/RFCeh9O6G6p7Ow Date: Sat, 8 Apr 2017 01:16:43 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF90711@SJCEML701-CHM.china.huawei.com> References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> In-Reply-To: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58E83A04.00B1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.8, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d8d4b6246a198b5e3766ec7f50ff8e45 Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 01:16:57 -0000 I do have a question re: the rationale that is given in the document: " Tod= ay's Common practice is include the definition of the syntax used to repr= esent a YANG module in every document that provides a tree diagram. This p= ractice has several disadvantages and the purpose of the document is to p= rovide a single location for this definition. " I am not sure how much simplification this will really bring - is the boile= rplate paragraph we find in drafts with YANG tree diagrams today really tha= t a big problem, specifically while the snippet is still small enough (and = could arguably even be generated by pyang itself, if extended accordingly, = for easy pasting into drafts)? While having a common and consistent defini= tion in a central location is appreciated, one implication as the tree nota= tion evolves will be that documents may now have to be specific as to which= notation revision is used (as the notation might be updated, revisions mig= ht need to be maintained, although it is understood that churn will be kept= to a minimum). =20 --- Alex -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Friday, April 07, 2017 4:23 PM To: netmod@ietf.org Cc: netmod-chairs@ietf.org Subject: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagram= s All, This is start of a two-week poll on making the following draft a NETMOD wor= king group document: draft-bjorklund-netmod-yang-tree-diagrams Please send email to the list indicating "yes/support" or "no/do not suppor= t". If indicating no, please state your reservations with the document. I= f yes, please also feel free to provide comments you'd like to see addresse= d once the document is a WG document. Thank you, NETMOD WG Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Apr 8 12:25:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FC7129468 for ; Sat, 8 Apr 2017 12:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKxdgvGBf-3e for ; Sat, 8 Apr 2017 12:25:43 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F05129467 for ; Sat, 8 Apr 2017 12:25:42 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id w64so13176529wma.0 for ; Sat, 08 Apr 2017 12:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6xUro5Hh+r9tZk3kE/l8lbvuxXmmF8g8IUaPxLNIDg4=; b=bzo/CmkTA+r9OA5tngdR6Hcd4fk10aesVNZnY1k+LiLuxb/W/beOSD8QQjdQk37Qhm 1wgywAPTRfQ3s0979Lmtecysbtwb76AHwkSizd3auk6/KR3jU2qKzG/TTiC1g3eXaXZT v2B0idZoB2vz0c9HubrgrzBZiLITMhACegJGvZHtR5MbNoQfcYmwmnG0rjekN2p2JRex 4Ni8vjPkDvrIegk7SFmNHI1DSmip16ag8dMem7QaCeAOn/oe7Q85N18vLRoqPI3O8IFJ rIeo4ZfXXadOBZIAy4lQ1a+yHvExcQugm0YfVuWXmDHi9MkHFuIo/aNk5kBuEjWrUSBV QfaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6xUro5Hh+r9tZk3kE/l8lbvuxXmmF8g8IUaPxLNIDg4=; b=iTBHSaRsXD4fIhGsDfb8OD+gwIE+0Ft9I3OYA9khXfxy3VIL7mTARj77Qku/F4b6vC d9MUD1YF7AqdDWfB7V7yJPcCzS7CDQX0M7PDcz3y6brI+pz7LoGHlmKHNPOj+igYegUz 3AWi/GogJHsTAwALvCCygsrZReH2qSEY/vhI32DtrgrkdXoW4TWQ3O20EY0zt9NGjgTf n8gnY84TYP5MqFn6zDujEntKUG9pPFEtBZ3WFM5CVdX6Uac0OJ3Y2zy/ptT3LWB/8GK9 jFQhZ+eA+8I/YJI+DxoCBMVGZ1sCA72pnwuZctnQLrVdK1zI1nrtHJgbxsgQOvu/yCdb mC5g== X-Gm-Message-State: AN3rC/5dpryszzplANc8+CnpTUORVIXremtRBZ2IRJ6f1JZny1uct4RT 6Ct1UOkGJy2nMo6NtCUBcZnYnmDhSA== X-Received: by 10.28.46.198 with SMTP id u189mr4067858wmu.54.1491679541164; Sat, 08 Apr 2017 12:25:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Sat, 8 Apr 2017 12:25:40 -0700 (PDT) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF90711@SJCEML701-CHM.china.huawei.com> References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> <644DA50AFA8C314EA9BDDAC83BD38A2E0DF90711@SJCEML701-CHM.china.huawei.com> From: Andy Bierman Date: Sat, 8 Apr 2017 12:25:40 -0700 Message-ID: To: Alexander Clemm Cc: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a11423b642ba8e0054cacb507 Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2017 19:25:46 -0000 --001a11423b642ba8e0054cacb507 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 7, 2017 at 6:16 PM, Alexander Clemm wrote: > I do have a question re: the rationale that is given in the document: " > Today's Common practice is include the definition of the syntax used to > represent a YANG module in every document that provides a tree diagram. > This practice has several disadvantages and the purpose of the document > is to provide a single location for this definition. " > > I am not sure how much simplification this will really bring - is the > boilerplate paragraph we find in drafts with YANG tree diagrams today > really that a big problem, specifically while the snippet is still small > enough (and could arguably even be generated by pyang itself, if extended > accordingly, for easy pasting into drafts)? While having a common and > consistent definition in a central location is appreciated, one implication > as the tree notation evolves will be that documents may now have to be > specific as to which notation revision is used (as the notation might be > updated, revisions might need to be maintained, although it is understood > that churn will be kept to a minimum). > > I think the idea is that the current practice of including a terminology section for YANG tree diagrams would stop. Instead, there will be an Informative reference to the YANG tree diagram RFC. Then YANG tree diagrams can appear in the document matching the syntax in the tree diagrams RFC. I support the new RFC and also the idea that these diagrams need to be consistent to have value for YANG readers. I do not like the current ad-hoc practice or reinventing the syntax in each RFC that uses a tree diagram. > --- Alex > Andy > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Friday, April 07, 2017 4:23 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] WG adoption poll draft-bjorklund-netmod-yang- > tree-diagrams > > All, > > This is start of a two-week poll on making the following draft a NETMOD > working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like to > see addressed once the document is a WG document. > > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11423b642ba8e0054cacb507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 7, 2017 at 6:16 PM, Alexander Clemm <<= a href=3D"mailto:alexander.clemm@huawei.com" target=3D"_blank">alexander.cl= emm@huawei.com> wrote:
I do= have a question re: the rationale that is given in the document: " To= day's Common practice is include the definition of the syntax used=C2= =A0 =C2=A0to represent a YANG module in every document that provides a tree= diagram.=C2=A0 This practice has several disadvantages and the purpose of= =C2=A0 =C2=A0the document is to provide a single location for this definiti= on. "

I am not sure how much simplification this will really bring - is the boile= rplate paragraph we find in drafts with YANG tree diagrams today really tha= t a big problem, specifically while the snippet is still small enough (and = could arguably even be generated by pyang itself, if extended accordingly, = for easy pasting into drafts)?=C2=A0 While having a common and consistent d= efinition in a central location is appreciated, one implication as the tree= notation evolves will be that documents may now have to be specific as to = which notation revision is used (as the notation might be updated, revision= s might need to be maintained, although it is understood that churn will be= kept to a minimum).



I think the idea is tha= t the current practice of including a terminology section for
YAN= G tree diagrams would stop.=C2=A0 Instead, there will be an Informative ref= erence
to the YANG tree diagram RFC. Then YANG tree diagrams can = appear in the document
matching the syntax in the tree diagrams R= FC.

I support the new RFC and also the idea that t= hese diagrams need to be
consistent to have value for YANG reader= s.=C2=A0 I do not like the current
ad-hoc practice or reinventing= the syntax in each RFC that uses a tree diagram.

=
=C2=A0
--- Alex

Andy
=C2=A0

-----Original Message-----
From: netmod [mailto:netmod-boun= ces@ietf.org] On Behalf Of Kent Watsen
Sent: Friday, April 07, 2017 4:23 PM
To: netmod@ietf.org
Cc: netmod-chairs@ietf.org Subject: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-di= agrams

All,

This is start of a two-week poll on making the following draft a NETMOD wor= king group document:

=C2=A0 draft-bjorklund-netmod-yang-tree-diagrams

Please send email to the list indicating "yes/support" or "n= o/do not support".=C2=A0 If indicating no, please state your reservati= ons with the document.=C2=A0 If yes, please also feel free to provide comme= nts you'd like to see addressed once the document is a WG document.


Thank you,
NETMOD WG Chairs


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

--001a11423b642ba8e0054cacb507-- From nobody Mon Apr 10 01:50:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16F212945D; Mon, 10 Apr 2017 01:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 W7zk4vOdQOjQ; Mon, 10 Apr 2017 01:50:43 -0700 (PDT) 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 1E3D112945C; Mon, 10 Apr 2017 01:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=696; q=dns/txt; s=iport; t=1491814243; x=1493023843; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/fsgFot8aD2a/UOvf5Znc+CspL2wZEYkC51aik8Cdns=; b=TLG89wkzZgU9HDIDc7xGgf4HM1fzMT9cex/t2bQF1/l5pGZ+t+F1HgPZ GI2O8VKUjMtCyS8sT/ca1ab4Jjl1afP5Mxfg+e3Z1hfFseyhQWXJrnwKO Uj/OwZiiewqGKJ67j83jaKUfXES0bynMJScfgvZpTpa+vNCPUwXt2iD0t I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAQDtRutY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDSBC415c5AvH5VXgg8hC4UuSgKEIBgBAgEBAQEBAQFrKIUWAQE?= =?us-ascii?q?BAwEBNjYLEAsOCi4nMAYBDAYCAQGKCw6rF4peAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEZBYZQggUJgmKEKBEBhgEBBJx7klkCgX2FLoM3hl2LZIgcHzh9CCUWCBgVQYZ?= =?us-ascii?q?bPzWGWoIuAQEB?= X-IronPort-AV: E=Sophos;i="5.37,181,1488844800"; d="scan'208";a="653866910" 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; 10 Apr 2017 08:50:40 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3A8oeG7014607; Mon, 10 Apr 2017 08:50:40 GMT To: Kent Watsen , "netmod@ietf.org" References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Cc: "netmod-chairs@ietf.org" From: Robert Wilton Message-ID: <60029664-0bdf-b666-bf48-d9293f8e157d@cisco.com> Date: Mon, 10 Apr 2017 09:50:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:50:45 -0000 Yes/support. On 08/04/2017 00:22, Kent Watsen wrote: > All, > > This is start of a two-week poll on making the following draft a > NETMOD working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Apr 10 01:54:52 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9341E129435; Mon, 10 Apr 2017 01:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 GLiimDDyLksN; Mon, 10 Apr 2017 01:54:48 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D79C1201F2; Mon, 10 Apr 2017 01:54:46 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:8547:4af1:c350:bcfc] (unknown [IPv6:2001:718:1a02:1:8547:4af1:c350:bcfc]) by mail.nic.cz (Postfix) with ESMTPSA id A8616608B1; Mon, 10 Apr 2017 10:54:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491814484; bh=bKSgAJ0OzvrhC1fRHOM5ZvMqRXpPUJ4vxsMIrDOYsSY=; h=From:Date:To; b=j5tHmBGvA8hjGEUqJMbZ8/N+YrJ+KUUNi/0blAxjofWyONkLAwLSujbnMLW1YX3u5 QQdC/yCWjFkxtBTk+uQ/GQ0WDamx+3iX9m3/zsnE/u5uw+PteQ8tNCEmu8VxyqcWlA aYLDSm07YCh+oS7sGDBuygYuISkaIslRjR/nmC7A= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <60029664-0bdf-b666-bf48-d9293f8e157d@cisco.com> Date: Mon, 10 Apr 2017 10:54:44 +0200 Cc: Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <06B286B3-039A-4ABA-9CEC-B39787631AD1@nic.cz> References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> <60029664-0bdf-b666-bf48-d9293f8e157d@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 08:54:51 -0000 > On 10 Apr 2017, at 10:50, Robert Wilton wrote: > > Yes/support. Support. Lada > > > On 08/04/2017 00:22, Kent Watsen wrote: >> All, >> >> This is start of a two-week poll on making the following draft a >> NETMOD working group document: >> >> draft-bjorklund-netmod-yang-tree-diagrams >> >> Please send email to the list indicating "yes/support" or "no/do not >> support". If indicating no, please state your reservations with the >> document. If yes, please also feel free to provide comments you'd like >> to see addressed once the document is a WG document. >> >> >> Thank you, >> NETMOD WG Chairs >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 10 02:16:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6222B129467; Mon, 10 Apr 2017 02:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 69hWEfhEILog; Mon, 10 Apr 2017 02:16:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91EE2120454; Mon, 10 Apr 2017 02:06:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKP58507; Mon, 10 Apr 2017 09:06:34 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 10:06:33 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.133]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0301.000; Mon, 10 Apr 2017 17:05:45 +0800 From: wangzitao To: Kent Watsen , "netmod@ietf.org" CC: "netmod-chairs@ietf.org" Thread-Topic: WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams Thread-Index: AQHSr/Xg1jVz8di74UG+w/RFCeh9O6G+Uzbw Date: Mon, 10 Apr 2017 09:05:45 +0000 Message-ID: References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> In-Reply-To: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.161] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58EB4B1B.012B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d8d4b6246a198b5e3766ec7f50ff8e45 Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:16:11 -0000 U3VwcG9ydC4NCi1NaWNoYWVsDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog S2VudCBXYXRzZW4gW21haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0XSANCuWPkemAgeaXtumXtDog MjAxN+W5tDTmnIg45pelIDc6MjMNCuaUtuS7tuS6ujogbmV0bW9kQGlldGYub3JnDQrmioTpgIE6 IG5ldG1vZC1jaGFpcnNAaWV0Zi5vcmcNCuS4u+mimDogV0cgYWRvcHRpb24gcG9sbCBkcmFmdC1i am9ya2x1bmQtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcw0KDQpBbGwsDQoNClRoaXMgaXMgc3Rh cnQgb2YgYSB0d28td2VlayBwb2xsIG9uIG1ha2luZyB0aGUgZm9sbG93aW5nIGRyYWZ0IGEgTkVU TU9EIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQ6DQoNCiAgZHJhZnQtYmpvcmtsdW5kLW5ldG1vZC15 YW5nLXRyZWUtZGlhZ3JhbXMNCg0KUGxlYXNlIHNlbmQgZW1haWwgdG8gdGhlIGxpc3QgaW5kaWNh dGluZyAieWVzL3N1cHBvcnQiIG9yICJuby9kbyBub3Qgc3VwcG9ydCIuICBJZiBpbmRpY2F0aW5n IG5vLCBwbGVhc2Ugc3RhdGUgeW91ciByZXNlcnZhdGlvbnMgd2l0aCB0aGUgZG9jdW1lbnQuICBJ ZiB5ZXMsIHBsZWFzZSBhbHNvIGZlZWwgZnJlZSB0byBwcm92aWRlIGNvbW1lbnRzIHlvdSdkIGxp a2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50Lg0K DQoNClRoYW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFpcnMNCg0KDQo= From nobody Mon Apr 10 02:19:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94571128C83 for ; Mon, 10 Apr 2017 02:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 N5O_N4l0rvLC for ; Mon, 10 Apr 2017 02:19:23 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5317E129435 for ; Mon, 10 Apr 2017 02:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14680; q=dns/txt; s=iport; t=1491815962; x=1493025562; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=jxUQLZHDoGwqs13M9P9BiXVajEi3Stt0sGLAE/1Jnts=; b=IpLVRLBsWbLiraSEIpuLb18rNBaOWMWcYFrEDNmmpZXt/PPvjnx2HL7l x3Vnwl1oGoXhJQ+20ZWwt/mWW8ERXSpyi1Pz9+U955hxLLcmQoJ61WYAL 7n/7PfJAUIglHasH2yA9pwtq7kxFJD3l4jNqSqC3GOpKa9nW7Id0Bukjq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQBITetY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm6BRoELjXlzkE6QI4U0gg8hAQqFLkoChB0YAQIBAQEBAQEBayi?= =?us-ascii?q?FFgEBAQMBAStBGwsYLicwBgEMBgIBAYoLDqscK4ozAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBGAWGUIIFgmuEQIV7BZx7klmKZIZdi2SIHB84gQUlFggYFUGGWz81iV8?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.37,181,1488844800"; d="scan'208,217";a="651025163" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 09:19:20 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3A9JK7b031557; Mon, 10 Apr 2017 09:19:20 GMT To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" References: From: Robert Wilton Message-ID: Date: Mon, 10 Apr 2017 10:19:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------413474B8C063605D96E06924" Archived-At: Subject: Re: [netmod] choice statements and trim vs explicit default handling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:19:24 -0000 This is a multi-part message in MIME format. --------------413474B8C063605D96E06924 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Jason, Your default statement in your YANG snippet below would be ignored, as per section 7.9.3 of RFC 7950. But, if you changed your YANG to this: choice foo { default aa; case aa { leaf some-bool { type Boolean; default “false”; } { case bb { leaf some-num { type int32; } } } Then answering both (A) and (B): I would assume that setting "some-bool" to "true" or "false" would cause "bb" to be deleted regardless of what default mode the server was using. If neither some-bool or some-num had been set to an explicit value then some-bool semantically exists with value "false" due to the two default statements. I might be wrong, but I have always assumed that the with-defaults extension is really concerned with the presentation/encoding of default values, and isn't intended to change the underlying semantics of YANG's handling of default values. Thanks, Rob On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi all, > > When a server operates in ‘trim’ mode (rfc6243), setting a leaf to its > default value removes it from the config (i.e. it is indistinguishable > from the case where that leaf was never configured or the case where > that leaf was deleted/removed). > > (A) > > Does setting a leaf in one case of a choice to its default value (in a > ‘trim’ mode server) cause leafs in other cases to be implicitly > deleted ? I assume not. > > For example: > > choice foo { > > case aa { > > leaf some-bool { type Boolean; default “false”; } > > { > > case bb { > > leaf some-num { type int32; } > > } > > } > > If some-num is currently set to 50, and then an edit-config sets > some-bool to “false”, does that clear the some-num leaf ? > > (i.e. does it select case aa ?) > > RFC 7950 says: “the creation of a node from one case implicitly > deletes all nodes from all other cases”. > > RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim > server) doesn’t exist. > > (B) > > Now how about if the server operates in ‘explicit’ mode ? Does > setting some-bool to “false” clear some-num ? I assume it does (but > it just seems a little funny that the behavior on this changes between > trim and explicit servers). > > Regards, > > Jason > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------413474B8C063605D96E06924 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Jason,

Your default statement in your YANG snippet below would be ignored, as per section 7.9.3 of RFC 7950.

But, if you changed your YANG to this:

choice foo {

  default aa;

  case aa {

    leaf some-bool { type Boolean; default “false”; }

  {

  case bb {

    leaf some-num { type int32; }

  }

}


Then answering both (A) and (B): I would assume that setting "some-bool" to "true" or "false" would cause "bb" to be deleted regardless of what default mode the server was using.  If neither some-bool or some-num had been set to an explicit value then some-bool semantically exists with value "false" due to the two default statements.

I might be wrong, but I have always assumed that the with-defaults extension is really concerned with the presentation/encoding of default values, and isn't intended to change the underlying semantics of YANG's handling of default values.

Thanks,
Rob
On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottawa) wrote:

Hi all,

 

When a server operates in ‘trim’ mode (rfc6243), setting a leaf to its default value removes it from the config (i.e. it is indistinguishable from the case where that leaf was never configured or the case where that leaf was deleted/removed).

 

(A)

Does setting a leaf in one case of a choice to its default value (in a ‘trim’ mode server) cause leafs in other cases to be implicitly deleted ?  I assume not.

 

For example:

 

choice foo {

  case aa {

    leaf some-bool { type Boolean; default “false”; }

  {

  case bb {

    leaf some-num { type int32; }

  }

}

 

If some-num is currently set to 50, and then an edit-config sets some-bool to “false”, does that clear the some-num leaf ?

(i.e. does it select case aa ?)

 

RFC 7950 says: “the creation of a node from one case implicitly deletes all nodes from all other cases”.

RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim server) doesn’t exist.

 

(B)

Now how about if the server operates in ‘explicit’ mode ?  Does setting some-bool to “false” clear some-num ?  I assume it does (but it just seems a little funny that the behavior on this changes between trim and explicit servers).

 

 

Regards,

Jason

 

 

 

 

 



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

--------------413474B8C063605D96E06924-- From nobody Mon Apr 10 04:45:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924261294A3; Mon, 10 Apr 2017 04:45:56 -0700 (PDT) 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] 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 vTNpTMkOJkHf; Mon, 10 Apr 2017 04:45:55 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8241294A2; Mon, 10 Apr 2017 04:45:54 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 4D4CB182000E; Mon, 10 Apr 2017 13:43:08 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , "netmod\@ietf.org" Cc: "netmod-chairs\@ietf.org" In-Reply-To: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> Date: Mon, 10 Apr 2017 13:45:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:45:57 -0000 As the author: yes/support. Two changes seemed to have support in IETF 98 audience: 1. Apart from text/plain, the media type SHOULD be text/markdown (variants permitted). 2. The "text-media-type" extension can appear anywhere in a (sub)module, and will be scoped to the parent statement and its substaments (unless overriden). Lada Kent Watsen writes: > All, > > This is start of a two-week poll on making the following draft a > NETMOD working group document: > > draft-lhotka-netmod-yang-markup-00 > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd > like to see addressed once the document is a WG document. > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 10 04:49:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B06A1294A1; Mon, 10 Apr 2017 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD1oX_F4DX55; Mon, 10 Apr 2017 04:49:38 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82BDE1205D3; Mon, 10 Apr 2017 04:49:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 41D111E5691; Mon, 10 Apr 2017 04:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ynqqlUrMwbeU; Mon, 10 Apr 2017 04:49:30 -0700 (PDT) Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id 6230A1E5687; Mon, 10 Apr 2017 04:49:29 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=us-ascii From: William Lupton In-Reply-To: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> Date: Mon, 10 Apr 2017 12:49:31 +0100 Cc: "netmod-chairs@ietf.org" , Kent Watsen Content-Transfer-Encoding: quoted-printable Message-Id: <1065616D-06FE-486E-8FBF-1016D9974ED2@broadband-forum.org> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> To: "netmod@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:49:40 -0000 yes/support my https://www.ietf.org/mail-archive/web/netmod/current/msg17899.html = comments still apply; in summary: * support use of markdown, with the principle that descriptions (etc) = remain readable as plain text * support defining conventions for formally referencing enums, bits, = nodes etc (allows validation and rendering as links) william > On 8 Apr 2017, at 00:24, Kent Watsen wrote: >=20 > All, >=20 > This is start of a two-week poll on making the following draft a=20 > NETMOD working group document: >=20 > draft-lhotka-netmod-yang-markup-00 >=20 > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd=20 > like to see addressed once the document is a WG document. >=20 > Thank you, > NETMOD WG Chairs From nobody Mon Apr 10 04:59:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692101294AB; Mon, 10 Apr 2017 04:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 oR0QiOitwZH5; Mon, 10 Apr 2017 04:59:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8203A1294A5; Mon, 10 Apr 2017 04:59:43 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:8547:4af1:c350:bcfc] (unknown [IPv6:2001:718:1a02:1:8547:4af1:c350:bcfc]) by mail.nic.cz (Postfix) with ESMTPSA id 189EC605B2; Mon, 10 Apr 2017 13:59:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491825582; bh=3N+wr8nmmsxRnt3EVgcM3hH5/EZfPmyF3E0qaZsQ0F0=; h=From:Date:To; b=eGcIrOHXmyMLeklv/dOTMUeLc7bseZLUK4wXk0tue6Wjq6YiMEqFMxEA7K4iMbEGD BTQiSJO0/XS6VfFfpCheOdvCCR9Y+qZQZQI0RURHwNWZmrpMIJJAJhznLwZGol9/G0 GbsgFqfIHS1n/hJWw1RG44wwdjJnkce5lpymJVcY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <1065616D-06FE-486E-8FBF-1016D9974ED2@broadband-forum.org> Date: Mon, 10 Apr 2017 13:59:41 +0200 Cc: "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <1065616D-06FE-486E-8FBF-1016D9974ED2@broadband-forum.org> To: William Lupton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 11:59:45 -0000 > On 10 Apr 2017, at 13:49, William Lupton = wrote: >=20 > yes/support >=20 > my https://www.ietf.org/mail-archive/web/netmod/current/msg17899.html = comments still apply; in summary: > * support use of markdown, with the principle that descriptions (etc) = remain readable as plain text > * support defining conventions for formally referencing enums, bits, = nodes etc (allows validation and rendering as links) >=20 I think a proper approach to this would be to define such markup = conventions as a markdown variant (in a separate document). Lada > william >=20 >> On 8 Apr 2017, at 00:24, Kent Watsen wrote: >>=20 >> All, >>=20 >> This is start of a two-week poll on making the following draft a=20 >> NETMOD working group document: >>=20 >> draft-lhotka-netmod-yang-markup-00 >>=20 >> Please send email to the list indicating "yes/support" or "no/do not >> support". If indicating no, please state your reservations with the >> document. If yes, please also feel free to provide comments you'd=20 >> like to see addressed once the document is a WG document. >>=20 >> Thank you, >> NETMOD WG Chairs >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Apr 10 06:30:06 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930E1294DF; Mon, 10 Apr 2017 06:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 tnTKy6pPTl6v; Mon, 10 Apr 2017 06:30:03 -0700 (PDT) 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 297531294E6; Mon, 10 Apr 2017 06:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2010; q=dns/txt; s=iport; t=1491831002; x=1493040602; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=xM9/SRjHU3G50+hE/jdYs75eU6BwzRQx8LE9FU161/M=; b=YGApUwb1H79sNFi7P8Hc5O96qrc3hF8YdU4ZG+hd85jGGDQuuQ0c6tXM Iyj58FWh6ucCkjxlxB3/tz9xYpLnophbCGwR7b2Aa6cf3yUc7dxpu3sNc JbhT+6gMPuqw+i3LILpYxj6UKyytoI3BVaUgg4Bb50pKucACqbkuQHd2Y U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQCJh+tY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDSBC415c5A0H5VXgg8hC4UuSgKEGxgBAgEBAQEBAQFrKIUWAQE?= =?us-ascii?q?BAwEBNjYLEAsYLicwBgEMBgIBAYoLDqsCimMBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBYZQggUJgmKBPIJsEQGGAQEEnHuSWYF/hS6DN4Zdi2SIHB84fQglFggYFUG?= =?us-ascii?q?EZ4F0PzWHMYIuAQEB?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="653872910" 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 Apr 2017 13:30:00 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3ADU0Bs031276; Mon, 10 Apr 2017 13:30:00 GMT To: Ladislav Lhotka , Kent Watsen , "netmod@ietf.org" References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> Cc: "netmod-chairs@ietf.org" From: Robert Wilton Message-ID: <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> Date: Mon, 10 Apr 2017 14:29:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 13:30:05 -0000 Yes/support. But with the condition that I would still like the draft to define a basic common subset of markdown fields/annotations that implementations would be expected to support. For clarity, I'm not suggesting that the draft should define a new markdown language, I think that it would be better to use an existing markdown language, but perhaps simplified. I want to avoid the scenario where each group of YANG modelers could decide to use a different incompatible variant of text/markdown, and hence generic tools would not be able to reliably render the markup for a generic YANG module. Care would need to be taken with which variant of the Markdown language is chosen as a base (RFC 7764 may be of use) . E.g. the github markup language has been previously suggested, but the specification document for that variant is long (approx 120 pages). Thanks, Rob On 10/04/2017 12:45, Ladislav Lhotka wrote: > As the author: yes/support. > > Two changes seemed to have support in IETF 98 audience: > > 1. Apart from text/plain, the media type SHOULD be text/markdown > (variants permitted). > > 2. The "text-media-type" extension can appear anywhere in a (sub)module, > and will be scoped to the parent statement and its substaments (unless > overriden). > > Lada > > Kent Watsen writes: > >> All, >> >> This is start of a two-week poll on making the following draft a >> NETMOD working group document: >> >> draft-lhotka-netmod-yang-markup-00 >> >> Please send email to the list indicating "yes/support" or "no/do not >> support". If indicating no, please state your reservations with the >> document. If yes, please also feel free to provide comments you'd >> like to see addressed once the document is a WG document. >> >> Thank you, >> NETMOD WG Chairs >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Apr 10 07:44:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35F212950A; Mon, 10 Apr 2017 07:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 gLkxYxWQ4ijG; Mon, 10 Apr 2017 07:44:22 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919C4129505; Mon, 10 Apr 2017 07:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=917; q=dns/txt; s=iport; t=1491835462; x=1493045062; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=t9snmuK23xOpT6rlvrIDq7diVbDYqElCaAz3MTRv7LI=; b=lJXkDPyYXU7o2KC58dWFo9n/T8pjmd3T90/CqA+M+D6BpJOH7DVeGAky 4zyVuq6AAkjHfOHx4pwWSxaN3tLfQb0mgAr/tO/Hh2kwCiapB/TKYAxX8 STBqfjMgihDuLu7JfWnXIDJUnT1ihxQMh/LHS+RXvc+4y6SZUPYwoMbrn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgBMmetY/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhhHGKE5FGZ5Rwgg8shXgCg18/GAECAQEBAQEBAWsohRYBBSM?= =?us-ascii?q?VQRALGAICJgICVwYBDAgBAYoLDqh9giaKYwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RgFgQuFRYIFgmuCPYFrEQGDIoJfAQSJJYdGjBCHAItZgX+FLoM3hl2LZIgcHzh?= =?us-ascii?q?9CCUWCBgVhzsgh2aCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="410021292" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 14:44:21 +0000 Received: from [10.24.49.39] ([10.24.49.39]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3AEiLkY000751; Mon, 10 Apr 2017 14:44:21 GMT To: Warren Kumari , The IESG References: <149132350838.1047.3054142067171081053.idtracker@ietfa.amsl.com> Cc: netmod-chairs@ietf.org, netmod@ietf.org From: Benoit Claise Message-ID: <005e8797-65a9-3b7b-c6ca-d93e408f4d30@cisco.com> Date: Mon, 10 Apr 2017 07:44:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149132350838.1047.3054142067171081053.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Warren Kumari's No Objection on charter-ietf-netmod-08-02: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:44:24 -0000 On 4/4/2017 9:31 AM, Warren Kumari wrote: > Warren Kumari has entered the following ballot position for > charter-ietf-netmod-08-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This seems clear to me. > Not sure if this is the place to address this, but the milestones seem, > um, aggressive... :-) The 4 documents for March and April are kind of done. Btw, I changed March to April. Slightly less agressive :-) Regards, B. > > > . > From nobody Mon Apr 10 07:51:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521E6129440 for ; Mon, 10 Apr 2017 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 6bGquXnUSX-P for ; Mon, 10 Apr 2017 07:51:42 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E90312950A for ; Mon, 10 Apr 2017 07:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=375; q=dns/txt; s=iport; t=1491835893; x=1493045493; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=PbRehUG/xrdMKfK2zGUSgabLT/BMe0PPyaV4/YWUdLw=; b=OWQzei7XZdZeY59/H8etJ6aMDNQwz/YQH0MpFAtJGK3cf/xi5A2x647I fxvMJCUN2Vq2nJRnpMh3ncz9sZ7OJSNV7X8fgcNwbs4xx9TzLE9cskQsg bjcIg0bJ9J/6ZGRfEsgx6Cq3Xg6uO0gIkbPHfevNM1byBEGzz3ecEGlUZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BSBwAhm+tY/40NJK1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1NhhHGcQZZ/LIlaQhUBAgEBAQEBAQFrKIU/FXYCJgJfDQgBAYoLDph5kAi?= =?us-ascii?q?CJopjAQEBAQEFAQEBAQEeBYELhUWCBYUohR+CXwWQa4wQhwCLWYFnAYh8hl2LZ?= =?us-ascii?q?IgcNSKBBSUWCBgVhzsgihQBAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="231145851" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 14:51:32 +0000 Received: from [10.24.49.39] ([10.24.49.39]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3AEpWKp008767 for ; Mon, 10 Apr 2017 14:51:32 GMT To: NETMOD Working Group From: Benoit Claise Message-ID: <971edd80-48b6-94f8-b5eb-67d6c408097c@cisco.com> Date: Mon, 10 Apr 2017 07:51:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] draft-ietf-netmod-rfc6087bis: milestones in the new charter proposal X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:51:44 -0000 Dear all, draft-ietf-netmod-rfc6087bis went back to the WG. In the new charter proposal, https://datatracker.ietf.org/doc/charter-ietf-netmod/, I introduced this milestone. Jul 2017 - Submit draft-ietf-netmod-rfc6087bis to IESG for publication (as Informational) Same date as the revised DS. Does it sound reasonable? Regards, Benoit From nobody Mon Apr 10 07:57:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91887129532; Mon, 10 Apr 2017 07:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 FOryKLu4rA_l; Mon, 10 Apr 2017 07:57:53 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB1C129530; Mon, 10 Apr 2017 07:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1517; q=dns/txt; s=iport; t=1491836272; x=1493045872; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=yV4uncB43rc0RE5ZLnJUmjr1hFdCWAIXyDVxN2vAeiU=; b=PQsRAObPGP+fWnwM786L6yfAyx8dkuo/En0B7y+BsbAzpw8FuCZNNZhG FBi9kxa1pN6X9G3VkY02rH4ILuGizSwx9sgeiUlPJg4FdUEteGjzuKtAx 0eD+VxmGifQvGKYb/EKsAgr5jiqGhs/7ktNWS3ORHZERWnj4iRygSd24f Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAQAjnetY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQuNeZEolXaCDyELhS5KAoNgPxgBAgEBAQEBAQFrKIUWAgE?= =?us-ascii?q?DAQE2NgsQC0YnMAYBDAYCAQEFigYOqxqKYwEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R2GUIIFCYJigj0zgTgRAYYBBYklh0aMEIcAi1mBf4UugzeGXYtkiBwfOH0IJRY?= =?us-ascii?q?IGBVBhFscGYFqIDUBhzCCLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="409109094" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2017 14:57:52 +0000 Received: from [10.24.49.39] ([10.24.49.39]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v3AEvoSk005698; Mon, 10 Apr 2017 14:57:51 GMT To: Spencer Dawkins , The IESG References: <149070955216.30562.13909945162900610745.idtracker@ietfa.amsl.com> Cc: netmod-chairs@ietf.org, netmod@ietf.org From: Benoit Claise Message-ID: Date: Mon, 10 Apr 2017 07:57:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149070955216.30562.13909945162900610745.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Spencer Dawkins' No Objection on charter-ietf-netmod-08-01: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:57:55 -0000 Hi Spencer, > Spencer Dawkins has entered the following ballot position for > charter-ietf-netmod-08-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-netmod/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This revised charter changes a lot of text, so I'm glad it's going for > external review, but it seems clear to me. Actually, all items in the milestones are well under way. For example, the first 4 are kind of done, and all milestones are already WG documents. Personally, I don't believe that we need to go through external review. The reason for updating the NETMOD charter is to align both NETMOD and NETCONF charters. > > I did wonder why the link to > http://www.ietf.org/iesg/directorate/yang-doctors.html was removed. Good point. The URL has been re-introduced. Regards, Benoit > Was > this not found to be useful in the current charter, or is there a policy > about URLs in charters that I should know about? > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Apr 10 09:19:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26212957A for ; Mon, 10 Apr 2017 09:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DocxMzUCd-YE for ; Mon, 10 Apr 2017 09:19:55 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E29129562 for ; Mon, 10 Apr 2017 09:19:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4FDF135C0AE3 for ; Mon, 10 Apr 2017 18:19:53 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4JpCEaHbybBz for ; Mon, 10 Apr 2017 18:19:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0A78335C0AE1 for ; Mon, 10 Apr 2017 18:19:53 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ovWHs8SczYsB for ; Mon, 10 Apr 2017 18:19:52 +0200 (CEST) Received: from [192.168.209.116] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id C115F35C0AE0 for ; Mon, 10 Apr 2017 18:19:52 +0200 (CEST) To: "netmod@ietf.org" References: From: Vladimir Vassilev Message-ID: <589a9020-b987-dbe5-d704-cf981de33b51@transpacket.com> Date: Mon, 10 Apr 2017 18:19:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:19:57 -0000 Hello, On 04/06/2017 07:43 PM, Andy Bierman wrote: > > 3) identity ethSubInterface > > This identity is used in the encapsulation container when-stmt. > It is not clear if this is intended as a base identity (like identity > sub-interface) > An example for the encapsulation container would help clarify the > expected usage > > This also has 2 bases (sub-interface and l2vlan). > Some explanation in the identity-stmt would be helpful > (since this is a new YANG 1.1 construct) It seems the intentended result was identity similar to ianaift:atmSubInterface (thus the naming convention change ethSubInterface instead of eth-sub-interface). I think it is less confusing to name the identity with the same naming convention used for the rest of the identities introduced e.g. sub-interface, loopback-internal etc. and if needed define new atm-sub-interface based on sub-interface. I am not sure even atm users would like a model where atmSubInterface will be the only identity of all future sub interface based identities not being derived from sub-interface because of this precedent: augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'ietf-if-cmn', 'sub-interface') or if:type = 'ianaift:atmSubInterface' or if:type = 'ianaift:frameRelay'" { Vladimir > > > Andy > From nobody Mon Apr 10 09:46:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BE3129566; Mon, 10 Apr 2017 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kffooIz4Gnnx; Mon, 10 Apr 2017 09:46:26 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2749B124BFA; Mon, 10 Apr 2017 09:46:26 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id l201so35000264ybf.0; Mon, 10 Apr 2017 09:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gHuyHVpBoIZ6m8IRaGPlIJTCNWwrfYUSbmnYTv5hOkg=; b=labSmAOB9uNqynCyE3SQ3AR/GhHmXKFTAk3en5UyHDTH6D3QD6tlWdl7O0C6MaVjZ8 DER3Z8/sRAA9uHyrZ0RhR0HhhvAkkyyJriz3xJBWdaTHoaUsiD38nOKoOaSwIOQ5Vmsr yRdcUGOaXu+DN3vRMLAJ7mjwf9i5BUlwhrcO4dQitltxxE6i5WZbJWzRQ/QypiMtr+5t m2yaxicKKWH7sVd3meJI+ZBmJvvVYd8reDZtNtZCMuSTOze1F5niCsbgQoBgGKTIsZOc juItiAVtfp1mX+MquGEpa/KA01esMCjB42qrm1JT/Db5rlbbHSnpuUCz7OVLnqbx+TgK hVpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gHuyHVpBoIZ6m8IRaGPlIJTCNWwrfYUSbmnYTv5hOkg=; b=e9VzlV28uC8XID8hruu3CyqENleLYUVJy0b9TDU7/Y2YY3U4SsLlnFbGxQQNMChM0m 1AiaaJRiSOqtfye+kgvDcATSOSGum6+CYNqlE5xvExnfZxZNul8H3KXlP1CaoaP4nKuD nLMfZJinIZFYKVktLCPqqOD+upLxf3EQyuQLD/lDGMj5ew1wEmP1rCDweIz+CJI8WiAv X+2tqneIyuvLcDwpFb3VqSGG3kQ6ZkGpQobZ+N9/PChmmwfnRLqzs2yK3VXiQ4lcwmgV SjbgzzeWSU405gHxADCNeijbsEyTWllxRNmsx4qzeogG2cwptdZwLzDC0IFXxodf0lkB HnxQ== X-Gm-Message-State: AN3rC/4VZYvZulrlpdWKTXg1so+g8ZzV4hd/mH4CCpFED4eFbZVsr3TP/I6Rfxpzl+8YXbcd7/1KXnqYYLCgUA== X-Received: by 10.37.211.81 with SMTP id e78mr6362997ybf.121.1491842785242; Mon, 10 Apr 2017 09:46:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.73.129 with HTTP; Mon, 10 Apr 2017 09:46:24 -0700 (PDT) In-Reply-To: References: <149070955216.30562.13909945162900610745.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Mon, 10 Apr 2017 11:46:24 -0500 Message-ID: To: Benoit Claise Cc: The IESG , netmod-chairs@ietf.org, netmod@ietf.org Content-Type: multipart/alternative; boundary=94eb2c147c3c467487054cd2b72c Archived-At: Subject: Re: [netmod] Spencer Dawkins' No Objection on charter-ietf-netmod-08-01: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:46:28 -0000 --94eb2c147c3c467487054cd2b72c Content-Type: text/plain; charset=UTF-8 Hi, Benoit, On Mon, Apr 10, 2017 at 9:57 AM, Benoit Claise wrote: > Hi Spencer, > >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-netmod-08-01: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-netmod/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This revised charter changes a lot of text, so I'm glad it's going for >> external review, but it seems clear to me. >> > Actually, all items in the milestones are well under way. > For example, the first 4 are kind of done, and all milestones are already > WG documents. > Personally, I don't believe that we need to go through external review. > I'm seeing the ballot question as "Ballot question: "Is this charter ready for external review?"" What am I missing? To be clear - I ALSO don't object if you think this revision doesn't need to go for external review, but I'm not entirely sure what I was balloting No Objection on ;-) Spencer, who should be highly experienced at the futility of trying to signal both error and congestion in TCP with one signal (packet loss), but who doesn't quite know how to ballot "is this charter ready for IETF Last Call? Does it need to go for external review outside the IETF community?" with one ballot position. > The reason for updating the NETMOD charter is to align both NETMOD and > NETCONF charters. > >> >> I did wonder why the link to >> http://www.ietf.org/iesg/directorate/yang-doctors.html was removed. >> > Good point. The URL has been re-introduced. > > Regards, Benoit > >> Was >> this not found to be useful in the current charter, or is there a policy >> about URLs in charters that I should know about? >> > > >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> . >> >> > --94eb2c147c3c467487054cd2b72c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Benoit,

On Mon, Apr 10, 2017 at 9:57 AM, Benoit Claise <bclaise@cisco.c= om> wrote:
Hi Spencer,
Spencer Dawkins has entered the following ballot position for
charter-ietf-netmod-08-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-i= etf-netmod/



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

This revised charter changes a lot of text, so I'm glad it's going = for
external review, but it seems clear to me.
 Actually, all items in the milestones are well under way.
For example, the first 4 are kind of done, and all milestones are already W= G documents.
Personally, I don't believe that we need to go through external review.=

I'm seeing the ballot question as = "Ball= ot question:=C2=A0"Is this charter ready for external review?""
=
What am I missing?=C2=A0
<= br>
To be clear - I ALSO don't object i= f you think this revision doesn't need to go for external review, but I= 'm not entirely sure what I was balloting No Objection on ;-)

Sp= encer, who should be highly experienced at the futility of trying to signal= both error and congestion in TCP with one signal (packet loss), but who do= esn't quite know how to ballot "is this charter ready for IETF Las= t Call? Does it need to go for external review outside the IETF community?&= quot; with one ballot position.=C2=A0
=C2=A0
The reason for updating the NETMOD charter is = to align both NETMOD and NETCONF charters.

I did wonder why the link to
http://www.ietf.org/iesg/directorate/yang= -doctors.html was removed.
 Good point. The URL has been re-introduced.

Regards, Benoit
Was
this not found to be useful in the current charter, or is there a policy about URLs in charters that I should know about?



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



--94eb2c147c3c467487054cd2b72c-- From nobody Mon Apr 10 10:17:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D601294EF for ; Mon, 10 Apr 2017 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 7nBTMBETHwPQ for ; Mon, 10 Apr 2017 10:16:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82E41277BB for ; Mon, 10 Apr 2017 10:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13669; q=dns/txt; s=iport; t=1491844616; x=1493054216; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=YVifpz5yhcYT17FRTI1N9rSSlSPYTF2dK9dgPUxuZW4=; b=hRpihimvh5epeUk00DsvDHXv9au8wrXxWJdZVSNq5Dgo/m6PDo6G7aya bXih4IGD15p3RrpVui8KcoEyHP/3RxHNQOp9G4KPE1occ8qQMWseBfwRC YFX48s3S2X3eok8Z6Gdthm35sB5Fw9xbjSEkY3eMTcnKpM9rh4kzPEXuo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAQAavetY/xbLJq1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOoEMgQuNeXOQVZAjhTSCDyEBCoJCgmxKAoQlGAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBAWwbCxguJzAGAQwGAgEBigMIDqsoK4pSAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWGUIIFgmuEL4VtHwWJLIY+jRGSWYNfhwWGXYtkiBwfOIE?= =?us-ascii?q?FJRYIGBVBhls/NYlfAQEB?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208,217";a="651035671" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 17:16:52 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v3AHGq7C014701; Mon, 10 Apr 2017 17:16:52 GMT To: Vladimir Vassilev , "netmod@ietf.org" References: <589a9020-b987-dbe5-d704-cf981de33b51@transpacket.com> From: Robert Wilton Message-ID: <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> Date: Mon, 10 Apr 2017 18:16:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <589a9020-b987-dbe5-d704-cf981de33b51@transpacket.com> Content-Type: multipart/alternative; boundary="------------CB0BB9A47E8825983BB5C043" Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 17:17:00 -0000 This is a multi-part message in MIME format. --------------CB0BB9A47E8825983BB5C043 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Vladimir, all, On 10/04/2017 17:19, Vladimir Vassilev wrote: > Hello, > > On 04/06/2017 07:43 PM, Andy Bierman wrote: >> >> 3) identity ethSubInterface >> >> This identity is used in the encapsulation container when-stmt. >> It is not clear if this is intended as a base identity (like identity >> sub-interface) >> An example for the encapsulation container would help clarify the >> expected usage >> >> This also has 2 bases (sub-interface and l2vlan). >> Some explanation in the identity-stmt would be helpful >> (since this is a new YANG 1.1 construct) > It seems the intentended result was identity similar to > ianaift:atmSubInterface (thus the naming convention change > ethSubInterface instead of eth-sub-interface). I think it is less > confusing to name the identity with the same naming convention used > for the rest of the identities introduced e.g. sub-interface, > loopback-internal etc. and if needed define new atm-sub-interface > based on sub-interface. I am not sure even atm users would like a > model where atmSubInterface will be the only identity of all future > sub interface based identities not being derived from sub-interface > because of this precedent: > > augment "/if:interfaces/if:interface" { > when "derived-from(if:type, > 'ietf-if-cmn', > 'sub-interface') or > if:type = 'ianaift:atmSubInterface' or > if:type = 'ianaift:frameRelay'" { My idea was that all sub-interfaces could inherit from a common identity. I don't think that this idea just applies to sub-interfaces, but other interface properties as well. E.g. sub-interface (i.e. any interface that is logically a child interface of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM sub-interface, FR sub-interface) ethernet-like (i.e. does the interface use ethernet framing). E.g. this would apply to physical Ethernet, LAG, IRB interfaces. physical (i.e. an interface that is generally instantiated due to some physical hardware) logical? (This is harder to define, but roughly an interface that is a software construct). there must be other generic properties as well. My main aim is for future flexibility. I.e. so that if need interface types get defined in the future they can share existing interface related configuration and state without having to redefine it. Similarly, if there are vendor specific variants of interfaces then they could also reuse the existing interface related configuration and state without having to define vendor specific MTU leaves, etc for the new interface type. My refinement of this idea, is still to define these generic properties, but then revise iana-if-type.yang to add these common interface properties as additional base identities. E.g. identity interface-property-type { description "Base identity from which all interface properties are derived."; } identity sub-interface-like { description "The interface has sub-interface properties"; base interface-property-type; } identity ethernet-like { description "The interface uses ethernet framing, e.g. has a MAC address associated with it."; base interface-property-type; } ... Then, for example, the IANA type for atm & l2vlan (if this is the IANA type for an Ethernet sub-interface) would change from: identity atmSubInterface { base iana-interface-type; description "ATM Sub Interface."; } identity l2vlan { base iana-interface-type; description "Layer 2 Virtual LAN using 802.1Q."; } to: identity atmSubInterface { base iana-interface-type; base sub-interface-like; description "ATM Sub Interface."; } identity l2vlan { base iana-interface-type; base sub-interface-like; description "Layer 2 Virtual LAN using 802.1Q."; } and hence the augment can just become: augment "/if:interfaces/if:interface" { when "derived-from(if:type, 'ietf-if', 'sub-interface')" { ... } If someone wants to define a new type of sub-interface in the future they can. They just need to ensure that when they define the type in iana-if-types it also derives from the sub-interface property, and then they would automatically pick up the generic sub-interface configuration leaf. This would fix this issue that having when statements on IANA defined interface types isn't really robust or flexible. Finally, adding these properties to iana-if-types.yang would be a backwards compatible change. What are other peoples opinion's on this idea? Thanks, Rob > > Vladimir >> >> >> Andy >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------CB0BB9A47E8825983BB5C043 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Vladimir, all,


On 10/04/2017 17:19, Vladimir Vassilev wrote:
Hello,

On 04/06/2017 07:43 PM, Andy Bierman wrote:

3) identity ethSubInterface

This identity is used in the encapsulation container when-stmt.
It is not clear if this is intended as a base identity (like identity sub-interface)
An example for the encapsulation container would help clarify the
expected usage

This also has 2 bases (sub-interface and l2vlan).
Some explanation in the identity-stmt would be helpful
(since this is a new YANG 1.1 construct)
It seems the intentended result was identity similar to ianaift:atmSubInterface (thus the naming convention change ethSubInterface instead of eth-sub-interface). I think it is less confusing to name the identity with the same naming convention used for the rest of the identities introduced e.g. sub-interface, loopback-internal etc. and if needed define new atm-sub-interface based on sub-interface. I am not sure even atm users would like a model where atmSubInterface will be the only identity of all future sub interface based identities not being derived from sub-interface because of this precedent:

     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type,
                          'ietf-if-cmn',
                          'sub-interface') or
             if:type = 'ianaift:atmSubInterface' or
             if:type = 'ianaift:frameRelay'"  {

My idea was that all sub-interfaces could inherit from a common identity.  I don't think that this idea just applies to sub-interfaces, but other interface properties as well.  E.g.
 sub-interface (i.e. any interface that is logically a child interface of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM sub-interface, FR sub-interface)
 ethernet-like (i.e. does the interface use ethernet framing).  E.g. this would apply to physical Ethernet, LAG, IRB interfaces.
 physical (i.e. an interface that is generally instantiated due to some physical hardware)
 logical? (This is harder to define, but roughly an interface that is a software construct).
 there must be other generic properties as well.

My main aim is for future flexibility.  I.e. so that if need interface types get defined in the future they can share existing interface related configuration and state without having to redefine it.  Similarly, if there are vendor specific variants of interfaces then they could also reuse the existing interface related configuration and state without having to define vendor specific MTU leaves, etc for the new interface type.

My refinement of this idea, is still to define these generic properties, but then revise iana-if-type.yang to add these common interface properties as additional base identities.

E.g. 
     identity interface-property-type {
       description
         "Base identity from which all interface properties are
          derived.";
     }

     identity sub-interface-like {
       description
         "The interface has sub-interface properties";
       base interface-property-type;
     }

     identity ethernet-like {
       description
         "The interface uses ethernet framing, e.g. has a MAC address associated with it.";
       base interface-property-type;
     }

     ...


Then, for example, the IANA type for atm & l2vlan (if this is the IANA type for an Ethernet sub-interface) would change from:


  identity atmSubInterface {
    base iana-interface-type;
    description
      "ATM Sub Interface.";
  }


  identity l2vlan {
    base iana-interface-type;
    description
      "Layer 2 Virtual LAN using 802.1Q.";
  }

to:

  identity atmSubInterface {
    base iana-interface-type;
    base sub-interface-like;
    description
      "ATM Sub Interface.";
  }

  identity l2vlan {
    base iana-interface-type;
    base sub-interface-like;
    description
      "Layer 2 Virtual LAN using 802.1Q.";
  }

and hence the augment can just become:
     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'ietf-if', 'sub-interface')"  {
          ...
     }

If someone wants to define a new type of sub-interface in the future they can.  They just need to ensure that when they define the type in iana-if-types it also derives from the sub-interface property, and then they would automatically pick up the generic sub-interface configuration leaf.  This would fix this issue that having when statements on IANA defined interface types isn't really robust or flexible.

Finally, adding these properties to iana-if-types.yang would be a backwards compatible change.

What are other peoples opinion's on this idea?

Thanks,
Rob



Vladimir


Andy


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


--------------CB0BB9A47E8825983BB5C043-- From nobody Tue Apr 11 03:13:08 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E470E1275AB for ; Tue, 11 Apr 2017 03:13:06 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhmOZ8IpWqlU for ; Tue, 11 Apr 2017 03:13:05 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 244FC127286 for ; Tue, 11 Apr 2017 03:13:05 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 0854B1AE0351; Tue, 11 Apr 2017 12:13:03 +0200 (CEST) Date: Tue, 11 Apr 2017 12:13:13 +0200 (CEST) Message-Id: <20170411.121313.282585946337498966.mbj@tail-f.com> To: rwilton@cisco.com Cc: vladimir@transpacket.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> References: <589a9020-b987-dbe5-d704-cf981de33b51@transpacket.com> <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 10:13:07 -0000 Robert Wilton wrote: > Hi Vladimir, all, > > > On 10/04/2017 17:19, Vladimir Vassilev wrote: > > Hello, > > > > On 04/06/2017 07:43 PM, Andy Bierman wrote: > >> > >> 3) identity ethSubInterface > >> > >> This identity is used in the encapsulation container when-stmt. > >> It is not clear if this is intended as a base identity (like identity > >> sub-interface) > >> An example for the encapsulation container would help clarify the > >> expected usage > >> > >> This also has 2 bases (sub-interface and l2vlan). > >> Some explanation in the identity-stmt would be helpful > >> (since this is a new YANG 1.1 construct) > > It seems the intentended result was identity similar to > > ianaift:atmSubInterface (thus the naming convention change > > ethSubInterface instead of eth-sub-interface). I think it is less > > confusing to name the identity with the same naming convention used > > for the rest of the identities introduced e.g. sub-interface, > > loopback-internal etc. and if needed define new atm-sub-interface > > based on sub-interface. I am not sure even atm users would like a > > model where atmSubInterface will be the only identity of all future > > sub interface based identities not being derived from sub-interface > > because of this precedent: > > > > augment "/if:interfaces/if:interface" { > > when "derived-from(if:type, > > 'ietf-if-cmn', > > 'sub-interface') or > > if:type = 'ianaift:atmSubInterface' or > > if:type = 'ianaift:frameRelay'" { > > My idea was that all sub-interfaces could inherit from a common > identity. I don't think that this idea just applies to > sub-interfaces, but other interface properties as well. E.g. > sub-interface (i.e. any interface that is logically a child interface > of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM > sub-interface, FR sub-interface) > ethernet-like (i.e. does the interface use ethernet framing). > E.g. this would apply to physical Ethernet, LAG, IRB interfaces. > physical (i.e. an interface that is generally instantiated due to some > physical hardware) > logical? (This is harder to define, but roughly an interface that is a > software construct). > there must be other generic properties as well. > > My main aim is for future flexibility. I.e. so that if need interface > types get defined in the future they can share existing interface > related configuration and state without having to redefine it. > Similarly, if there are vendor specific variants of interfaces then > they could also reuse the existing interface related configuration and > state without having to define vendor specific MTU leaves, etc for the > new interface type. > > My refinement of this idea, is still to define these generic > properties, but then revise iana-if-type.yang to add these common > interface properties as additional base identities. > > E.g. > > identity interface-property-type { > description > "Base identity from which all interface properties are > derived."; > } > > > identity sub-interface-like { > description > "The interface has sub-interface properties"; > base interface-property-type; > } > > identity ethernet-like { > description > "The interface uses ethernet framing, e.g. has a MAC address > associated with it."; > base interface-property-type; > } > > ... > > > Then, for example, the IANA type for atm & l2vlan (if this is the IANA > type for an Ethernet sub-interface) would change from: > > > identity atmSubInterface { > base iana-interface-type; > description > "ATM Sub Interface."; > } > > identity l2vlan { > base iana-interface-type; > description > "Layer 2 Virtual LAN using 802.1Q."; > } > > to: > > identity atmSubInterface { > base iana-interface-type; > base sub-interface-like; > description > "ATM Sub Interface."; > } > > identity l2vlan { > base iana-interface-type; > base sub-interface-like; > description > "Layer 2 Virtual LAN using 802.1Q."; > } > > and hence the augment can just become: > > augment "/if:interfaces/if:interface" { > when "derived-from(if:type, 'ietf-if', 'sub-interface')" { > ... > } > > If someone wants to define a new type of sub-interface in the future > they can. They just need to ensure that when they define the type in > iana-if-types it also derives from the sub-interface property, and > then they would automatically pick up the generic sub-interface > configuration leaf. This would fix this issue that having when > statements on IANA defined interface types isn't really robust or > flexible. > > Finally, adding these properties to iana-if-types.yang would be a > backwards compatible change. > > What are other peoples opinion's on this idea? I think that this is good idea. We have discussed adding properties as identities before. Having them in the iana-if-types would make these types more useful. But this would require a non-signinficant change to draft-ietf-netmod-intf-ext-yang, right? We would need an update to iana-if-types and move the identities there. /martin From nobody Tue Apr 11 04:26:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4373129442 for ; Tue, 11 Apr 2017 04:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gsi9cXxkW5Yz for ; Tue, 11 Apr 2017 04:26:44 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 34484128C83 for ; Tue, 11 Apr 2017 04:26:43 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E0E20182000E; Tue, 11 Apr 2017 13:23:48 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , rwilton@cisco.com Cc: netmod@ietf.org In-Reply-To: <20170411.121313.282585946337498966.mbj@tail-f.com> References: <589a9020-b987-dbe5-d704-cf981de33b51@transpacket.com> <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> <20170411.121313.282585946337498966.mbj@tail-f.com> Date: Tue, 11 Apr 2017 13:26:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:26:47 -0000 Martin Bjorklund writes: > Robert Wilton wrote: >> Hi Vladimir, all, >> >> >> On 10/04/2017 17:19, Vladimir Vassilev wrote: >> > Hello, >> > >> > On 04/06/2017 07:43 PM, Andy Bierman wrote: >> >> >> >> 3) identity ethSubInterface >> >> >> >> This identity is used in the encapsulation container when-stmt. >> >> It is not clear if this is intended as a base identity (like identity >> >> sub-interface) >> >> An example for the encapsulation container would help clarify the >> >> expected usage >> >> >> >> This also has 2 bases (sub-interface and l2vlan). >> >> Some explanation in the identity-stmt would be helpful >> >> (since this is a new YANG 1.1 construct) >> > It seems the intentended result was identity similar to >> > ianaift:atmSubInterface (thus the naming convention change >> > ethSubInterface instead of eth-sub-interface). I think it is less >> > confusing to name the identity with the same naming convention used >> > for the rest of the identities introduced e.g. sub-interface, >> > loopback-internal etc. and if needed define new atm-sub-interface >> > based on sub-interface. I am not sure even atm users would like a >> > model where atmSubInterface will be the only identity of all future >> > sub interface based identities not being derived from sub-interface >> > because of this precedent: >> > >> > augment "/if:interfaces/if:interface" { >> > when "derived-from(if:type, >> > 'ietf-if-cmn', >> > 'sub-interface') or >> > if:type = 'ianaift:atmSubInterface' or >> > if:type = 'ianaift:frameRelay'" { >> >> My idea was that all sub-interfaces could inherit from a common >> identity. I don't think that this idea just applies to >> sub-interfaces, but other interface properties as well. E.g. >> sub-interface (i.e. any interface that is logically a child interface >> of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM >> sub-interface, FR sub-interface) >> ethernet-like (i.e. does the interface use ethernet framing). >> E.g. this would apply to physical Ethernet, LAG, IRB interfaces. >> physical (i.e. an interface that is generally instantiated due to some >> physical hardware) >> logical? (This is harder to define, but roughly an interface that is a >> software construct). >> there must be other generic properties as well. >> >> My main aim is for future flexibility. I.e. so that if need interface >> types get defined in the future they can share existing interface >> related configuration and state without having to redefine it. >> Similarly, if there are vendor specific variants of interfaces then >> they could also reuse the existing interface related configuration and >> state without having to define vendor specific MTU leaves, etc for the >> new interface type. >> >> My refinement of this idea, is still to define these generic >> properties, but then revise iana-if-type.yang to add these common >> interface properties as additional base identities. >> >> E.g. >> >> identity interface-property-type { >> description >> "Base identity from which all interface properties are >> derived."; >> } >> >> >> identity sub-interface-like { >> description >> "The interface has sub-interface properties"; >> base interface-property-type; >> } >> >> identity ethernet-like { >> description >> "The interface uses ethernet framing, e.g. has a MAC address >> associated with it."; >> base interface-property-type; >> } >> >> ... >> >> >> Then, for example, the IANA type for atm & l2vlan (if this is the IANA >> type for an Ethernet sub-interface) would change from: >> >> >> identity atmSubInterface { >> base iana-interface-type; >> description >> "ATM Sub Interface."; >> } >> >> identity l2vlan { >> base iana-interface-type; >> description >> "Layer 2 Virtual LAN using 802.1Q."; >> } >> >> to: >> >> identity atmSubInterface { >> base iana-interface-type; >> base sub-interface-like; >> description >> "ATM Sub Interface."; >> } >> >> identity l2vlan { >> base iana-interface-type; >> base sub-interface-like; >> description >> "Layer 2 Virtual LAN using 802.1Q."; >> } >> >> and hence the augment can just become: >> >> augment "/if:interfaces/if:interface" { >> when "derived-from(if:type, 'ietf-if', 'sub-interface')" { >> ... >> } >> >> If someone wants to define a new type of sub-interface in the future >> they can. They just need to ensure that when they define the type in >> iana-if-types it also derives from the sub-interface property, and >> then they would automatically pick up the generic sub-interface >> configuration leaf. This would fix this issue that having when >> statements on IANA defined interface types isn't really robust or >> flexible. >> >> Finally, adding these properties to iana-if-types.yang would be a >> backwards compatible change. >> >> What are other peoples opinion's on this idea? > > I think that this is good idea. We have discussed adding properties Yes. Such use cases were actually the motivation for introducing multiple inheritance of identities in the first place. > as identities before. Having them in the iana-if-types would make > these types more useful. > > But this would require a non-signinficant change to > draft-ietf-netmod-intf-ext-yang, right? We would need an update to > iana-if-types and move the identities there. But then iana-if-type would diverge from the underlying IANA registry, which would be confusing. It is IMO better to start a new module (or a few of them) with a sound structure of interface types and no reference to the IANA interface registry. Lada > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 11 04:31:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C78A127775 for ; Tue, 11 Apr 2017 04:31:26 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGi3FvQbl2uY for ; Tue, 11 Apr 2017 04:31:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4731C126C25 for ; Tue, 11 Apr 2017 04:31:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 584931AE0351; Tue, 11 Apr 2017 13:31:23 +0200 (CEST) Date: Tue, 11 Apr 2017 13:31:33 +0200 (CEST) Message-Id: <20170411.133133.535844576323902109.mbj@tail-f.com> To: lhotka@nic.cz Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> <20170411.121313.282585946337498966.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:31:26 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Robert Wilton wrote: > >> Hi Vladimir, all, > >> > >> > >> On 10/04/2017 17:19, Vladimir Vassilev wrote: > >> > Hello, > >> > > >> > On 04/06/2017 07:43 PM, Andy Bierman wrote: > >> >> > >> >> 3) identity ethSubInterface > >> >> > >> >> This identity is used in the encapsulation container when-stmt. > >> >> It is not clear if this is intended as a base identity (like identity > >> >> sub-interface) > >> >> An example for the encapsulation container would help clarify the > >> >> expected usage > >> >> > >> >> This also has 2 bases (sub-interface and l2vlan). > >> >> Some explanation in the identity-stmt would be helpful > >> >> (since this is a new YANG 1.1 construct) > >> > It seems the intentended result was identity similar to > >> > ianaift:atmSubInterface (thus the naming convention change > >> > ethSubInterface instead of eth-sub-interface). I think it is less > >> > confusing to name the identity with the same naming convention used > >> > for the rest of the identities introduced e.g. sub-interface, > >> > loopback-internal etc. and if needed define new atm-sub-interface > >> > based on sub-interface. I am not sure even atm users would like a > >> > model where atmSubInterface will be the only identity of all future > >> > sub interface based identities not being derived from sub-interface > >> > because of this precedent: > >> > > >> > augment "/if:interfaces/if:interface" { > >> > when "derived-from(if:type, > >> > 'ietf-if-cmn', > >> > 'sub-interface') or > >> > if:type = 'ianaift:atmSubInterface' or > >> > if:type = 'ianaift:frameRelay'" { > >> > >> My idea was that all sub-interfaces could inherit from a common > >> identity. I don't think that this idea just applies to > >> sub-interfaces, but other interface properties as well. E.g. > >> sub-interface (i.e. any interface that is logically a child interface > >> of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM > >> sub-interface, FR sub-interface) > >> ethernet-like (i.e. does the interface use ethernet framing). > >> E.g. this would apply to physical Ethernet, LAG, IRB interfaces. > >> physical (i.e. an interface that is generally instantiated due to some > >> physical hardware) > >> logical? (This is harder to define, but roughly an interface that is a > >> software construct). > >> there must be other generic properties as well. > >> > >> My main aim is for future flexibility. I.e. so that if need interface > >> types get defined in the future they can share existing interface > >> related configuration and state without having to redefine it. > >> Similarly, if there are vendor specific variants of interfaces then > >> they could also reuse the existing interface related configuration and > >> state without having to define vendor specific MTU leaves, etc for the > >> new interface type. > >> > >> My refinement of this idea, is still to define these generic > >> properties, but then revise iana-if-type.yang to add these common > >> interface properties as additional base identities. > >> > >> E.g. > >> > >> identity interface-property-type { > >> description > >> "Base identity from which all interface properties are > >> derived."; > >> } > >> > >> > >> identity sub-interface-like { > >> description > >> "The interface has sub-interface properties"; > >> base interface-property-type; > >> } > >> > >> identity ethernet-like { > >> description > >> "The interface uses ethernet framing, e.g. has a MAC address > >> associated with it."; > >> base interface-property-type; > >> } > >> > >> ... > >> > >> > >> Then, for example, the IANA type for atm & l2vlan (if this is the IANA > >> type for an Ethernet sub-interface) would change from: > >> > >> > >> identity atmSubInterface { > >> base iana-interface-type; > >> description > >> "ATM Sub Interface."; > >> } > >> > >> identity l2vlan { > >> base iana-interface-type; > >> description > >> "Layer 2 Virtual LAN using 802.1Q."; > >> } > >> > >> to: > >> > >> identity atmSubInterface { > >> base iana-interface-type; > >> base sub-interface-like; > >> description > >> "ATM Sub Interface."; > >> } > >> > >> identity l2vlan { > >> base iana-interface-type; > >> base sub-interface-like; > >> description > >> "Layer 2 Virtual LAN using 802.1Q."; > >> } > >> > >> and hence the augment can just become: > >> > >> augment "/if:interfaces/if:interface" { > >> when "derived-from(if:type, 'ietf-if', 'sub-interface')" { > >> ... > >> } > >> > >> If someone wants to define a new type of sub-interface in the future > >> they can. They just need to ensure that when they define the type in > >> iana-if-types it also derives from the sub-interface property, and > >> then they would automatically pick up the generic sub-interface > >> configuration leaf. This would fix this issue that having when > >> statements on IANA defined interface types isn't really robust or > >> flexible. > >> > >> Finally, adding these properties to iana-if-types.yang would be a > >> backwards compatible change. > >> > >> What are other peoples opinion's on this idea? > > > > I think that this is good idea. We have discussed adding properties > > Yes. Such use cases were actually the motivation for introducing > multiple inheritance of identities in the first place. > > > as identities before. Having them in the iana-if-types would make > > these types more useful. > > > > But this would require a non-signinficant change to > > draft-ietf-netmod-intf-ext-yang, right? We would need an update to > > iana-if-types and move the identities there. > > But then iana-if-type would diverge from the underlying IANA > registry, which would be confusing. It is IMO better to start a new > module (or a few of them) with a sound structure of interface types and > no reference to the IANA interface registry. I don't think it would diverge - all interface types would be there, but some have additional properies (which are not visible in the MIB). But the underlying registry somehow needs to be extended. /martin From nobody Tue Apr 11 04:56:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCE112946E for ; Tue, 11 Apr 2017 04:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 ikmk-hqD7mxQ for ; Tue, 11 Apr 2017 04:56:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0C612945B for ; Tue, 11 Apr 2017 04:56:06 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:f47a:c5ea:506a:7ed0] (unknown [IPv6:2001:718:1a02:1:f47a:c5ea:506a:7ed0]) by mail.nic.cz (Postfix) with ESMTPSA id 955AF608A7; Tue, 11 Apr 2017 13:56:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1491911764; bh=Aghcn6YdJ7IoYPkvaVaNgCkLxrEN4eBAldKwSdN8L8o=; h=From:Date:To; b=BaOOxYJTLi3ueov8DdoGBBQt6xdvcsJ8t0I9MqK/KI3VjZlaXMv+SBOz1SQ89O8Hw sazBhSSKt8gd6ZVhUaDhKmHcuHe0WeESioV0WgcxSMQGZ4DsBidGMJtZDPKtQ/PwWl irNGjxNcSNoEM/NmkQoJXs5ZhZS7C+grpuDquGdg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170411.133133.535844576323902109.mbj@tail-f.com> Date: Tue, 11 Apr 2017 13:56:03 +0200 Cc: Robert Wilton , netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <773bc744-f147-f854-87c1-cad0d61d1ab8@cisco.com> <20170411.121313.282585946337498966.mbj@tail-f.com> <20170411.133133.535844576323902109.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 11:56:10 -0000 > On 11 Apr 2017, at 13:31, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Robert Wilton wrote: >>>> Hi Vladimir, all, >>>>=20 >>>>=20 >>>> On 10/04/2017 17:19, Vladimir Vassilev wrote: >>>>> Hello, >>>>>=20 >>>>> On 04/06/2017 07:43 PM, Andy Bierman wrote: >>>>>>=20 >>>>>> 3) identity ethSubInterface >>>>>>=20 >>>>>> This identity is used in the encapsulation container when-stmt. >>>>>> It is not clear if this is intended as a base identity (like = identity >>>>>> sub-interface) >>>>>> An example for the encapsulation container would help clarify the >>>>>> expected usage >>>>>>=20 >>>>>> This also has 2 bases (sub-interface and l2vlan). >>>>>> Some explanation in the identity-stmt would be helpful >>>>>> (since this is a new YANG 1.1 construct) >>>>> It seems the intentended result was identity similar to >>>>> ianaift:atmSubInterface (thus the naming convention change >>>>> ethSubInterface instead of eth-sub-interface). I think it is less >>>>> confusing to name the identity with the same naming convention = used >>>>> for the rest of the identities introduced e.g. sub-interface, >>>>> loopback-internal etc. and if needed define new atm-sub-interface >>>>> based on sub-interface. I am not sure even atm users would like a >>>>> model where atmSubInterface will be the only identity of all = future >>>>> sub interface based identities not being derived from = sub-interface >>>>> because of this precedent: >>>>>=20 >>>>> augment "/if:interfaces/if:interface" { >>>>> when "derived-from(if:type, >>>>> 'ietf-if-cmn', >>>>> 'sub-interface') or >>>>> if:type =3D 'ianaift:atmSubInterface' or >>>>> if:type =3D 'ianaift:frameRelay'" { >>>>=20 >>>> My idea was that all sub-interfaces could inherit from a common >>>> identity. I don't think that this idea just applies to >>>> sub-interfaces, but other interface properties as well. E.g. >>>> sub-interface (i.e. any interface that is logically a child = interface >>>> of some parent interface, e.g. Ethernet/VLAN sub-interface, ATM >>>> sub-interface, FR sub-interface) >>>> ethernet-like (i.e. does the interface use ethernet framing). >>>> E.g. this would apply to physical Ethernet, LAG, IRB interfaces. >>>> physical (i.e. an interface that is generally instantiated due to = some >>>> physical hardware) >>>> logical? (This is harder to define, but roughly an interface that = is a >>>> software construct). >>>> there must be other generic properties as well. >>>>=20 >>>> My main aim is for future flexibility. I.e. so that if need = interface >>>> types get defined in the future they can share existing interface >>>> related configuration and state without having to redefine it. >>>> Similarly, if there are vendor specific variants of interfaces then >>>> they could also reuse the existing interface related configuration = and >>>> state without having to define vendor specific MTU leaves, etc for = the >>>> new interface type. >>>>=20 >>>> My refinement of this idea, is still to define these generic >>>> properties, but then revise iana-if-type.yang to add these common >>>> interface properties as additional base identities. >>>>=20 >>>> E.g. >>>>=20 >>>> identity interface-property-type { >>>> description >>>> "Base identity from which all interface properties are >>>> derived."; >>>> } >>>>=20 >>>>=20 >>>> identity sub-interface-like { >>>> description >>>> "The interface has sub-interface properties"; >>>> base interface-property-type; >>>> } >>>>=20 >>>> identity ethernet-like { >>>> description >>>> "The interface uses ethernet framing, e.g. has a MAC = address >>>> associated with it."; >>>> base interface-property-type; >>>> } >>>>=20 >>>> ... >>>>=20 >>>>=20 >>>> Then, for example, the IANA type for atm & l2vlan (if this is the = IANA >>>> type for an Ethernet sub-interface) would change from: >>>>=20 >>>>=20 >>>> identity atmSubInterface { >>>> base iana-interface-type; >>>> description >>>> "ATM Sub Interface."; >>>> } >>>>=20 >>>> identity l2vlan { >>>> base iana-interface-type; >>>> description >>>> "Layer 2 Virtual LAN using 802.1Q."; >>>> } >>>>=20 >>>> to: >>>>=20 >>>> identity atmSubInterface { >>>> base iana-interface-type; >>>> base sub-interface-like; >>>> description >>>> "ATM Sub Interface."; >>>> } >>>>=20 >>>> identity l2vlan { >>>> base iana-interface-type; >>>> base sub-interface-like; >>>> description >>>> "Layer 2 Virtual LAN using 802.1Q."; >>>> } >>>>=20 >>>> and hence the augment can just become: >>>>=20 >>>> augment "/if:interfaces/if:interface" { >>>> when "derived-from(if:type, 'ietf-if', 'sub-interface')" { >>>> ... >>>> } >>>>=20 >>>> If someone wants to define a new type of sub-interface in the = future >>>> they can. They just need to ensure that when they define the type = in >>>> iana-if-types it also derives from the sub-interface property, and >>>> then they would automatically pick up the generic sub-interface >>>> configuration leaf. This would fix this issue that having when >>>> statements on IANA defined interface types isn't really robust or >>>> flexible. >>>>=20 >>>> Finally, adding these properties to iana-if-types.yang would be a >>>> backwards compatible change. >>>>=20 >>>> What are other peoples opinion's on this idea? >>>=20 >>> I think that this is good idea. We have discussed adding properties >>=20 >> Yes. Such use cases were actually the motivation for introducing >> multiple inheritance of identities in the first place.=20 >>=20 >>> as identities before. Having them in the iana-if-types would make >>> these types more useful. >>>=20 >>> But this would require a non-signinficant change to >>> draft-ietf-netmod-intf-ext-yang, right? We would need an update to >>> iana-if-types and move the identities there. >>=20 >> But then iana-if-type would diverge from the underlying IANA >> registry, which would be confusing. It is IMO better to start a new >> module (or a few of them) with a sound structure of interface types = and >> no reference to the IANA interface registry. >=20 > I don't think it would diverge - all interface types would be there, > but some have additional properies (which are not visible in the > MIB). But the underlying registry somehow needs to be extended. The IANA registry is mostly rubbish - quite fundamental interface types = are missing but, on the other hand, obsolete/experimental/humorous types = are there. The plethora of Ethernet types is represented by a single = entry (moreover with a totally impossible name). Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Apr 11 06:25:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046F6129B9B for ; Tue, 11 Apr 2017 06:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 WXjhVzjzz5o4 for ; Tue, 11 Apr 2017 06:25:01 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30110.outbound.protection.outlook.com [40.107.3.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB2126BF0 for ; Tue, 11 Apr 2017 06:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EY/3VOEbGKNK1xtnzcHrkt8Dc0qbbxDsrDTOOhmqvsM=; b=UtqJHnE/QsboUS0XmvVg/gs0KtXsXZTe2wGRpnSTP38pOm2M6NExmiaMyuP0yN2EDobDAJmPy2NUyrmoTyE7AOKhVDEJSuC2n6aFcs+9JtfK6dcJWS//vDA6vqW9eUr+YPwengJT+YYqkglpA4sIA9oKxh3qIHsxQzEU0J2+Qbs= Received: from HE1PR07MB0843.eurprd07.prod.outlook.com (10.162.24.16) by HE1PR07MB0844.eurprd07.prod.outlook.com (10.162.24.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 11 Apr 2017 13:24:58 +0000 Received: from HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) by HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) with mapi id 15.01.1034.008; Tue, 11 Apr 2017 13:24:58 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: pyang and YANG 1.1 submodule scoping rules Thread-Index: AdKyw8myEAn/hT2MQVWwASof+0F4PQ== Date: Tue, 11 Apr 2017 13:24:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.12] x-microsoft-exchange-diagnostics: 1; HE1PR07MB0844; 7:v9odJeS17Ubc0PE8P4eSpJ7PJif7DfwrtsacvEfPDaog0EmbWK5nOvz2ZTevHHdS9ciQStTket66R+JxDpr8N/uY3fmHGBDNJHTHF0U3TOjDLi25vsT7CJSj6HwGgL0rGVP/O8dgSHVL9yIT51Jtpx9tfWsiKv8AzufrHYXz7CxltWL3fv2JJq7z5xXTrKqcODaQim5Zp+qFETXJeU6I6ZWooPsu8QEma+iqQtr5f/ly3NqCiiCmpK+XcxaLedxFZZEEmxFiMKUqxyMh+jk+No72dzMRwH/FcvtgSm3Y0NU7Gi4rOgjeheTgk71PdelvqDuDpgtiWbP4nwza41/+9A== x-ms-office365-filtering-correlation-id: ce416c97-9fd1-49da-b2d4-08d480de26c7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:HE1PR07MB0844; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0844; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(39400400002)(53754006)(53936002)(2351001)(122556002)(2501003)(3280700002)(2906002)(3660700001)(7696004)(5660300001)(6916009)(33656002)(8936002)(81166006)(8676002)(1730700003)(50986999)(54356999)(74316002)(558084003)(5630700001)(5640700003)(7736002)(99286003)(55016002)(54896002)(6306002)(6436002)(2900100001)(9686003)(102836003)(6506006)(790700001)(6116002)(77096006)(97736004)(3846002)(66066001)(189998001)(38730400002)(110136004)(25786009)(86362001)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0844; H:HE1PR07MB0843.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB08437B9251658159397B68BA9B000HE1PR07MB0843eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2017 13:24:58.5257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0844 Archived-At: Subject: [netmod] pyang and YANG 1.1 submodule scoping rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:25:03 -0000 --_000_HE1PR07MB08437B9251658159397B68BA9B000HE1PR07MB0843eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Pyang 1.7 mentions that it was updated for YANG 1.1 except for the new subm= odule scoping rules. Just checking the plans/status of support for those r= ules. Do other common tools support those new submodule scoping rules already ? Regards, Jason --_000_HE1PR07MB08437B9251658159397B68BA9B000HE1PR07MB0843eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Pyang 1.7 mentions that it was updated for YANG 1.1 = except for the new submodule scoping rules.  Just checking the plans/s= tatus of support for those rules.

 

Do other common tools support those new submodule sc= oping rules already ?

 

Regards,

Jason

--_000_HE1PR07MB08437B9251658159397B68BA9B000HE1PR07MB0843eurp_-- From nobody Tue Apr 11 06:30:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E0129BAF for ; Tue, 11 Apr 2017 06:30:05 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eplf1wNk9Dcg for ; Tue, 11 Apr 2017 06:30:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 87B63129BB3 for ; Tue, 11 Apr 2017 06:30:01 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 7B2871AE0351; Tue, 11 Apr 2017 15:30:00 +0200 (CEST) Date: Tue, 11 Apr 2017 15:30:10 +0200 (CEST) Message-Id: <20170411.153010.309426705798953533.mbj@tail-f.com> To: jason.sterne@nokia.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] pyang and YANG 1.1 submodule scoping rules X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 13:30:05 -0000 Hi, This is probably not the right place to discuss these things... ...but to answer your question there is currently no plan (time) for adding this (aka "help wanted"). /martin "Sterne, Jason (Nokia - CA/Ottawa)" wrote: > Hi all, > > Pyang 1.7 mentions that it was updated for YANG 1.1 except for the new > submodule scoping rules. Just checking the plans/status of support > for those rules. > > Do other common tools support those new submodule scoping rules > already ? > > Regards, > Jason From nobody Tue Apr 11 20:43:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1682C1293FD for ; Tue, 11 Apr 2017 20:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 gp4qyLgBob_c for ; Tue, 11 Apr 2017 20:43:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0130.outbound.protection.outlook.com [104.47.2.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A846128B88 for ; Tue, 11 Apr 2017 20:43:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2wgAGLgGNTcT89VJRQE0LB3JUNjJw81OlSYl6byVBhM=; b=MTxiCfVnmYyNIrRMwi0iDlkIie4MOd8icMZZlpJsBa0J+7HiynXBhkDMwTQfOv7jsrSJEgPkTzd0lvrJ7timoCW0N4JuSV0pe9mx6unu9rcpXMyq0kJfvuVZD7TbNaOetpBqULx/7TOfwVaxbV5FZ9jS+4dYc2uC2/uy8RMq/3Q= Received: from HE1PR07MB0843.eurprd07.prod.outlook.com (10.162.24.16) by HE1PR07MB0842.eurprd07.prod.outlook.com (10.162.24.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 03:43:15 +0000 Received: from HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) by HE1PR07MB0843.eurprd07.prod.outlook.com ([10.162.24.16]) with mapi id 15.01.1034.008; Wed, 12 Apr 2017 03:43:14 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: Robert Wilton , "netmod@ietf.org" Thread-Topic: [netmod] choice statements and trim vs explicit default handling Thread-Index: AdKv6w7/8xX3pfT5TQy0uN4Yo4P2TwB8HnoAAA/IrLA= Date: Wed, 12 Apr 2017 03:43:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.20.12] x-microsoft-exchange-diagnostics: 1; HE1PR07MB0842; 7:Ll2EHDvFmMDl2CfmbfVkUh+oiZ+/HGNGU5HZHPMCfkt5RaDec1cJwheDXqIGhsg1BaYd/Ct4CqFlqL+VO94+qH/WfhB7isjeWDIA12W8VpkG2M1Uf2TPZjqnEImPuWHWB9BhRckh0W8JD4Qd6NcVKYogEGqJaB3awvYUfZAABDJvTmYhhmsdkW1L7ig1Ox3JXY5LS00L8A8htpszJbiu+K+d7R4EyP/SlcI/3LYcydV1UC0jV/R0QiHQJ7iIeYrUG61J1IEouLqHXdEM7OJJIs8w2fu08xNYVSB2Wc40sCDhkh2UCo4ZE/3frypEZQCirxZNv6TGeko1475bGPogmg== x-ms-office365-filtering-correlation-id: 3a26a054-2b8b-4ec2-465c-08d481560ce6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:HE1PR07MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:HE1PR07MB0842; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0842; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39850400002)(39410400002)(39840400002)(39400400002)(39450400003)(24454002)(53754006)(50986999)(53936002)(8676002)(8936002)(3280700002)(81166006)(606005)(76176999)(9686003)(2950100002)(33656002)(189998001)(54896002)(2900100001)(55016002)(54356999)(236005)(6306002)(229853002)(6436002)(7906003)(66066001)(7736002)(3660700001)(2501003)(6506006)(5660300001)(7696004)(102836003)(790700001)(6116002)(53546009)(3846002)(25786009)(2906002)(122556002)(74316002)(6246003)(99286003)(86362001)(38730400002)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB0842; H:HE1PR07MB0843.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB084391FD4DD8667A311E2D069B030HE1PR07MB0843eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2017 03:43:14.6658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0842 Archived-At: Subject: Re: [netmod] choice statements and trim vs explicit default handling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 03:43:21 -0000 --_000_HE1PR07MB084391FD4DD8667A311E2D069B030HE1PR07MB0843eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Rob. You may be right here but it isn't what I would have expected. You're sayi= ng that any existing config in case bb is removed by the *act* of writing t= o a leaf of case aa, even if that write (setting some-bool to its default v= alue) results in no config existing in case aa (for 'trim' servers). If I had a must statement for leaf some-num like this: must ". !=3D 55"; and a client sets some-num to 55 I suppose that would clear out (delete) an= y previous config of some-bool, even though the validate/commit later would= fail. After the failure it is "too late" and some-bool would have already= lost its value. So case bb would be 'selected' even though it is a config= that will fail validation. You mention "would be ignored". That is true for the particular model I sh= ow below, but default values for child nodes under a case don't require a d= efault for the overall choice in order to be relevant. If I had other leaf= s in those cases, then the defaults could be used/relevant even without a d= efault for the choice (when another leaf of the same case is configured). = >From 7.9.3. : Default values for child nodes under a case are only used if one of the nodes under that case is present or if that case is the default case. Rgds, Jason From: Robert Wilton [mailto:rwilton@cisco.com] Sent: Monday, April 10, 2017 5:19 To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf= .org Subject: Re: [netmod] choice statements and trim vs explicit default handli= ng Hi Jason, Your default statement in your YANG snippet below would be ignored, as per = section 7.9.3 of RFC 7950. But, if you changed your YANG to this: choice foo { default aa; case aa { leaf some-bool { type Boolean; default "false"; } { case bb { leaf some-num { type int32; } } } Then answering both (A) and (B): I would assume that setting "some-bool" to= "true" or "false" would cause "bb" to be deleted regardless of what defaul= t mode the server was using. If neither some-bool or some-num had been set= to an explicit value then some-bool semantically exists with value "false"= due to the two default statements. I might be wrong, but I have always assumed that the with-defaults extensio= n is really concerned with the presentation/encoding of default values, and= isn't intended to change the underlying semantics of YANG's handling of de= fault values. Thanks, Rob On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottawa) wrote: Hi all, When a server operates in 'trim' mode (rfc6243), setting a leaf to its defa= ult value removes it from the config (i.e. it is indistinguishable from the= case where that leaf was never configured or the case where that leaf was = deleted/removed). (A) Does setting a leaf in one case of a choice to its default value (in a 'tri= m' mode server) cause leafs in other cases to be implicitly deleted ? I as= sume not. For example: choice foo { case aa { leaf some-bool { type Boolean; default "false"; } { case bb { leaf some-num { type int32; } } } If some-num is currently set to 50, and then an edit-config sets some-bool = to "false", does that clear the some-num leaf ? (i.e. does it select case aa ?) RFC 7950 says: "the creation of a node from one case implicitly deletes all= nodes from all other cases". RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim serv= er) doesn't exist. (B) Now how about if the server operates in 'explicit' mode ? Does setting som= e-bool to "false" clear some-num ? I assume it does (but it just seems a l= ittle funny that the behavior on this changes between trim and explicit ser= vers). Regards, Jason _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_HE1PR07MB084391FD4DD8667A311E2D069B030HE1PR07MB0843eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Rob.

 

You may be right he= re but it isn’t what I would have expected.  You’re saying= that any existing config in case bb is removed by the *act* of writing to a leaf of case aa, even if that write (setting some-bool = to its default value) results in no config existing in case aa (for ‘= trim’ servers).

 

If I had a must sta= tement for leaf some-num like this:

   &= nbsp;            mus= t “. !=3D 55”;

and a client sets s= ome-num to 55 I suppose that would clear out (delete) any previous config o= f some-bool, even though the validate/commit later would fail.  After = the failure it is “too late” and some-bool would have already lost its value.  So case bb would be ‘select= ed’ even though it is a config that will fail validation.

 

You mention “= would be ignored”.  That is true for the particular model I show= below, but default values for child nodes under a case don’t require= a default for the overall choice in order to be relevant.  If I had other leafs in those cases, then the defaults could be used/relev= ant even without a default for the choice (when another leaf of the same ca= se is configured).  From 7.9.3. :

 

    = Default values for child nodes under a case are only used if one of

    =    the nodes under that case is present or if that case is t= he default

    =    case.

 

Rgds,

Jason

 

 

From:= Robert Wilton [mailto:rwilton@cisco.com]
Sent: Monday, April 10, 2017 5:19
To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>= ; netmod@ietf.org
Subject: Re: [netmod] choice statements and trim vs explicit default= handling

 

Hi Jason,

Your default statement in your YANG snippet below would be ignored, as p= er section 7.9.3 of RFC 7950.

But, if you changed your YANG to this:

c= hoice foo {

  d= efault aa;

&= nbsp; case aa {

&= nbsp;   leaf some-bool { type Boolean; default “false”= ;; }

&= nbsp; {

&= nbsp; case bb {

&= nbsp;   leaf some-num { type int32; }

&= nbsp; }

}


Then answering both (A) and (B): I would assume that setting "s= ome-bool" to "true" or "false" would cause "b= b" to be deleted regardless of what default mode the server was using.=   If neither some-bool or some-num had been set to an explicit value t= hen some-bool semantically exists with value "false" due to the two = default statements.

I might be wrong, but I have always assumed that the with-defaults extensio= n is really concerned with the presentation/encoding of default values, and= isn't intended to change the underlying semantics of YANG's handling of de= fault values.

Thanks,
Rob

On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottaw= a) wrote:

Hi all,

 

When a server operates in ‘trim’ mode (rfc6243), s= etting a leaf to its default value removes it from the config (i.e. it is i= ndistinguishable from the case where that leaf was never configured or the case where that leaf was deleted/removed).

 

(A)

Does setting a leaf in one case of a choice to its default val= ue (in a ‘trim’ mode server) cause leafs in other cases to be i= mplicitly deleted ?  I assume not.

 

For example:

 

choice foo {

  case aa {

    leaf some-bool { type Boolean; default R= 20;false”; }

  {

  case bb {

    leaf some-num { type int32; }

  }

}

 

If some-num is currently set to 50, and then an edit-config se= ts some-bool to “false”, does that clear the some-num leaf ?

(i.e. does it select case aa ?)

 

RFC 7950 says: “the creation of a node from one case imp= licitly deletes all nodes from all other cases”.

RFC 6243 section 2.2.3 describes that a leaf set to default (i= n a trim server) doesn’t exist.

 

(B)

Now how about if the server operates in ‘explicit’= mode ?  Does setting some-bool to “false” clear some-num = ?  I assume it does (but it just seems a little funny that the behavio= r on this changes between trim and explicit servers).

 

 

Regards,

Jason

 

 

 

 

 




_______________________________________________
netmod mailing list
netmod@ietf.org

https://www.i=
etf.org/mailman/listinfo/netmod

 

--_000_HE1PR07MB084391FD4DD8667A311E2D069B030HE1PR07MB0843eurp_-- From nobody Wed Apr 12 05:53:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0C129C3F; Wed, 12 Apr 2017 05:53:14 -0700 (PDT) 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] 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 0sDNANYMK9YT; Wed, 12 Apr 2017 05:53:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C781012945B; Wed, 12 Apr 2017 05:53:11 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id EDB19182000E; Wed, 12 Apr 2017 14:53:04 +0200 (CEST) From: Ladislav Lhotka To: Robert Wilton , Kent Watsen , "netmod\@ietf.org" Cc: "netmod-chairs\@ietf.org" In-Reply-To: <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> Date: Wed, 12 Apr 2017 14:53:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 12:53:14 -0000 Robert Wilton writes: > Yes/support. But with the condition that I would still like the draft > to define a basic common subset of markdown fields/annotations that > implementations would be expected to support. For clarity, I'm not > suggesting that the draft should define a new markdown language, I think > that it would be better to use an existing markdown language, but > perhaps simplified. In my view, this needs to remain purely optional, so implementations won't be expected to support anything. It should be perfectly fine to leave description texts unprocessed, or process only selected constructs. > > I want to avoid the scenario where each group of YANG modelers could > decide to use a different incompatible variant of text/markdown, and > hence generic tools would not be able to reliably render the markup for > a generic YANG module. On the other hand, particular markup conventions might be dictated by external circumstances. For example, for modules hosted at GitHub, the GFM variant of text/markdown looks like a natural choice but elsewhere it can be something different. William also suggested that certain YANG-specific constructs may also be introduced. > > Care would need to be taken with which variant of the Markdown language > is chosen as a base (RFC 7764 may be of use) . E.g. the github markup > language has been previously suggested, but the specification document > for that variant is long (approx 120 pages). RFC 7763 also notes that markdown itself by design has no concept of validity, so I think it is appropriate to take it easy and avoid overspecifying things. I guess the key point here is "lighweight markup": if and implementation can make use of it, then fine, but module readers should have little difficulty if not. Thanks, Lada > > Thanks, > Rob > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: >> As the author: yes/support. >> >> Two changes seemed to have support in IETF 98 audience: >> >> 1. Apart from text/plain, the media type SHOULD be text/markdown >> (variants permitted). >> >> 2. The "text-media-type" extension can appear anywhere in a (sub)module, >> and will be scoped to the parent statement and its substaments (unless >> overriden). >> >> Lada >> >> Kent Watsen writes: >> >>> All, >>> >>> This is start of a two-week poll on making the following draft a >>> NETMOD working group document: >>> >>> draft-lhotka-netmod-yang-markup-00 >>> >>> Please send email to the list indicating "yes/support" or "no/do not >>> support". If indicating no, please state your reservations with the >>> document. If yes, please also feel free to provide comments you'd >>> like to see addressed once the document is a WG document. >>> >>> Thank you, >>> NETMOD WG Chairs >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 12 06:02:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45C129AE8; Wed, 12 Apr 2017 06:02:20 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 8ZLP_y_wGulG; Wed, 12 Apr 2017 06:02:17 -0700 (PDT) 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 528A5127337; Wed, 12 Apr 2017 06:02:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5794F6D7; Wed, 12 Apr 2017 15:02:04 +0200 (CEST) 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 woYHOnJph_aP; Wed, 12 Apr 2017 15:02:01 +0200 (CEST) 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; Wed, 12 Apr 2017 15:02:04 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 326452004E; Wed, 12 Apr 2017 15:02:04 +0200 (CEST) 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 cq2CFYDXT2tq; Wed, 12 Apr 2017 15:02:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CD9E2004A; Wed, 12 Apr 2017 15:02:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4561F3F1B40C; Wed, 12 Apr 2017 15:02:07 +0200 (CEST) Date: Wed, 12 Apr 2017 15:02:07 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Message-ID: <20170412130207.GA83817@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:02:20 -0000 I think it is crucial that descriptions etc. remain human readable using plain text readers. Having to run a renderer to make sense out of descriptions etc. would be a big failure and things are even worse if modules use different dialects all over the place. I believe there is way more important work to get done than this (and I fear endless discussions about which adapted subsets of markdown or (whatever comes next) to use). I do not object this work, but I also do not support it at this point in time. /js On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > Robert Wilton writes: > > > Yes/support. But with the condition that I would still like the draft > > to define a basic common subset of markdown fields/annotations that > > implementations would be expected to support. For clarity, I'm not > > suggesting that the draft should define a new markdown language, I think > > that it would be better to use an existing markdown language, but > > perhaps simplified. > > In my view, this needs to remain purely optional, so implementations > won't be expected to support anything. It should be perfectly fine to > leave description texts unprocessed, or process only selected > constructs. > > > > > I want to avoid the scenario where each group of YANG modelers could > > decide to use a different incompatible variant of text/markdown, and > > hence generic tools would not be able to reliably render the markup for > > a generic YANG module. > > On the other hand, particular markup conventions might be dictated by > external circumstances. For example, for modules hosted at GitHub, the > GFM variant of text/markdown looks like a natural choice but elsewhere > it can be something different. William also suggested that certain > YANG-specific constructs may also be introduced. > > > > > Care would need to be taken with which variant of the Markdown language > > is chosen as a base (RFC 7764 may be of use) . E.g. the github markup > > language has been previously suggested, but the specification document > > for that variant is long (approx 120 pages). > > RFC 7763 also notes that markdown itself by design has no concept of > validity, so I think it is appropriate to take it easy and avoid > overspecifying things. > > I guess the key point here is "lighweight markup": if and implementation > can make use of it, then fine, but module readers should have little > difficulty if not. > > Thanks, Lada > > > > > Thanks, > > Rob > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > >> As the author: yes/support. > >> > >> Two changes seemed to have support in IETF 98 audience: > >> > >> 1. Apart from text/plain, the media type SHOULD be text/markdown > >> (variants permitted). > >> > >> 2. The "text-media-type" extension can appear anywhere in a (sub)module, > >> and will be scoped to the parent statement and its substaments (unless > >> overriden). > >> > >> Lada > >> > >> Kent Watsen writes: > >> > >>> All, > >>> > >>> This is start of a two-week poll on making the following draft a > >>> NETMOD working group document: > >>> > >>> draft-lhotka-netmod-yang-markup-00 > >>> > >>> Please send email to the list indicating "yes/support" or "no/do not > >>> support". If indicating no, please state your reservations with the > >>> document. If yes, please also feel free to provide comments you'd > >>> like to see addressed once the document is a WG document. > >>> > >>> Thank you, > >>> NETMOD WG Chairs > >>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 12 06:28:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FBB1294A6 for ; Wed, 12 Apr 2017 06:28:30 -0700 (PDT) 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] 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 E2417UjMrsOB for ; Wed, 12 Apr 2017 06:28:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 073AA1294B3 for ; Wed, 12 Apr 2017 06:28:28 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 684F9182000E; Wed, 12 Apr 2017 15:28:21 +0200 (CEST) From: Ladislav Lhotka To: "Sterne\, Jason \(Nokia - CA\/Ottawa\)" , Robert Wilton , "netmod\@ietf.org" In-Reply-To: References: Date: Wed, 12 Apr 2017 15:28:25 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] choice statements and trim vs explicit default handling X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 13:28:31 -0000 "Sterne, Jason (Nokia - CA/Ottawa)" writes: > Thanks Rob. > > You may be right here but it isn't what I would have expected. You're saying that any existing config in case bb is removed by the *act* of writing to a leaf of case aa, even if that write (setting some-bool to its default value) results in no config existing in case aa (for 'trim' servers). > > If I had a must statement for leaf some-num like this: must ". != 55"; > and a client sets some-num to 55 I suppose that would clear out > (delete) any previous config of some-bool, even though the > validate/commit later would fail. After the failure it is "too late" > and some-bool would have already lost its value. So case bb would be > 'selected' even though it is a config that will fail validation. Yes, but note that the situation would be different if you used when ". != 55"; for "some-num" instead - setting "some-num" to 55 silently discards this case and the default value for "some-bool" takes effect. Similar interactions between "when" and default values (and auto-deletion) make implementations brittle and prone to race conditions. It is not difficult to understand why some people (mainly in XML circles) always insisted that modifying the data, e.g. by adding defaults, while validating the same data was a terrible idea. Lada > > You mention "would be ignored". That is true for the particular model I show below, but default values for child nodes under a case don't require a default for the overall choice in order to be relevant. If I had other leafs in those cases, then the defaults could be used/relevant even without a default for the choice (when another leaf of the same case is configured). >From 7.9.3. : > > Default values for child nodes under a case are only used if one of > the nodes under that case is present or if that case is the default > case. > > Rgds, > Jason > > > From: Robert Wilton [mailto:rwilton@cisco.com] > Sent: Monday, April 10, 2017 5:19 > To: Sterne, Jason (Nokia - CA/Ottawa) ; netmod@ietf.org > Subject: Re: [netmod] choice statements and trim vs explicit default handling > > > Hi Jason, > > Your default statement in your YANG snippet below would be ignored, as per section 7.9.3 of RFC 7950. > > But, if you changed your YANG to this: > choice foo { > default aa; > > case aa { > leaf some-bool { type Boolean; default "false"; } > { > case bb { > leaf some-num { type int32; } > } > } > > > Then answering both (A) and (B): I would assume that setting "some-bool" to "true" or "false" would cause "bb" to be deleted regardless of what default mode the server was using. If neither some-bool or some-num had been set to an explicit value then some-bool semantically exists with value "false" due to the two default statements. > > I might be wrong, but I have always assumed that the with-defaults extension is really concerned with the presentation/encoding of default values, and isn't intended to change the underlying semantics of YANG's handling of default values. > > Thanks, > Rob > > On 07/04/2017 23:50, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > When a server operates in 'trim' mode (rfc6243), setting a leaf to its default value removes it from the config (i.e. it is indistinguishable from the case where that leaf was never configured or the case where that leaf was deleted/removed). > > (A) > Does setting a leaf in one case of a choice to its default value (in a 'trim' mode server) cause leafs in other cases to be implicitly deleted ? I assume not. > > For example: > > choice foo { > case aa { > leaf some-bool { type Boolean; default "false"; } > { > case bb { > leaf some-num { type int32; } > } > } > > If some-num is currently set to 50, and then an edit-config sets some-bool to "false", does that clear the some-num leaf ? > (i.e. does it select case aa ?) > > RFC 7950 says: "the creation of a node from one case implicitly deletes all nodes from all other cases". > RFC 6243 section 2.2.3 describes that a leaf set to default (in a trim server) doesn't exist. > > (B) > Now how about if the server operates in 'explicit' mode ? Does setting some-bool to "false" clear some-num ? I assume it does (but it just seems a little funny that the behavior on this changes between trim and explicit servers). > > > Regards, > Jason > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 12 09:44:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91890129540 for ; Wed, 12 Apr 2017 09:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACknB2zXj2v0 for ; Wed, 12 Apr 2017 09:44:31 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8354C12EAF3 for ; Wed, 12 Apr 2017 09:44:30 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w64so92687577wma.0 for ; Wed, 12 Apr 2017 09:44:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=wve9J+QoxEwJcdzYw8cuJ6lUyxzaZFOA6OqmocPny0M=; b=tSI3WavvW30QFW8veS0lo8xgLmg++IcpQHdHmW2JmCH6JpxFg0tWxZmVYv/mEcupeh NiB1c+Za0wNQPe6C2+4FC1T9t0XaoPXZEkmIwn7yZ/tk8mc58drxO9If2wZbl/ukFUE+ Yh/ZtXYOgzhYfYmrphVg9iWnXLicx6J9//rbFmJXtbCtO8xhBcJMRuojDeHhiIy6hfpG zPY9gy8xfJJdQhcQ+/Ii6BxzftxK81C6V/BiW0etEj2gOw4j+5FzgGAtpIblAJSA0E6Y 0nsGRKuVNuAKVd7a2c7ba1Bz6OO0jWErSnijsiXMAHmT+rKidgQxquLhBxQmIqgwJ8pX FyQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wve9J+QoxEwJcdzYw8cuJ6lUyxzaZFOA6OqmocPny0M=; b=bjeKVlRIuWvp1ysC/oE/FlMeEwM4x1FUxksNW1bCgG0rcaVe0h+YzoAPxr+Af+5W+R hX+jGacznio2N6wMLyCpsVqjTYS5MrZ706STHwP/tXUJGtoop+BmzTVxrPlX2EEGqx00 wUbweg9mBJsIwiP7JGMoO5r/biC6fVMNhluCiWlvPtBUrc/3qV0VeeFv1U24bC2+nbiW Oeytd3zviHfnaSRGFzS0Fi3GwAhOG9hv1o7B45W10lWWaOSdDLb313BgwElq4qBZYe2H TsxHhtBDgrqb79j70LE6HlxMXDFu2XOxitlqAVeArK0cRqX7raTRxjHDpl4+oXgMbC1S tPaw== X-Gm-Message-State: AN3rC/7+pTfwlR0A+JcMUc5FIWn2V1PuBJi/4JxvurIqAw9BKKtbS/gs8XhbAYu9mvECm9ppfPaA4YBeplKTUw== X-Received: by 10.28.143.135 with SMTP id r129mr3621076wmd.54.1492015469047; Wed, 12 Apr 2017 09:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Wed, 12 Apr 2017 09:44:28 -0700 (PDT) In-Reply-To: <20170412130207.GA83817@elstar.local> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> From: Andy Bierman Date: Wed, 12 Apr 2017 09:44:28 -0700 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Type: multipart/alternative; boundary=001a1145b59e084bc1054cfaece3 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 16:44:34 -0000 --001a1145b59e084bc1054cfaece3 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I think it is crucial that descriptions etc. remain human readable > using plain text readers. Having to run a renderer to make sense out > of descriptions etc. would be a big failure and things are even worse > if modules use different dialects all over the place. > > I believe there is way more important work to get done than this (and > I fear endless discussions about which adapted subsets of markdown or > (whatever comes next) to use). I do not object this work, but I also > do not support it at this point in time. > > +1 IMO this makes YANG less readable, especially without any agreement on the specific markup supported. A YANG module should be readable by humans without any special tools required. > /js > > Andy > On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > Robert Wilton writes: > > > > > Yes/support. But with the condition that I would still like the draft > > > to define a basic common subset of markdown fields/annotations that > > > implementations would be expected to support. For clarity, I'm not > > > suggesting that the draft should define a new markdown language, I > think > > > that it would be better to use an existing markdown language, but > > > perhaps simplified. > > > > In my view, this needs to remain purely optional, so implementations > > won't be expected to support anything. It should be perfectly fine to > > leave description texts unprocessed, or process only selected > > constructs. > > > > > > > > I want to avoid the scenario where each group of YANG modelers could > > > decide to use a different incompatible variant of text/markdown, and > > > hence generic tools would not be able to reliably render the markup for > > > a generic YANG module. > > > > On the other hand, particular markup conventions might be dictated by > > external circumstances. For example, for modules hosted at GitHub, the > > GFM variant of text/markdown looks like a natural choice but elsewhere > > it can be something different. William also suggested that certain > > YANG-specific constructs may also be introduced. > > > > > > > > Care would need to be taken with which variant of the Markdown language > > > is chosen as a base (RFC 7764 may be of use) . E.g. the github markup > > > language has been previously suggested, but the specification document > > > for that variant is long (approx 120 pages). > > > > RFC 7763 also notes that markdown itself by design has no concept of > > validity, so I think it is appropriate to take it easy and avoid > > overspecifying things. > > > > I guess the key point here is "lighweight markup": if and implementation > > can make use of it, then fine, but module readers should have little > > difficulty if not. > > > > Thanks, Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > > >> As the author: yes/support. > > >> > > >> Two changes seemed to have support in IETF 98 audience: > > >> > > >> 1. Apart from text/plain, the media type SHOULD be text/markdown > > >> (variants permitted). > > >> > > >> 2. The "text-media-type" extension can appear anywhere in a > (sub)module, > > >> and will be scoped to the parent statement and its substaments (unless > > >> overriden). > > >> > > >> Lada > > >> > > >> Kent Watsen writes: > > >> > > >>> All, > > >>> > > >>> This is start of a two-week poll on making the following draft a > > >>> NETMOD working group document: > > >>> > > >>> draft-lhotka-netmod-yang-markup-00 > > >>> > > >>> Please send email to the list indicating "yes/support" or "no/do not > > >>> support". If indicating no, please state your reservations with the > > >>> document. If yes, please also feel free to provide comments you'd > > >>> like to see addressed once the document is a WG document. > > >>> > > >>> Thank you, > > >>> NETMOD WG Chairs > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1145b59e084bc1054cfaece3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
I think it is crucial that descriptions etc. remain = human readable
using plain text readers. Having to run a renderer to make sense out
of descriptions etc. would be a big failure and things are even worse
if modules use different dialects all over the place.

I believe there is way more important work to get done than this (and
I fear endless discussions about which adapted subsets of markdown or
(whatever comes next) to use). I do not object this work, but I also
do not support it at this point in time.


+1

IMO this m= akes YANG less readable, especially without any agreement
on the = specific markup supported. A YANG module should be readable by humans
=
without any special tools required.

=C2=A0
/js


Andy
=C2=A0
On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote:
> Robert Wilton <rwilton@cisco.c= om> writes:
>
> > Yes/support.=C2=A0 But with the condition that I would still like= the draft
> > to define a basic common subset of markdown fields/annotations th= at
> > implementations would be expected to support.=C2=A0 For clarity, = I'm not
> > suggesting that the draft should define a new markdown language, = I think
> > that it would be better to use an existing markdown language, but=
> > perhaps simplified.
>
> In my view, this needs to remain purely optional, so implementations > won't be expected to support anything. It should be perfectly fine= to
> leave description texts unprocessed, or process only selected
> constructs.
>
> >
> > I want to avoid the scenario where each group of YANG modelers co= uld
> > decide to use a different incompatible variant of text/markdown, = and
> > hence generic tools would not be able to reliably render the mark= up for
> > a generic YANG module.
>
> On the other hand, particular markup conventions might be dictated by<= br> > external circumstances. For example, for modules hosted at GitHub, the=
> GFM variant of text/markdown looks like a natural choice but elsewhere=
> it can be something different. William also suggested that certain
> YANG-specific constructs may also be introduced.
>
> >
> > Care would need to be taken with which variant of the Markdown la= nguage
> > is chosen as a base (RFC 7764 may be of use) .=C2=A0 E.g. the git= hub markup
> > language has been previously suggested, but the specification doc= ument
> > for that variant is long (approx 120 pages).
>
> RFC 7763 also notes that markdown itself by design has no concept of > validity, so I think it is appropriate to take it easy and avoid
> overspecifying things.
>
> I guess the key point here is "lighweight markup": if and im= plementation
> can make use of it, then fine, but module readers should have little > difficulty if not.
>
> Thanks, Lada
>
> >
> > Thanks,
> > Rob
> >
> >
> > On 10/04/2017 12:45, Ladislav Lhotka wrote:
> >> As the author: yes/support.
> >>
> >> Two changes seemed to have support in IETF 98 audience:
> >>
> >> 1. Apart from text/plain, the media type SHOULD be text/markd= own
> >> (variants permitted).
> >>
> >> 2. The "text-media-type" extension can appear anywh= ere in a (sub)module,
> >> and will be scoped to the parent statement and its substament= s (unless
> >> overriden).
> >>
> >> Lada
> >>
> >> Kent Watsen <kwatse= n@juniper.net> writes:
> >>
> >>> All,
> >>>
> >>> This is start of a two-week poll on making the following = draft a
> >>> NETMOD working group document:
> >>>
> >>>=C2=A0 =C2=A0 draft-lhotka-netmod-yang-markup-00
> >>>
> >>> Please send email to the list indicating "yes/suppor= t" or "no/do not
> >>> support".=C2=A0 If indicating no, please state your = reservations with the
> >>> document.=C2=A0 If yes, please also feel free to provide = comments you'd
> >>> like to see addressed once the document is a WG document.=
> >>>
> >>> Thank you,
> >>> NETMOD WG Chairs
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/list= info/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a1145b59e084bc1054cfaece3-- From nobody Wed Apr 12 10:39:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C520612960D; Wed, 12 Apr 2017 10:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 9pS0rhLh-LRp; Wed, 12 Apr 2017 10:39:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38625129AA4; Wed, 12 Apr 2017 10:39:15 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:a1b0:3cb3:83a:a8fb] (unknown [IPv6:2a01:5e0:29:ffff:a1b0:3cb3:83a:a8fb]) by mail.nic.cz (Postfix) with ESMTPSA id B579660952; Wed, 12 Apr 2017 19:39:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492018752; bh=wYcktvh8CdTBcyymxdVOj2VPl2+w7EnUhQGFPXgXr5w=; h=From:Date:To; b=iku7Lo1JNu3M3B0amSrjuDlgDBxXEQbIt5DTKZdknT/WB1H3go/StMfjLYbBeBKAB hkJdLJQ0zDTe7nPWPp539pBEvajN3Navt1XQHY/udtJnwbtAi2xfQ2CaS83c31woo/ yt8El6sUbgJjyNBPjXCGAa4E5Nb/QAzAzYEY3Ifw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 12 Apr 2017 19:39:11 +0200 Cc: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:39:20 -0000 > On 12 Apr 2017, at 18:44, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder = wrote: > I think it is crucial that descriptions etc. remain human readable > using plain text readers. Having to run a renderer to make sense out > of descriptions etc. would be a big failure and things are even worse > if modules use different dialects all over the place. >=20 > I believe there is way more important work to get done than this (and > I fear endless discussions about which adapted subsets of markdown or > (whatever comes next) to use). I do not object this work, but I also > do not support it at this point in time. >=20 >=20 > +1 >=20 > IMO this makes YANG less readable, especially without any agreement > on the specific markup supported. A YANG module should be readable by = humans > without any special tools required. Why do you think that unprocessed *lightweight* markup such as markdown = is not readable by humans? Note that everybody can use it even now = without further ado, so this document only allows module authors who = want to do so to provide explicit info about the format. As the draft also tries to explain, some trivial markup is already = commonly used in IETF modules (for example, bulleted lists) and = inconsistent indentation rules make it difficult for applications to = properly format such texts. Lada=20 >=20 > =20 > /js >=20 >=20 > Andy > =20 > On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > Robert Wilton writes: > > > > > Yes/support. But with the condition that I would still like the = draft > > > to define a basic common subset of markdown fields/annotations = that > > > implementations would be expected to support. For clarity, I'm = not > > > suggesting that the draft should define a new markdown language, I = think > > > that it would be better to use an existing markdown language, but > > > perhaps simplified. > > > > In my view, this needs to remain purely optional, so implementations > > won't be expected to support anything. It should be perfectly fine = to > > leave description texts unprocessed, or process only selected > > constructs. > > > > > > > > I want to avoid the scenario where each group of YANG modelers = could > > > decide to use a different incompatible variant of text/markdown, = and > > > hence generic tools would not be able to reliably render the = markup for > > > a generic YANG module. > > > > On the other hand, particular markup conventions might be dictated = by > > external circumstances. For example, for modules hosted at GitHub, = the > > GFM variant of text/markdown looks like a natural choice but = elsewhere > > it can be something different. William also suggested that certain > > YANG-specific constructs may also be introduced. > > > > > > > > Care would need to be taken with which variant of the Markdown = language > > > is chosen as a base (RFC 7764 may be of use) . E.g. the github = markup > > > language has been previously suggested, but the specification = document > > > for that variant is long (approx 120 pages). > > > > RFC 7763 also notes that markdown itself by design has no concept of > > validity, so I think it is appropriate to take it easy and avoid > > overspecifying things. > > > > I guess the key point here is "lighweight markup": if and = implementation > > can make use of it, then fine, but module readers should have little > > difficulty if not. > > > > Thanks, Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > > >> As the author: yes/support. > > >> > > >> Two changes seemed to have support in IETF 98 audience: > > >> > > >> 1. Apart from text/plain, the media type SHOULD be text/markdown > > >> (variants permitted). > > >> > > >> 2. The "text-media-type" extension can appear anywhere in a = (sub)module, > > >> and will be scoped to the parent statement and its substaments = (unless > > >> overriden). > > >> > > >> Lada > > >> > > >> Kent Watsen writes: > > >> > > >>> All, > > >>> > > >>> This is start of a two-week poll on making the following draft a > > >>> NETMOD working group document: > > >>> > > >>> draft-lhotka-netmod-yang-markup-00 > > >>> > > >>> Please send email to the list indicating "yes/support" or "no/do = not > > >>> support". If indicating no, please state your reservations with = the > > >>> document. If yes, please also feel free to provide comments = you'd > > >>> like to see addressed once the document is a WG document. > > >>> > > >>> Thank you, > > >>> NETMOD WG Chairs > > >>> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 12 10:59:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B5C12EB2C for ; Wed, 12 Apr 2017 10:59:52 -0700 (PDT) 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jlHkUzRiW76 for ; Wed, 12 Apr 2017 10:59:49 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9615712EB1E for ; Wed, 12 Apr 2017 10:59:48 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id o21so22323202wrb.2 for ; Wed, 12 Apr 2017 10:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SevCUcxaTNNjIlUf3wbDw/XFUcDJTZ5137APaa3hx5c=; b=W1ri0ScHhDBAtOTZM9paVO0u5lJlPWNd2I5ZvaJChutrw0557N1sGWETcZUS5ZlyHO 1izdvEV4PbTcflAF31MZXaWGAWFS4z/Ml0icUtWCNpsur7FsS2HfSvxgBX53WEhP1Ww9 at1uUGcIQQwlRSLDm3Q0j3h1nJXv5h2jF/1kKUZz5yvD27Mw8rVVvRtJdsc/MVJ48Ycm bDIOA+Z+YFEQAv4PmQ9a4nNL2zxKix5mrT7al2vuyp9w/2RVU71Uuua8L8rK0Bt4QxXA F2USVRgOnPTAlyZPPqm2ZFeirljCIkRp7S0kDzfjbawOgoLYF5YhvG4dFplwvWPYVKt/ A99A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SevCUcxaTNNjIlUf3wbDw/XFUcDJTZ5137APaa3hx5c=; b=JwukZnWNnUzc1klEIcvr/cp0XtjYvjOYttQLbtjhGgVllTORZf64LQu4DiszL1GJGh 1bSuU3u5ssq9TpwS9tPcB2HlVHHZfKWWcwAdTsx4qRN8yPypysIe8igsT/fQSKbC46Uc U5hrTa82IYEZDm1aKet9oBfHPHwDuUAsZVsi8u0v4b9HeUt0LCG+FckdIG886rtu8w5a g24+MvKiCgYZNGpBmBUorIUiFQTDb71WP6N72TEIC7yCDwo2Bzp496ASbc4JYy/94/ZX hJt1+yGpUXHBXnbSUcCWEkdHzR86YKnZfxKO7OGn3WJk+u48/jPtYWnX5yKu6GIcv/nW a2EQ== X-Gm-Message-State: AN3rC/7efGdG9XPSVRiHDRrfajI/1ESIa21EFEwNXGxCqm4aQfjVdq8n1UTdhoKFrKIdoHjWftQkI5hkUh2ogg== X-Received: by 10.223.129.4 with SMTP id 4mr4590521wrm.62.1492019987059; Wed, 12 Apr 2017 10:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Wed, 12 Apr 2017 10:59:46 -0700 (PDT) In-Reply-To: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> From: Andy Bierman Date: Wed, 12 Apr 2017 10:59:46 -0700 Message-ID: To: Ladislav Lhotka Cc: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c06859853d263054cfbf9a4 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 17:59:52 -0000 --94eb2c06859853d263054cfbf9a4 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 12, 2017 at 10:39 AM, Ladislav Lhotka wrote: > > > On 12 Apr 2017, at 18:44, Andy Bierman wrote: > > > > > > > > On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > I think it is crucial that descriptions etc. remain human readable > > using plain text readers. Having to run a renderer to make sense out > > of descriptions etc. would be a big failure and things are even worse > > if modules use different dialects all over the place. > > > > I believe there is way more important work to get done than this (and > > I fear endless discussions about which adapted subsets of markdown or > > (whatever comes next) to use). I do not object this work, but I also > > do not support it at this point in time. > > > > > > +1 > > > > IMO this makes YANG less readable, especially without any agreement > > on the specific markup supported. A YANG module should be readable by > humans > > without any special tools required. > > Why do you think that unprocessed *lightweight* markup such as markdown is > not readable by humans? Note that everybody can use it even now without > further ado, so this document only allows module authors who want to do so > to provide explicit info about the format. > > I think YANG should not place any additional burden on readers. Tool-makers are the lowest priority. Too bad if things are not optimized for them. > As the draft also tries to explain, some trivial markup is already > commonly used in IETF modules (for example, bulleted lists) and > inconsistent indentation rules make it difficult for applications to > properly format such texts. > > A bullet list is human-readable without any need to reformat and re-render. A reader can correctly interpret a bullet list without knowing any markup. Tools can figure out what to do on their own. I do not think this is really needed in YANG. If you want to convert YANG to HTML, then just do it. We don't need to have a standard for this. Lada > > Andy > > > > > > /js > > > > > > Andy > > > > On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > > Robert Wilton writes: > > > > > > > Yes/support. But with the condition that I would still like the > draft > > > > to define a basic common subset of markdown fields/annotations that > > > > implementations would be expected to support. For clarity, I'm not > > > > suggesting that the draft should define a new markdown language, I > think > > > > that it would be better to use an existing markdown language, but > > > > perhaps simplified. > > > > > > In my view, this needs to remain purely optional, so implementations > > > won't be expected to support anything. It should be perfectly fine to > > > leave description texts unprocessed, or process only selected > > > constructs. > > > > > > > > > > > I want to avoid the scenario where each group of YANG modelers could > > > > decide to use a different incompatible variant of text/markdown, and > > > > hence generic tools would not be able to reliably render the markup > for > > > > a generic YANG module. > > > > > > On the other hand, particular markup conventions might be dictated by > > > external circumstances. For example, for modules hosted at GitHub, the > > > GFM variant of text/markdown looks like a natural choice but elsewhere > > > it can be something different. William also suggested that certain > > > YANG-specific constructs may also be introduced. > > > > > > > > > > > Care would need to be taken with which variant of the Markdown > language > > > > is chosen as a base (RFC 7764 may be of use) . E.g. the github > markup > > > > language has been previously suggested, but the specification > document > > > > for that variant is long (approx 120 pages). > > > > > > RFC 7763 also notes that markdown itself by design has no concept of > > > validity, so I think it is appropriate to take it easy and avoid > > > overspecifying things. > > > > > > I guess the key point here is "lighweight markup": if and > implementation > > > can make use of it, then fine, but module readers should have little > > > difficulty if not. > > > > > > Thanks, Lada > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > > > >> As the author: yes/support. > > > >> > > > >> Two changes seemed to have support in IETF 98 audience: > > > >> > > > >> 1. Apart from text/plain, the media type SHOULD be text/markdown > > > >> (variants permitted). > > > >> > > > >> 2. The "text-media-type" extension can appear anywhere in a > (sub)module, > > > >> and will be scoped to the parent statement and its substaments > (unless > > > >> overriden). > > > >> > > > >> Lada > > > >> > > > >> Kent Watsen writes: > > > >> > > > >>> All, > > > >>> > > > >>> This is start of a two-week poll on making the following draft a > > > >>> NETMOD working group document: > > > >>> > > > >>> draft-lhotka-netmod-yang-markup-00 > > > >>> > > > >>> Please send email to the list indicating "yes/support" or "no/do > not > > > >>> support". If indicating no, please state your reservations with > the > > > >>> document. If yes, please also feel free to provide comments you'd > > > >>> like to see addressed once the document is a WG document. > > > >>> > > > >>> Thank you, > > > >>> NETMOD WG Chairs > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> netmod mailing list > > > >>> netmod@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --94eb2c06859853d263054cfbf9a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 12, 2017 at 10:39 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 12 Apr 2017, at 18:44, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de> wrote:
> I think it is crucial that descriptions etc. remain human readable
> using plain text readers. Having to run a renderer to make sense out > of descriptions etc. would be a big failure and things are even worse<= br> > if modules use different dialects all over the place.
>
> I believe there is way more important work to get done than this (and<= br> > I fear endless discussions about which adapted subsets of markdown or<= br> > (whatever comes next) to use). I do not object this work, but I also > do not support it at this point in time.
>
>
> +1
>
> IMO this makes YANG less readable, especially without any agreement > on the specific markup supported. A YANG module should be readable by = humans
> without any special tools required.

Why do you think that unprocessed *lightweight* markup such as markdown is = not readable by humans? Note that everybody can use it even now without fur= ther ado, so this document only allows module authors who want to do so to = provide explicit info about the format.


I think YANG should not place any addi= tional burden on readers.
Tool-makers are the lowest priority.=C2= =A0 Too bad if things are not optimized for them.
=C2=A0
As the draft also tries to explain, some trivial markup is already commonly= used in IETF modules (for example, bulleted lists) and inconsistent indent= ation rules make it difficult for applications to properly format such text= s.


A bullet list is human-readable withou= t any need to reformat and re-render.
A reader can correctly inte= rpret a bullet list without knowing any markup.
Tools can figure = out what to do on their own.

I do not think this i= s really needed in YANG.
If you want to convert YANG to HTML, the= n just do it.
We don't need to have a standard for this.


Lada


Andy
=C2=A0
>
>
> /js
>
>
> Andy
>
> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote:
> > Robert Wilton <rwilton@ci= sco.com> writes:
> >
> > > Yes/support.=C2=A0 But with the condition that I would still= like the draft
> > > to define a basic common subset of markdown fields/annotatio= ns that
> > > implementations would be expected to support.=C2=A0 For clar= ity, I'm not
> > > suggesting that the draft should define a new markdown langu= age, I think
> > > that it would be better to use an existing markdown language= , but
> > > perhaps simplified.
> >
> > In my view, this needs to remain purely optional, so implementati= ons
> > won't be expected to support anything. It should be perfectly= fine to
> > leave description texts unprocessed, or process only selected
> > constructs.
> >
> > >
> > > I want to avoid the scenario where each group of YANG modele= rs could
> > > decide to use a different incompatible variant of text/markd= own, and
> > > hence generic tools would not be able to reliably render the= markup for
> > > a generic YANG module.
> >
> > On the other hand, particular markup conventions might be dictate= d by
> > external circumstances. For example, for modules hosted at GitHub= , the
> > GFM variant of text/markdown looks like a natural choice but else= where
> > it can be something different. William also suggested that certai= n
> > YANG-specific constructs may also be introduced.
> >
> > >
> > > Care would need to be taken with which variant of the Markdo= wn language
> > > is chosen as a base (RFC 7764 may be of use) .=C2=A0 E.g. th= e github markup
> > > language has been previously suggested, but the specificatio= n document
> > > for that variant is long (approx 120 pages).
> >
> > RFC 7763 also notes that markdown itself by design has no concept= of
> > validity, so I think it is appropriate to take it easy and avoid<= br> > > overspecifying things.
> >
> > I guess the key point here is "lighweight markup": if a= nd implementation
> > can make use of it, then fine, but module readers should have lit= tle
> > difficulty if not.
> >
> > Thanks, Lada
> >
> > >
> > > Thanks,
> > > Rob
> > >
> > >
> > > On 10/04/2017 12:45, Ladislav Lhotka wrote:
> > >> As the author: yes/support.
> > >>
> > >> Two changes seemed to have support in IETF 98 audience:<= br> > > >>
> > >> 1. Apart from text/plain, the media type SHOULD be text/= markdown
> > >> (variants permitted).
> > >>
> > >> 2. The "text-media-type" extension can appear = anywhere in a (sub)module,
> > >> and will be scoped to the parent statement and its subst= aments (unless
> > >> overriden).
> > >>
> > >> Lada
> > >>
> > >> Kent Watsen <k= watsen@juniper.net> writes:
> > >>
> > >>> All,
> > >>>
> > >>> This is start of a two-week poll on making the follo= wing draft a
> > >>> NETMOD working group document:
> > >>>
> > >>>=C2=A0 =C2=A0 draft-lhotka-netmod-yang-markup-00=
> > >>>
> > >>> Please send email to the list indicating "yes/s= upport" or "no/do not
> > >>> support".=C2=A0 If indicating no, please state = your reservations with the
> > >>> document.=C2=A0 If yes, please also feel free to pro= vide comments you'd
> > >>> like to see addressed once the document is a WG docu= ment.
> > >>>
> > >>> Thank you,
> > >>> NETMOD WG Chairs
> > >>>
> > >>>
> > >>> _______________________________________________=
> > >>> netmod mailing list
> > >>> netmod@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/netmod
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/net= mod
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67






--94eb2c06859853d263054cfbf9a4-- From nobody Wed Apr 12 14:13:35 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF2D1295A0; Wed, 12 Apr 2017 14:13:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149203160701.15774.9374112746057504703.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 14:13:27 -0700 Archived-At: Subject: [netmod] Ben Campbell's No Objection on charter-ietf-netmod-08-05: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 21:13:27 -0000 Ben Campbell has entered the following ballot position for charter-ietf-netmod-08-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I lean towards thinking this should have an external review, but I won't insist if others think it is unnecessary. The vast majority of the text for the old charter is changed. The milestone dates seem optimistic. Four of them are this month; is that intentional? From nobody Wed Apr 12 22:46:06 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A881E1267BB; Wed, 12 Apr 2017 22:46:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alia Atlas To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149206236459.15682.10714540431640759841.idtracker@ietfa.amsl.com> Date: Wed, 12 Apr 2017 22:46:04 -0700 Archived-At: Subject: [netmod] Alia Atlas' Yes on charter-ietf-netmod-08-05: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 05:46:05 -0000 Alia Atlas has entered the following ballot position for charter-ietf-netmod-08-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I do think that it would be helpful for this charter to discuss some of the needed WG interactions. In particular, where encodings of YANG are defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there should be coordination of the impact of changes to the YANG language. Another question is where do you see the discussion of device profiles or sets of YANG modules needed to meet a particular purpose going? To me, this doesn't read as in scope for this charter and yet I don't think that we've thought through the right place for them. I'm ok with continued discussion for routing-related ones in RTGWG - but not all device profiles (i.e. a profile of modules needed for a firewall) belong anywhere near Routing. From nobody Wed Apr 12 23:13:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6F4124234; Wed, 12 Apr 2017 23:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 OYjX28dIZMkI; Wed, 12 Apr 2017 23:13:52 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA69127201; Wed, 12 Apr 2017 23:13:52 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a] (unknown [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a]) by mail.nic.cz (Postfix) with ESMTPSA id C1E046297A; Thu, 13 Apr 2017 08:13:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492064030; bh=Kke6QrGCdYlD7222D4OMFKDjNxzRMxZB4DkDBdCGuzs=; h=From:Date:To; b=LP9qaqq4cA83Jltxn6ynDsY5Q2p34FhT+t7U9zpVvwYctvcxtiQsM080KofaKiIAx J2crlyeFyPA9MEAgiZKmQBLAJRPQ2hMcfUgaKRfUCdqgBkJ47/yroD0o/MDhZLv5kn GA90bD2mKSf7xvUgZiEbq3/YKoige3YRMsC5bEsE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Apr 2017 08:13:50 +0200 Cc: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 06:13:55 -0000 > On 12 Apr 2017, at 19:59, Andy Bierman wrote: >=20 >=20 >=20 > On Wed, Apr 12, 2017 at 10:39 AM, Ladislav Lhotka = wrote: >=20 > > On 12 Apr 2017, at 18:44, Andy Bierman wrote: > > > > > > > > On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder = wrote: > > I think it is crucial that descriptions etc. remain human readable > > using plain text readers. Having to run a renderer to make sense out > > of descriptions etc. would be a big failure and things are even = worse > > if modules use different dialects all over the place. > > > > I believe there is way more important work to get done than this = (and > > I fear endless discussions about which adapted subsets of markdown = or > > (whatever comes next) to use). I do not object this work, but I also > > do not support it at this point in time. > > > > > > +1 > > > > IMO this makes YANG less readable, especially without any agreement > > on the specific markup supported. A YANG module should be readable = by humans > > without any special tools required. >=20 > Why do you think that unprocessed *lightweight* markup such as = markdown is not readable by humans? Note that everybody can use it even = now without further ado, so this document only allows module authors who = want to do so to provide explicit info about the format. >=20 >=20 > I think YANG should not place any additional burden on readers. > Tool-makers are the lowest priority. Too bad if things are not = optimized for them. > =20 > As the draft also tries to explain, some trivial markup is already = commonly used in IETF modules (for example, bulleted lists) and = inconsistent indentation rules make it difficult for applications to = properly format such texts. >=20 >=20 > A bullet list is human-readable without any need to reformat and = re-render. > A reader can correctly interpret a bullet list without knowing any = markup. > Tools can figure out what to do on their own. If you want to ignore the extension proposed by this draft in your = tools, you are free to do so. Other people may want to use this extra = information. Lada =20 >=20 > I do not think this is really needed in YANG. > If you want to convert YANG to HTML, then just do it. > We don't need to have a standard for this. >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > /js > > > > > > Andy > > > > On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > > Robert Wilton writes: > > > > > > > Yes/support. But with the condition that I would still like the = draft > > > > to define a basic common subset of markdown fields/annotations = that > > > > implementations would be expected to support. For clarity, I'm = not > > > > suggesting that the draft should define a new markdown language, = I think > > > > that it would be better to use an existing markdown language, = but > > > > perhaps simplified. > > > > > > In my view, this needs to remain purely optional, so = implementations > > > won't be expected to support anything. It should be perfectly fine = to > > > leave description texts unprocessed, or process only selected > > > constructs. > > > > > > > > > > > I want to avoid the scenario where each group of YANG modelers = could > > > > decide to use a different incompatible variant of text/markdown, = and > > > > hence generic tools would not be able to reliably render the = markup for > > > > a generic YANG module. > > > > > > On the other hand, particular markup conventions might be dictated = by > > > external circumstances. For example, for modules hosted at GitHub, = the > > > GFM variant of text/markdown looks like a natural choice but = elsewhere > > > it can be something different. William also suggested that certain > > > YANG-specific constructs may also be introduced. > > > > > > > > > > > Care would need to be taken with which variant of the Markdown = language > > > > is chosen as a base (RFC 7764 may be of use) . E.g. the github = markup > > > > language has been previously suggested, but the specification = document > > > > for that variant is long (approx 120 pages). > > > > > > RFC 7763 also notes that markdown itself by design has no concept = of > > > validity, so I think it is appropriate to take it easy and avoid > > > overspecifying things. > > > > > > I guess the key point here is "lighweight markup": if and = implementation > > > can make use of it, then fine, but module readers should have = little > > > difficulty if not. > > > > > > Thanks, Lada > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > > > >> As the author: yes/support. > > > >> > > > >> Two changes seemed to have support in IETF 98 audience: > > > >> > > > >> 1. Apart from text/plain, the media type SHOULD be = text/markdown > > > >> (variants permitted). > > > >> > > > >> 2. The "text-media-type" extension can appear anywhere in a = (sub)module, > > > >> and will be scoped to the parent statement and its substaments = (unless > > > >> overriden). > > > >> > > > >> Lada > > > >> > > > >> Kent Watsen writes: > > > >> > > > >>> All, > > > >>> > > > >>> This is start of a two-week poll on making the following draft = a > > > >>> NETMOD working group document: > > > >>> > > > >>> draft-lhotka-netmod-yang-markup-00 > > > >>> > > > >>> Please send email to the list indicating "yes/support" or = "no/do not > > > >>> support". If indicating no, please state your reservations = with the > > > >>> document. If yes, please also feel free to provide comments = you'd > > > >>> like to see addressed once the document is a WG document. > > > >>> > > > >>> Thank you, > > > >>> NETMOD WG Chairs > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> netmod mailing list > > > >>> netmod@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 12 23:22:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B63127201; Wed, 12 Apr 2017 23:22:31 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0khHK20NqjQ; Wed, 12 Apr 2017 23:22:29 -0700 (PDT) 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 DFEE5124234; Wed, 12 Apr 2017 23:22:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id ADAAD6BA; Thu, 13 Apr 2017 08:22:27 +0200 (CEST) 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 KRCQq7YkVYfm; Thu, 13 Apr 2017 08:22:24 +0200 (CEST) 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; Thu, 13 Apr 2017 08:22:27 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66C3620051; Thu, 13 Apr 2017 08:22:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xDFe7GtiPGSy; Thu, 13 Apr 2017 08:22:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1001320050; Thu, 13 Apr 2017 08:22:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 867F83F1C558; Thu, 13 Apr 2017 08:22:30 +0200 (CEST) Date: Thu, 13 Apr 2017 08:22:30 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Message-ID: <20170413062230.GA85844@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 06:22:31 -0000 On Thu, Apr 13, 2017 at 08:13:50AM +0200, Ladislav Lhotka wrote: > > If you want to ignore the extension proposed by this draft in your tools, you are free to do so. Other people may want to use this extra information. > As a human, I can't ignore markup thrown at my eyes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Apr 12 23:28:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C3A1273B1; Wed, 12 Apr 2017 23:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 nUpZVV09n5Kh; Wed, 12 Apr 2017 23:28:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4538124234; Wed, 12 Apr 2017 23:28:09 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a] (unknown [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a]) by mail.nic.cz (Postfix) with ESMTPSA id 9A27A7B481; Thu, 13 Apr 2017 08:28:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492064888; bh=+RpDYR9Jwdic0rvC4QKPEr1ekYg2uqf/UjoUq5Nq+ho=; h=From:Date:To; b=D+LPC0BlBzp6zZ6cPmPxCSaBq5dGhqqAY0fNmRohMUA4Pc+Td+44u1IXhdV1VYrTu 00zY7Ql6KDDk4t9UyX9jr1rudrZ/2kvbRMK/QL4B05b8gMgyHXCVYbOqL865PpeVX+ WIpwBRm/1IRZIamm0YWD6Asdo65Ga8fTiIL4wNgw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <20170413062230.GA85844@elstar.local> Date: Thu, 13 Apr 2017 08:28:08 +0200 Cc: Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <584A7D9B-3D6D-4B66-A81B-203E7AF31AD3@nic.cz> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> <20170413062230.GA85844@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 06:28:13 -0000 > On 13 Apr 2017, at 08:22, Juergen Schoenwaelder = wrote: >=20 > On Thu, Apr 13, 2017 at 08:13:50AM +0200, Ladislav Lhotka wrote: >>=20 >> If you want to ignore the extension proposed by this draft in your = tools, you are free to do so. Other people may want to use this extra = information. >>=20 >=20 > As a human, I can't ignore markup thrown at my eyes. We are talking past each other. Are you willing to admit that my draft = has nothing to do with the *presence* of markup in a description text, = as long as it remains a valid YANG string? Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 13 00:14:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D8712EB89; Thu, 13 Apr 2017 00:14:23 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPJ6pLPWdzQM; Thu, 13 Apr 2017 00:14:22 -0700 (PDT) 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 C1C9B12EB84; Thu, 13 Apr 2017 00:14:21 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 990A9341; Thu, 13 Apr 2017 09:14:20 +0200 (CEST) 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 HkjRG_HcGbbJ; Thu, 13 Apr 2017 09:14:17 +0200 (CEST) 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; Thu, 13 Apr 2017 09:14:20 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77EB320051; Thu, 13 Apr 2017 09:14:20 +0200 (CEST) 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 1erboaOxZ_wb; Thu, 13 Apr 2017 09:14:19 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98C4B20050; Thu, 13 Apr 2017 09:14:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 668483F1C610; Thu, 13 Apr 2017 09:14:22 +0200 (CEST) Date: Thu, 13 Apr 2017 09:14:22 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Cc: Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Message-ID: <20170413071421.GA85949@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" References: <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> <20170413062230.GA85844@elstar.local> <584A7D9B-3D6D-4B66-A81B-203E7AF31AD3@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <584A7D9B-3D6D-4B66-A81B-203E7AF31AD3@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 07:14:23 -0000 On Thu, Apr 13, 2017 at 08:28:08AM +0200, Ladislav Lhotka wrote: > > We are talking past each other. Are you willing to admit that my draft has nothing to do with the *presence* of markup in a description text, as long as it remains a valid YANG string? > I think you do not understand what I am saying. The main purpose of description statements etc. is that they are easily to read by humans. 7.21.3. The "description" Statement The "description" statement takes as an argument a string that contains a human-readable textual description of this definition. I disagree with your claim that human-readable text is markup. The whole RFC series is formatted human-readable text, not markup. I believe this work is heading in the wrong direction, it will lead to endless discussions of many different flavors of markup used in description clauses, and it will harm interoperability at the human eye level. I believe there are way more important problems to work on. I am out of this thread (since there is more important work to do). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Apr 13 00:21:35 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC0C12EBA7; Thu, 13 Apr 2017 00:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 u1oFLcDQp1Ia; Thu, 13 Apr 2017 00:21:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E97412EBA6; Thu, 13 Apr 2017 00:21:29 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a] (unknown [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a]) by mail.nic.cz (Postfix) with ESMTPSA id 9251263679; Thu, 13 Apr 2017 09:21:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492068087; bh=MPT+8NOpu2U1FgLTZSb+ilBXUrT6DX7B6SyQipHTl9M=; h=From:Date:To; b=OdQx+OIvOqt6eMw51H1jkj5dJyYNlFIm1Xk7bpTvlQZPr5iGEt0mnwUBFHPPb2MHN Mg6BttZdfAXMj+C5iAMWKNq7YvcVa0BEQ6SUk3L1vlfW8l6b9qfrZbTmBbrCu5vakZ m94i1htglo4HM8My2oCG0lSWD/YKhoUnyQbAKP00= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <20170413071421.GA85949@elstar.local> Date: Thu, 13 Apr 2017 09:21:27 +0200 Cc: Andy Bierman , Robert Wilton , Kent Watsen , "netmod@ietf.org" , "netmod-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3768EA5B-2691-4854-A8F7-5C07410956E2@nic.cz> References: <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <437C6A56-6273-4E37-AAE1-90E01589C1CE@nic.cz> <20170413062230.GA85844@elstar.local> <584A7D9B-3D6D-4B66-A81B-203E7AF31AD3@nic.cz> <20170413071421.GA85949@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 07:21:34 -0000 > On 13 Apr 2017, at 09:14, Juergen Schoenwaelder = wrote: >=20 > On Thu, Apr 13, 2017 at 08:28:08AM +0200, Ladislav Lhotka wrote: >>=20 >> We are talking past each other. Are you willing to admit that my = draft has nothing to do with the *presence* of markup in a description = text, as long as it remains a valid YANG string? >>=20 >=20 > I think you do not understand what I am saying. The main purpose of > description statements etc. is that they are easily to read by humans. >=20 > 7.21.3. The "description" Statement >=20 > The "description" statement takes as an argument a string that > contains a human-readable textual description of this definition. >=20 > I disagree with your claim that human-readable text is markup. The > whole RFC series is formatted human-readable text, not markup. I > believe this work is heading in the wrong direction, it will lead to > endless discussions of many different flavors of markup used in > description clauses, and it will harm interoperability at the human > eye level. >=20 > I believe there are way more important problems to work on. I am out > of this thread (since there is more important work to do). I believe your discussion habits are sometimes aggressive and = unacceptable. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 13 05:14:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18EA131597; Thu, 13 Apr 2017 05:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=btconnect.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 p5SEbbfGMpF2; Thu, 13 Apr 2017 05:14:33 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0138.outbound.protection.outlook.com [104.47.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9510A12942F; Thu, 13 Apr 2017 05:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O+i2m26XKtTftzKPDu3OaElCdPPI8b4AQar8wBrL4uw=; b=SL8ur+cT5dzaReRe3caUZqWKbwsROC5bU/c2YxjNntiyOgwegK+JxllY9ETzEeZO7+IcbG0ZKtJiET3Gvif9jJyYxwjFu6lYXLpC3XZf5hbKZA3+qnkP3ht7vVqXYLUQS5HCN+gQ9NSiwzGK5r01S3Jjt6DACysWDSIMRNK8kPU= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (86.169.157.161) by AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 13 Apr 2017 12:14:29 +0000 Message-ID: <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Robert Wilton , Kent Watsen , , References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> Date: Thu, 13 Apr 2017 12:34:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.157.161] X-ClientProxiedBy: AM4PR05CA0034.eurprd05.prod.outlook.com (10.171.184.175) To AM5PR0701MB2994.eurprd07.prod.outlook.com (10.168.156.144) X-MS-Office365-Filtering-Correlation-Id: 263b334c-a0cf-4b45-dd71-08d48266a327 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 3:MHRlPM4n6Rh3VOgWtD1WRqxO2Nx2g5TiNzQavMxycn4zrG+291v/cdiuJ1WjE26EHZSwMWT7idRdPlIdH1MbTOtzqEjweNctp8MkxThNzbUi1zEhUm5mDQCPB7MJPFBUYS4waV/RMFBnAnLC6iiIsTrYm/fWJZnWQFmuZQGXQyqte8U6LTi/tPMpuzI5zXH3Y3NIqZKHeUWodlr7WR4bCIrLXgmvCak1fxduFQHGgVW8TUAUHOAN1/DsPnaFF7ujMPerF3JzYhTFMoKfF5fuuhyo7JYAgLKXyT1+C2J5ySOD23/IAgnz5r/Ij0DStJWIIWXfM1col8oXo/775qUW0A==; 25:r4n6dWbTqKUbirc038v9PG4n9FggoPlFre+twOLdt4bFrNhA5gFTtNti64RNs5pC71AtI9oN9+PT0dmXdUykoMBG4s4U+ZSZkROYDyGmvdJb830Jxm3jHPXmV79OP4DKnH73ap5yKhBzA4AU6GqobU/81nM271mal+Tc+ChBrRrT+mQr24huh8HSyDwPzLx6rEorpC6/7hrGAu9uiUe/5K+jhBWHEdwQqTH2OG8ljIhhbnfsngWpmsnu4dYUkMMIxcN49Vp8EizIz/L0eGDn83Kg6eIj/dgs+9bVy3VvTuXpA2yRsvt5vOiuKpfrl8yhY/4NyeIde+07yZOO61dIVpjFiUCXQ7Q95Mls7yfCsd8vxh6/WQy9t8cL5pURqAGarOPw7k9Zi2LgaCV+zlkAwUrhd16PfhVrxs+59/effcKY0dzIy5IpWkUhRF6NAul7sUiMfuRfLruquYkg1W6nzkLHURWrQtamH2QZKuBGiAE= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 31:9sJnXB802Idl8SfQ3gPCSxdycUTW6RG3/mLvFP8oVI8vQS57FUGlYSoVKoWFflfvCUoLEV8kMsBptAVImrJW1ywyThxkNI0Y6bD1X/w4xr0vYC619QXh1F+zDiHtykbU/Le6MjYzwcPsDPZitFsvtsb8UO4sSE9ikaMuTQhPpLMBsmwXZADvuZbkdblIUOpXB0nAefXU3+eEdORn1GoA/j7+KV/uPFF9puIO1Tb5nfuGFWrWCHS8sxxem/HzH0ECtRbPPtxOoFN1BSUdPhJCtQ== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:AM5PR0701MB2994; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2994; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 4:9PAe3eYVues8YrRhSgRtHGcGrFgMdWFhvTwy5EU+wMRkfwXjApzxXA6DvVICKDNTYEjshKnFBvyyWpBEb0m3XyxNsktjQQ09P0a/NsjT2zwsjhPl+7D7PqxF3GTJ3YuOAXfzmSZP1dnobGLhuziPkkRKsGTGcbmXEt74DzIWVH5SX+JoqVK0do5aFY0JTIZjyyrsQJ8A7mIfVJSTPfc4jOOzJsbW1sq+FV7Z9ecTT3RitnYMmv9HOdvoet7vBSvl31Jowc1itSznWKpkrFhFX92rKOV2XMzAyF2yVmz2TFONhg84FUmoRjctOYvv0gma8TyRydfuLahnXV1HA2f6hgBo5Z9hI3SlTgD9vuRvJKHgz7fTdJ3lljC/kFLd3Cohq2CF/4ea7ifiegrUxnt4JL3cgK3I0CmTEEThwHEV8N/XVMBWyZbcEKamI4SUEhBc4KS/z2KrkNwUtPcde0fCciOdu8XKoJGtgi6QepTDgQbtXnD9kGM3dLdBaNSVJgiTR/WJw3RxH8MsXXZ5WCC6a5CKFqVHrEiDlOgqGeNXF1QNOyLMCyUNB2xhYbEb7tgUU+RVcAWdGKcYPY3kvVmKyGl6Rhdoo6fg9SaBEixJ7aW+ZozQngb4k7te/nTCFHHWYmVNIQuYw99ozlRW5h8TeVWJuRccRB5bhQeuxotoasWMbIo69h9t/QroerP9iWPDjy8CmMHhLpE+vdFOqW4MOB3sU/4cVYJZJTsAXo3Pzn1yyMkQoo/Krdq+wNAWY1mRJZU+uBt2+8702epHvXWzoUQpU3uQUB58YaQOpH8N1rQ= X-Forefront-PRVS: 02760F0D1C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(39850400002)(39840400002)(39410400002)(39400400002)(39860400002)(39450400003)(24454002)(377454003)(13464003)(6116002)(230700001)(3846002)(50226002)(8676002)(7736002)(44716002)(305945005)(62236002)(1456003)(81166006)(86362001)(33646002)(2201001)(47776003)(42186005)(61296003)(66066001)(23676002)(229853002)(44736005)(8666007)(76176999)(6486002)(6306002)(84392002)(9686003)(116806002)(2906002)(53546009)(25786009)(53936002)(93886004)(6496005)(50466002)(5820100001)(14496001)(6666003)(4720700003)(38730400002)(6246003)(1556002)(81686999)(5660300001)(50986999)(1941001)(230783001)(81816999)(189998001)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2994; H:pc6; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTQ7MjM6NDlsZ3Jha0JnbVRzQVpkdWVDZFByallN?= =?utf-8?B?bGs5ejhoblNlak4xN1MwcTdCLzJPSllGNXBDZGZyL2JuYktzWEx2bEhYQ3pW?= =?utf-8?B?Wm9XZ2VjMHg0bXZ3aWJxRVVBd2ozS0MrZWNtclQ0N0x3YU9wYVBTMjcvcWhT?= =?utf-8?B?MVZWNEc0ZzJIbksreXRuQnZLK01vblViUWN1ZTZCckw4dWtLbFRhUlRtMFlR?= =?utf-8?B?WlFaRWJaUmUvcHk3MDNTUkJmSWc0NENwWWc0aFpka2h5L2hXM0draDBsQlds?= =?utf-8?B?RjdxSFRnY0VuZnlGNDE5VXhpcEVQY2xWVEd6ZkJ6SWVFRG0wOXhsVnUvaXZE?= =?utf-8?B?UFhWdndoeWlXQ0RhaWlZTlFqVTVSMUNuS1RBOGMwaXZ6OEE3d29aOGpSakdh?= =?utf-8?B?SWd6WWEzS2s0Sk8vVWdrcGVYdXNhakcwV2NmZ3U1RUFXdFFMZjAyUmlOcnda?= =?utf-8?B?c05nNmZua0pZbFgyNkt3b0VGWkVLdGZBVGdYU0hZTEJCWVpCdEpPTmV0TFU0?= =?utf-8?B?TDMwajV2cDRMZGU0WjhOTWwwVkt4U0tGVkFSbFd6eFB3SGVFYUdHbldSWkp6?= =?utf-8?B?cml2N09wbVZmRkNHQWtxUmY1VVNOdkh6ZXRWajRTUjZVNDNPQUlLYWhmV1M4?= =?utf-8?B?MjNBajhnV2trRmtDSHlhazZLWXJBMktCcTdIV2dpWEVBVHlINkZyWUpzREhy?= =?utf-8?B?WTA4L0RPcEg0RUo5L1EwWmQ1dHFPeHh2KzJLcER5cTBmL01VL1VWcjRNWlIx?= =?utf-8?B?QjZsWWVZQWloblZjTnNZQm53bklmRlFJQkcralhtRWNaNXNtc0MwZjdiNWpq?= =?utf-8?B?SXBVcCtKZW14RFl4dWJiVjZJdUkxWTdPVmdYVXJyNXlkYWNCNlZkcU9Jc1pJ?= =?utf-8?B?bG82bjIrSG1ETHFMSUpTY01GdFBTMWw4ZUY3WklCZWptdG1lV2sxZXNuKyts?= =?utf-8?B?d0FNeTZXWFRWUTRpeHVOY1pvSFBnRGlYZUxhUGxMQTFSRlFKcFFHL2xRTFVG?= =?utf-8?B?YnBsVFN2eUplYnJ0UUljbE90d0ZMR0VsVWlXRkdQNnpGL3ppMzg4eEVqWmhE?= =?utf-8?B?MmhabzZJUVZ3VUNxZEMvUjRxTDA1UFhJYThwZkFzU05lY21yVXlIbTFSZ2Jv?= =?utf-8?B?UnorWEUrdGFDMDgxN3o4UHVhcllac0c1TUh2Yy92K0lock1lQ2RFSFdEVXZw?= =?utf-8?B?NjAzZVFqOXZKUHpERjAyYkYveDJRZC9YN0J1UGNWNjNPMWlNaVBMdk92WmVu?= =?utf-8?B?SEc4a2QvZHBabUZJTGkreFkrRU5ZdmNSdVkyWlVOUXBqZWhhVnFScTRrUmlE?= =?utf-8?B?MlVoYXBwYzhpZEdrRlloN21LS2VMdCtZb29VMU5XL05SaHJRZXFwVHZvcVpv?= =?utf-8?B?Vkh0bWNjczF1M2t1d0hOei9kb25yL3BYem9vQVVYMGs4blkzSHhHYnFTK3Iz?= =?utf-8?B?azlNMUFLSmdMZExHSWc2eDJYeUlvNDVFbm5XZ0R1eGxWYUxJejU0T0MrclRQ?= =?utf-8?B?TXNEcnNCcnd0ZU9DaGttdEJ3SGlnamF4c0ZCWHBxSEFhdGZwbjROSnhaeUJn?= =?utf-8?B?YUxtb0R4cmE3VDgwVmZGSkJpM3R6Z2VqQ2Z6ZDg3SS94eEFXUUQyTVRRTktz?= =?utf-8?B?c29jOTYzbCthVUkxMmk4R0RBcHFRZGUzWGtJL2ducjYvWFFsSnM5VW45VXFm?= =?utf-8?B?SWxWN0U5ZjNMWXRHRWpSK0xFU1lsaXRsLzd0WTJRdHIvR2lSZEZPVytZVHFj?= =?utf-8?B?MlI3MWh0WmJZZFprMXpLS1hWKzZLLzU3SU5mcS9NZVVzUlFXTlU1MWFHOGxI?= =?utf-8?B?SlErTHRtZU12ejBNRzdHTUF5Q0xHenllMDg0SHZzSWlDWllBSTc1ejZBaWtI?= =?utf-8?B?TVEvMkt5TU1ZVVhnTUd6dnpzWnVUc3AvTWhJVGlBSFk5VC95cEVjOFowWHYz?= =?utf-8?B?UnlrNVEzMlo2ZEVROVpFaUtVNExpVWNlY1BLNWZ5NVFHaWZKeUJvak9jcG9Q?= =?utf-8?B?TjNzNWg0R0RYY1lkUzdtMXA4ckNTU0dXVHpvcnNWY2NJejVHYlE1ZURreXpE?= =?utf-8?B?ekY2ejJrd2RweU9KTTAvUGVkNjgvbUNOUTRqRUR4cFhQbmU4Tk13QzRlbDZz?= =?utf-8?Q?/f+JecDEHtkfu5S5ikSq4wiG4=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 6:rv5FR1dM7G5fTLDoPB3cNuL0JQPyQIuz6n+DmxdmLvu5C2vMPG6KLhDkBQOPjf6oYF/IN15vVTNdXdsE/CTMpV+qvOc3djazxzuhntVL4nZR5utmghGTnmGi4gLMLm4cnzQ6cSbMxUR0BIuFFu4GsQpCsQVE72Kt0fjz+/Yyt3XHNbVtGH3BCddlmSwIu1JwvNizh2raOrv9sjgsy62W8anPyfPBrhuhn6mmf2lvjUvO5vYBGl90vsVjNaivNTI1WG2MdIaVKHodvRZgCuNLNnRCg9hweSgvnUif2eXqQpbhX7Fyd90Y7fNwOMUX/5ul9T5JjZQpMYhWt1L8CmalQwtGOfFKkdKga1jcVrZ3HjJFoJqyELeFKaxPj2DmFDFRCDUKTkckYSJFJ4V6r8cL7XgZBOFX0Zg1RZP76SqTWYNGhkYmfDsdlXdMijJiIyA/QHpV3tkSuA+y39oR9jdeDQ==; 5:LbxksoCgXMWCa8VTS8xSug+g81oQUHK4/Bf7WsnPRmd62o13XXVcP0FQX8yTuOuE6g4IzsXWf3yCujIgrj7BK+a/puV/qpHTHTddv3P5RVFnvqM5+qreibZiiKT1txkYqZHNKLLZNUoQp7k555gXBA==; 24:aLbGOXwiOme3ngLIApztTBy73QA/ZQWEGCX00IU7peWuht5rwNSwwrdXuqiLMFyxMlj5owIpVpFEkZtzphl703GcgnMJf9KpGDuDK2wV8co= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2994; 7:9EpcyjvADJBjUgEfsjEMvn9fDR9VCvyf53faWGccxQ87MJiJzi4T8MnvGIxw7KNh2Wq+u6wtyv+8Mw0lgg2UPaP5uTsTmB8brhtpcK4lP9HRcGXqilkr62dlw5OI1dQtS+4ng8Gw5JdFtbR6mLXTK5OI/SdFU9+srRPpOBR760LFhGemkJNV/b7X4yXNWnxSTVkub1HrVqqsH3RQZEd4jjjFmemOPVf50u1viNInFywMbka5sW525vgn/8F8fdEu1RTwo1Abjbs7x5TR5dbwbL6LvoZh4axM9SEoOM8jv8rU6AzbpABP/AwnKP1IWKDYPVkJI/XXCqQvV8PveWWd/Q== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2017 12:14:29.6902 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2994 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 12:14:37 -0000 ----- Original Message ----- From: "Andy Bierman" Sent: Wednesday, April 12, 2017 5:44 PM > On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > I think it is crucial that descriptions etc. remain human readable > > using plain text readers. Having to run a renderer to make sense out > > of descriptions etc. would be a big failure and things are even worse > > if modules use different dialects all over the place. > > > > I believe there is way more important work to get done than this (and > > I fear endless discussions about which adapted subsets of markdown or > > (whatever comes next) to use). I do not object this work, but I also > > do not support it at this point in time. > > > > > +1 > > IMO this makes YANG less readable, especially without any agreement > on the specific markup supported. A YANG module should be readable by humans > without any special tools required. I agree. I would say that if you cannot say it in text/plain, then you probably should not be saying it (something I would extend to e-mail but realise that I am less likely to get support there:-) Tom Petch > > /js > > > > > Andy > > > > On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > > Robert Wilton writes: > > > > > > > Yes/support. But with the condition that I would still like the draft > > > > to define a basic common subset of markdown fields/annotations that > > > > implementations would be expected to support. For clarity, I'm not > > > > suggesting that the draft should define a new markdown language, I > > think > > > > that it would be better to use an existing markdown language, but > > > > perhaps simplified. > > > > > > In my view, this needs to remain purely optional, so implementations > > > won't be expected to support anything. It should be perfectly fine to > > > leave description texts unprocessed, or process only selected > > > constructs. > > > > > > > > > > > I want to avoid the scenario where each group of YANG modelers could > > > > decide to use a different incompatible variant of text/markdown, and > > > > hence generic tools would not be able to reliably render the markup for > > > > a generic YANG module. > > > > > > On the other hand, particular markup conventions might be dictated by > > > external circumstances. For example, for modules hosted at GitHub, the > > > GFM variant of text/markdown looks like a natural choice but elsewhere > > > it can be something different. William also suggested that certain > > > YANG-specific constructs may also be introduced. > > > > > > > > > > > Care would need to be taken with which variant of the Markdown language > > > > is chosen as a base (RFC 7764 may be of use) . E.g. the github markup > > > > language has been previously suggested, but the specification document > > > > for that variant is long (approx 120 pages). > > > > > > RFC 7763 also notes that markdown itself by design has no concept of > > > validity, so I think it is appropriate to take it easy and avoid > > > overspecifying things. > > > > > > I guess the key point here is "lighweight markup": if and implementation > > > can make use of it, then fine, but module readers should have little > > > difficulty if not. > > > > > > Thanks, Lada > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > On 10/04/2017 12:45, Ladislav Lhotka wrote: > > > >> As the author: yes/support. > > > >> > > > >> Two changes seemed to have support in IETF 98 audience: > > > >> > > > >> 1. Apart from text/plain, the media type SHOULD be text/markdown > > > >> (variants permitted). > > > >> > > > >> 2. The "text-media-type" extension can appear anywhere in a > > (sub)module, > > > >> and will be scoped to the parent statement and its substaments (unless > > > >> overriden). > > > >> > > > >> Lada > > > >> > > > >> Kent Watsen writes: > > > >> > > > >>> All, > > > >>> > > > >>> This is start of a two-week poll on making the following draft a > > > >>> NETMOD working group document: > > > >>> > > > >>> draft-lhotka-netmod-yang-markup-00 > > > >>> > > > >>> Please send email to the list indicating "yes/support" or "no/do not > > > >>> support". If indicating no, please state your reservations with the > > > >>> document. If yes, please also feel free to provide comments you'd > > > >>> like to see addressed once the document is a WG document. > > > >>> > > > >>> Thank you, > > > >>> NETMOD WG Chairs > > > >>> > > > >>> > > > >>> _______________________________________________ > > > >>> netmod mailing list > > > >>> netmod@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Apr 13 05:45:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD86A13159C; Thu, 13 Apr 2017 05:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 RmWUp_sWvbO8; Thu, 13 Apr 2017 05:45:08 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD8412943D; Thu, 13 Apr 2017 05:45:08 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a] (unknown [IPv6:2001:718:1a02:1:30ce:c9fd:d5db:548a]) by mail.nic.cz (Postfix) with ESMTPSA id 09F3063EEF; Thu, 13 Apr 2017 14:45:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492087506; bh=X0U8We8KBAp6lcLy+rZCw/Mopa5LxGsi24MxBl/YDD4=; h=From:Date:To; b=rCP2mDOHll0vC11OUcAksP33/RuveKQDkErAjLTrqlPTzSMCY0QER7dEojAF2W9wt OX7Y/gjlKN1Q4ZlYyM+1SwOiBFCrrstd2HoI2FyxZ6qeC+v9huP4QXpgE4PBagJYQ7 UkSmP5Iy7sUeC91iWF+/089YZmlnmJz35fk8Q284= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> Date: Thu, 13 Apr 2017 14:45:05 +0200 Cc: Andy Bierman , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , NETMOD WG , netmod-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> To: "t.petch" X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 12:45:12 -0000 > On 13 Apr 2017, at 13:34, t.petch wrote: >=20 >=20 > ----- Original Message ----- > From: "Andy Bierman" > Sent: Wednesday, April 12, 2017 5:44 PM >=20 >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >>> I think it is crucial that descriptions etc. remain human readable >>> using plain text readers. Having to run a renderer to make sense out >>> of descriptions etc. would be a big failure and things are even > worse >>> if modules use different dialects all over the place. >>>=20 >>> I believe there is way more important work to get done than this > (and >>> I fear endless discussions about which adapted subsets of markdown > or >>> (whatever comes next) to use). I do not object this work, but I also >>> do not support it at this point in time. >>>=20 >>>=20 >> +1 >>=20 >> IMO this makes YANG less readable, especially without any agreement >> on the specific markup supported. A YANG module should be readable by > humans >> without any special tools required. >=20 > I agree. I would say that if you cannot say it in text/plain, then = you > probably should not be saying it (something I would extend to e-mail = but > realise that I am less likely to get support there:-) OK, so if somebody writes leaf foo { description "This is my *favourite* leaf."; type string; } you may not like it, but it is absolutely legal and IMO also readable by = humans. As William previously mentioned, some communities are already = doing similar things. The principal aim of my I-D is to allow module = authors to explicitly state that they adhere to some rules, which helps = authors of tools reduce guesswork. The example with email is actually very relevant. I would also love if = people and MUAs only used plain text but, as you say, this is not going = to happen. If we accept this as a fact, is it better or worse for = interoperability that MUAs provide media type in mail headers? Lada >=20 > Tom Petch >=20 >>> /js >>>=20 >>>=20 >> Andy >>=20 >>=20 >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: >>>> Robert Wilton writes: >>>>=20 >>>>> Yes/support. But with the condition that I would still like the > draft >>>>> to define a basic common subset of markdown fields/annotations > that >>>>> implementations would be expected to support. For clarity, I'm > not >>>>> suggesting that the draft should define a new markdown language, > I >>> think >>>>> that it would be better to use an existing markdown language, > but >>>>> perhaps simplified. >>>>=20 >>>> In my view, this needs to remain purely optional, so > implementations >>>> won't be expected to support anything. It should be perfectly fine > to >>>> leave description texts unprocessed, or process only selected >>>> constructs. >>>>=20 >>>>>=20 >>>>> I want to avoid the scenario where each group of YANG modelers > could >>>>> decide to use a different incompatible variant of text/markdown, > and >>>>> hence generic tools would not be able to reliably render the > markup for >>>>> a generic YANG module. >>>>=20 >>>> On the other hand, particular markup conventions might be dictated > by >>>> external circumstances. For example, for modules hosted at GitHub, > the >>>> GFM variant of text/markdown looks like a natural choice but > elsewhere >>>> it can be something different. William also suggested that certain >>>> YANG-specific constructs may also be introduced. >>>>=20 >>>>>=20 >>>>> Care would need to be taken with which variant of the Markdown > language >>>>> is chosen as a base (RFC 7764 may be of use) . E.g. the github > markup >>>>> language has been previously suggested, but the specification > document >>>>> for that variant is long (approx 120 pages). >>>>=20 >>>> RFC 7763 also notes that markdown itself by design has no concept > of >>>> validity, so I think it is appropriate to take it easy and avoid >>>> overspecifying things. >>>>=20 >>>> I guess the key point here is "lighweight markup": if and > implementation >>>> can make use of it, then fine, but module readers should have > little >>>> difficulty if not. >>>>=20 >>>> Thanks, Lada >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Rob >>>>>=20 >>>>>=20 >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote: >>>>>> As the author: yes/support. >>>>>>=20 >>>>>> Two changes seemed to have support in IETF 98 audience: >>>>>>=20 >>>>>> 1. Apart from text/plain, the media type SHOULD be > text/markdown >>>>>> (variants permitted). >>>>>>=20 >>>>>> 2. The "text-media-type" extension can appear anywhere in a >>> (sub)module, >>>>>> and will be scoped to the parent statement and its substaments > (unless >>>>>> overriden). >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>> Kent Watsen writes: >>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> This is start of a two-week poll on making the following draft > a >>>>>>> NETMOD working group document: >>>>>>>=20 >>>>>>> draft-lhotka-netmod-yang-markup-00 >>>>>>>=20 >>>>>>> Please send email to the list indicating "yes/support" or > "no/do not >>>>>>> support". If indicating no, please state your reservations > with the >>>>>>> document. If yes, please also feel free to provide comments > you'd >>>>>>> like to see addressed once the document is a WG document. >>>>>>>=20 >>>>>>> Thank you, >>>>>>> NETMOD WG Chairs >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> netmod mailing list >>>>>>> netmod@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>>=20 >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>=20 >=20 >=20 > = ------------------------------------------------------------------------ > -------- >=20 >=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 13 08:08:30 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2983B129474; Thu, 13 Apr 2017 08:08:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: netmod-chairs@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149209610807.15738.9217379200248262745.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 08:08:28 -0700 Archived-At: Subject: [netmod] Eric Rescorla's No Objection on charter-ietf-netmod-08-05: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 15:08:28 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-netmod-08-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-netmod/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As before. From nobody Thu Apr 13 09:08:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609721294B8 for ; Thu, 13 Apr 2017 09:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYCHHyGB_fet for ; Thu, 13 Apr 2017 09:08:56 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E8A12949F for ; Thu, 13 Apr 2017 09:08:55 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id z109so38574495wrb.1 for ; Thu, 13 Apr 2017 09:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FJQ8eGOGpwG14bYLWFBnM5qU/q1Yg5U/Vi4BAbA98Mc=; b=l8vYTt6urlTGVTk2bM/WL0n5dMfjercZvfPR/vDnE2K2nr3Ee7QuASKw9AQvYu4YXK 1fPj5MD4Qj9RA/BZ4bfCu7terbcrKknKmY94mQB2ZZzh7DDyBeAowpuHHHcU6j/WZ1kO +XTKC7+zaMJYxPkRXueuN2GcPUz6lcThZiJPowBUXZw6yjk82KrlSUuaIk3hhlutANPf I2Xje5TBckbMBrGf9Ta5Y2/kVxejTj9W4Y68B8fVHQc3he4sztAmXKhzIjO5adoAibkP IWvA7Dk70OavLkLCb5uncAZCeNq2UYaYGvkkUy50IQsVxUkM4rNYu2ejlb4Jwr6hLXyC oyvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJQ8eGOGpwG14bYLWFBnM5qU/q1Yg5U/Vi4BAbA98Mc=; b=SRUk1RV9JyDLqJpDN6iSyRLprSo+XbhOB7bO6yXYagkffNkAz7/FBE6XPWg8F/3tkm 4YpkwgZle7QpsOYzQulVzS45y7JjhOlLDdwlKniyXm8lurRZNl0xf3iKNvXUYSPVyQQo IHYE/On/4BgbJkNF/Owf2TqllrsxQ9csAkZ3wyhwZilHGGaHwrtvFC+kIxn1TW5FOE7s 1hLntACQ1V45BGQCecNjawjZbdNrRsL7D20BFfGrmQIRobO1uT64p8E2SDkRpEQKlETE FaRMxk1w8RXhCPnQc2xlhWspC5MBvKKePpq3T5gNR7l37PR5XoWrhkUdi70LcucmLUCB E5Sw== X-Gm-Message-State: AN3rC/7oNAPkWjVuFuoBsH/lRFkYShCav/fhps/oUc3eNWpj0zimXnwA 7H9Am1UGvQyB5Uwc6reBP8G3ul/pxw== X-Received: by 10.223.178.68 with SMTP id y4mr3888980wra.88.1492099733874; Thu, 13 Apr 2017 09:08:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Thu, 13 Apr 2017 09:08:52 -0700 (PDT) In-Reply-To: <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> From: Andy Bierman Date: Thu, 13 Apr 2017 09:08:52 -0700 Message-ID: To: Ladislav Lhotka Cc: "t.petch" , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , NETMOD WG , NetMod WG Chairs Content-Type: multipart/alternative; boundary=f403045f1a469b8331054d0e8a43 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 16:08:58 -0000 --f403045f1a469b8331054d0e8a43 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka wrote: > > > On 13 Apr 2017, at 13:34, t.petch wrote: > > > > > > ----- Original Message ----- > > From: "Andy Bierman" > > Sent: Wednesday, April 12, 2017 5:44 PM > > > >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> I think it is crucial that descriptions etc. remain human readable > >>> using plain text readers. Having to run a renderer to make sense out > >>> of descriptions etc. would be a big failure and things are even > > worse > >>> if modules use different dialects all over the place. > >>> > >>> I believe there is way more important work to get done than this > > (and > >>> I fear endless discussions about which adapted subsets of markdown > > or > >>> (whatever comes next) to use). I do not object this work, but I also > >>> do not support it at this point in time. > >>> > >>> > >> +1 > >> > >> IMO this makes YANG less readable, especially without any agreement > >> on the specific markup supported. A YANG module should be readable by > > humans > >> without any special tools required. > > > > I agree. I would say that if you cannot say it in text/plain, then you > > probably should not be saying it (something I would extend to e-mail but > > realise that I am less likely to get support there:-) > > OK, so if somebody writes > > leaf foo { > description "This is my *favourite* leaf."; > type string; > } > > Your premise is that the description-stmt is for the benefit of the model writer, not the model reader. Since YANG explicitly states this statement contains a human-readable string, it seems clear the benefit to the readers is more important. you may not like it, but it is absolutely legal and IMO also readable by > humans. As William previously mentioned, some communities are already doing > similar things. The principal aim of my I-D is to allow module authors to > explicitly state that they adhere to some rules, which helps authors of > tools reduce guesswork. > > You may decide to ignore the intent of the description-stmt. That doesn't mean we should change the definition in the standard. IMO plain text is human-readable. Anything that requires parsing, reinterpreting and re-rendering is not human friendly. > The example with email is actually very relevant. I would also love if > people and MUAs only used plain text but, as you say, this is not going to > happen. If we accept this as a fact, is it better or worse for > interoperability that MUAs provide media type in mail headers? > > Lada > Andy > > > > > Tom Petch > > > >>> /js > >>> > >>> > >> Andy > >> > >> > >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > >>>> Robert Wilton writes: > >>>> > >>>>> Yes/support. But with the condition that I would still like the > > draft > >>>>> to define a basic common subset of markdown fields/annotations > > that > >>>>> implementations would be expected to support. For clarity, I'm > > not > >>>>> suggesting that the draft should define a new markdown language, > > I > >>> think > >>>>> that it would be better to use an existing markdown language, > > but > >>>>> perhaps simplified. > >>>> > >>>> In my view, this needs to remain purely optional, so > > implementations > >>>> won't be expected to support anything. It should be perfectly fine > > to > >>>> leave description texts unprocessed, or process only selected > >>>> constructs. > >>>> > >>>>> > >>>>> I want to avoid the scenario where each group of YANG modelers > > could > >>>>> decide to use a different incompatible variant of text/markdown, > > and > >>>>> hence generic tools would not be able to reliably render the > > markup for > >>>>> a generic YANG module. > >>>> > >>>> On the other hand, particular markup conventions might be dictated > > by > >>>> external circumstances. For example, for modules hosted at GitHub, > > the > >>>> GFM variant of text/markdown looks like a natural choice but > > elsewhere > >>>> it can be something different. William also suggested that certain > >>>> YANG-specific constructs may also be introduced. > >>>> > >>>>> > >>>>> Care would need to be taken with which variant of the Markdown > > language > >>>>> is chosen as a base (RFC 7764 may be of use) . E.g. the github > > markup > >>>>> language has been previously suggested, but the specification > > document > >>>>> for that variant is long (approx 120 pages). > >>>> > >>>> RFC 7763 also notes that markdown itself by design has no concept > > of > >>>> validity, so I think it is appropriate to take it easy and avoid > >>>> overspecifying things. > >>>> > >>>> I guess the key point here is "lighweight markup": if and > > implementation > >>>> can make use of it, then fine, but module readers should have > > little > >>>> difficulty if not. > >>>> > >>>> Thanks, Lada > >>>> > >>>>> > >>>>> Thanks, > >>>>> Rob > >>>>> > >>>>> > >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote: > >>>>>> As the author: yes/support. > >>>>>> > >>>>>> Two changes seemed to have support in IETF 98 audience: > >>>>>> > >>>>>> 1. Apart from text/plain, the media type SHOULD be > > text/markdown > >>>>>> (variants permitted). > >>>>>> > >>>>>> 2. The "text-media-type" extension can appear anywhere in a > >>> (sub)module, > >>>>>> and will be scoped to the parent statement and its substaments > > (unless > >>>>>> overriden). > >>>>>> > >>>>>> Lada > >>>>>> > >>>>>> Kent Watsen writes: > >>>>>> > >>>>>>> All, > >>>>>>> > >>>>>>> This is start of a two-week poll on making the following draft > > a > >>>>>>> NETMOD working group document: > >>>>>>> > >>>>>>> draft-lhotka-netmod-yang-markup-00 > >>>>>>> > >>>>>>> Please send email to the list indicating "yes/support" or > > "no/do not > >>>>>>> support". If indicating no, please state your reservations > > with the > >>>>>>> document. If yes, please also feel free to provide comments > > you'd > >>>>>>> like to see addressed once the document is a WG document. > >>>>>>> > >>>>>>> Thank you, > >>>>>>> NETMOD WG Chairs > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> netmod mailing list > >>>>>>> netmod@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>> > >>>> > >>>> -- > >>>> Ladislav Lhotka, CZ.NIC Labs > >>>> PGP Key ID: 0xB8F92B08A9F76C67 > >>>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > > > > > > ------------------------------------------------------------------------ > > -------- > > > > > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --f403045f1a469b8331054d0e8a43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 13 Apr 2017, at 13:34, t.petch <ietfc@btconnect.com> wrote:
>
>
> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> Sent: Wednesday, April 12, 2017 5:44 PM
>
>> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <
>> j.schoenwa= elder@jacobs-university.de> wrote:
>>
>>> I think it is crucial that descriptions etc. remain human read= able
>>> using plain text readers. Having to run a renderer to make sen= se out
>>> of descriptions etc. would be a big failure and things are eve= n
> worse
>>> if modules use different dialects all over the place.
>>>
>>> I believe there is way more important work to get done than th= is
> (and
>>> I fear endless discussions about which adapted subsets of mark= down
> or
>>> (whatever comes next) to use). I do not object this work, but = I also
>>> do not support it at this point in time.
>>>
>>>
>> +1
>>
>> IMO this makes YANG less readable, especially without any agreemen= t
>> on the specific markup supported. A YANG module should be readable= by
> humans
>> without any special tools required.
>
> I agree.=C2=A0 I would say that if you cannot say it in text/plain, th= en you
> probably should not be saying it (something I would extend to e-mail b= ut
> realise that I am less likely to get support there:-)

OK, so if somebody writes

leaf foo {
=C2=A0 =C2=A0 description "This is my *favourite* leaf.";
=C2=A0 =C2=A0 type string;
}


Your premise is that the description-s= tmt is for the
benefit of the model writer, not the model reader.=
Since YANG explicitly states this statement contains a human-rea= dable
string, it seems clear the benefit to the readers is more i= mportant.


you may not like it, but it is absolutely legal and IMO also readable by hu= mans. As William previously mentioned, some communities are already doing s= imilar things. The principal aim of my I-D is to allow module authors to ex= plicitly state that they adhere to some rules, which helps authors of tools= reduce guesswork.


You may decide to ignore the intent of= the description-stmt.
That doesn't mean we should change the= definition in the standard.
IMO plain text is human-readable.=C2= =A0 Anything that requires parsing,
reinterpreting and re-renderi= ng is not human friendly.

=C2=A0
The example with email is actually very relevant. I would also love if peop= le and MUAs only used plain text but, as you say, this is not going to happ= en. If we accept this as a fact, is it better or worse for interoperability= that MUAs provide media type in mail headers?

Lada

Andy
=C2=A0

>
> Tom Petch
>
>>> /js
>>>
>>>
>> Andy
>>
>>
>>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrot= e:
>>>> Robert Wilton <rwi= lton@cisco.com> writes:
>>>>
>>>>> Yes/support.=C2=A0 But with the condition that I would= still like the
> draft
>>>>> to define a basic common subset of markdown fields/ann= otations
> that
>>>>> implementations would be expected to support.=C2=A0 Fo= r clarity, I'm
> not
>>>>> suggesting that the draft should define a new markdown= language,
> I
>>> think
>>>>> that it would be better to use an existing markdown la= nguage,
> but
>>>>> perhaps simplified.
>>>>
>>>> In my view, this needs to remain purely optional, so
> implementations
>>>> won't be expected to support anything. It should be pe= rfectly fine
> to
>>>> leave description texts unprocessed, or process only selec= ted
>>>> constructs.
>>>>
>>>>>
>>>>> I want to avoid the scenario where each group of YANG = modelers
> could
>>>>> decide to use a different incompatible variant of text= /markdown,
> and
>>>>> hence generic tools would not be able to reliably rend= er the
> markup for
>>>>> a generic YANG module.
>>>>
>>>> On the other hand, particular markup conventions might be = dictated
> by
>>>> external circumstances. For example, for modules hosted at= GitHub,
> the
>>>> GFM variant of text/markdown looks like a natural choice b= ut
> elsewhere
>>>> it can be something different. William also suggested that= certain
>>>> YANG-specific constructs may also be introduced.
>>>>
>>>>>
>>>>> Care would need to be taken with which variant of the = Markdown
> language
>>>>> is chosen as a base (RFC 7764 may be of use) .=C2=A0 E= .g. the github
> markup
>>>>> language has been previously suggested, but the specif= ication
> document
>>>>> for that variant is long (approx 120 pages).
>>>>
>>>> RFC 7763 also notes that markdown itself by design has no = concept
> of
>>>> validity, so I think it is appropriate to take it easy and= avoid
>>>> overspecifying things.
>>>>
>>>> I guess the key point here is "lighweight markup"= ;: if and
> implementation
>>>> can make use of it, then fine, but module readers should h= ave
> little
>>>> difficulty if not.
>>>>
>>>> Thanks, Lada
>>>>
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote:
>>>>>> As the author: yes/support.
>>>>>>
>>>>>> Two changes seemed to have support in IETF 98 audi= ence:
>>>>>>
>>>>>> 1. Apart from text/plain, the media type SHOULD be=
> text/markdown
>>>>>> (variants permitted).
>>>>>>
>>>>>> 2. The "text-media-type" extension can a= ppear anywhere in a
>>> (sub)module,
>>>>>> and will be scoped to the parent statement and its= substaments
> (unless
>>>>>> overriden).
>>>>>>
>>>>>> Lada
>>>>>>
>>>>>> Kent Watsen <kwatsen@juniper.net> writes:
>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> This is start of a two-week poll on making the= following draft
> a
>>>>>>> NETMOD working group document:
>>>>>>>
>>>>>>>=C2=A0 =C2=A0draft-lhotka-netmod-yang-mark= up-00
>>>>>>>
>>>>>>> Please send email to the list indicating "= ;yes/support" or
> "no/do not
>>>>>>> support".=C2=A0 If indicating no, please = state your reservations
> with the
>>>>>>> document.=C2=A0 If yes, please also feel free = to provide comments
> you'd
>>>>>>> like to see addressed once the document is a W= G document.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> NETMOD WG Chairs
>>>>>>>
>>>>>>>
>>>>>>> _________________________________________= ______
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf= .org
>>>>>>> https://www.ietf.org/mailma= n/listinfo/netmod
>>>>>
>>>>
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listi= nfo/netmod
>>>
>>> --
>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campu= s Ring 1 | 28759 Bremen |
> Germany
>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/netmod
>>>
>>
>
>
> ------------------------------------------------------------= ------------
> --------
>
>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netm= od

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67






--f403045f1a469b8331054d0e8a43-- From nobody Thu Apr 13 11:42:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E37D12EB26; Thu, 13 Apr 2017 11:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 Jr2akk4G_xFV; Thu, 13 Apr 2017 11:41:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C050129A8B; Thu, 13 Apr 2017 11:41:58 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:8841:54a3:f68c:6e22] (unknown [IPv6:2a01:5e0:29:ffff:8841:54a3:f68c:6e22]) by mail.nic.cz (Postfix) with ESMTPSA id AE25062D8C; Thu, 13 Apr 2017 20:41:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492108916; bh=hiTNQ/WD01mDs6QZoPgTA1DP1BXobyz7RJb+h/BiMzU=; h=From:Date:To; b=SmMd14xXHW4xaZFJVdv3LIAlPI+GkenUicfJ43ux9NaUokaRBXEPTcmoWkhJR2ib/ 4aHY77Ial/DzxJCgNLzF0R60hytJR2RvSuK01DG+7pzYAZjMSeIcdz6i3oZggaIDng ZV9nDBuvsshE20+jJT44O2kQG5OWv4QlQgVYuoRQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 13 Apr 2017 20:41:55 +0200 Cc: "t.petch" , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , NETMOD WG , NetMod WG Chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 18:42:03 -0000 > On 13 Apr 2017, at 18:08, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka = wrote: >=20 > > On 13 Apr 2017, at 13:34, t.petch wrote: > > > > > > ----- Original Message ----- > > From: "Andy Bierman" > > Sent: Wednesday, April 12, 2017 5:44 PM > > > >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> I think it is crucial that descriptions etc. remain human readable > >>> using plain text readers. Having to run a renderer to make sense = out > >>> of descriptions etc. would be a big failure and things are even > > worse > >>> if modules use different dialects all over the place. > >>> > >>> I believe there is way more important work to get done than this > > (and > >>> I fear endless discussions about which adapted subsets of markdown > > or > >>> (whatever comes next) to use). I do not object this work, but I = also > >>> do not support it at this point in time. > >>> > >>> > >> +1 > >> > >> IMO this makes YANG less readable, especially without any agreement > >> on the specific markup supported. A YANG module should be readable = by > > humans > >> without any special tools required. > > > > I agree. I would say that if you cannot say it in text/plain, then = you > > probably should not be saying it (something I would extend to e-mail = but > > realise that I am less likely to get support there:-) >=20 > OK, so if somebody writes >=20 > leaf foo { > description "This is my *favourite* leaf."; > type string; > } >=20 >=20 > Your premise is that the description-stmt is for the > benefit of the model writer, not the model reader. My premise is that such *lightweight* markup is being used and will be = used. So it is better to be prepared, and accomodate it in an acceptable = form, rather than fight it. And I explicitly want to avoid standardizing a particular markup format, = at this stage at least. > Since YANG explicitly states this statement contains a human-readable > string, it seems clear the benefit to the readers is more important. What exactly is non-human-readable in my example? Moreover, different communities may want to add e.g. metadata in a = certain formalized format. To some extent, we already do it in the = initial decription of our modules. IMO there is nothing wrong on = specifying the format that is being used. =20 >=20 >=20 > you may not like it, but it is absolutely legal and IMO also readable = by humans. As William previously mentioned, some communities are already = doing similar things. The principal aim of my I-D is to allow module = authors to explicitly state that they adhere to some rules, which helps = authors of tools reduce guesswork. >=20 >=20 > You may decide to ignore the intent of the description-stmt. > That doesn't mean we should change the definition in the standard. > IMO plain text is human-readable. Anything that requires parsing, > reinterpreting and re-rendering is not human friendly. My draft doesn't propose anything like this. Lightweight markup such as = markdown doesn't require parsing, and is as human-readable as anything = else. Lada >=20 > =20 > The example with email is actually very relevant. I would also love if = people and MUAs only used plain text but, as you say, this is not going = to happen. If we accept this as a fact, is it better or worse for = interoperability that MUAs provide media type in mail headers? >=20 > Lada >=20 > Andy > =20 >=20 > > > > Tom Petch > > > >>> /js > >>> > >>> > >> Andy > >> > >> > >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > >>>> Robert Wilton writes: > >>>> > >>>>> Yes/support. But with the condition that I would still like the > > draft > >>>>> to define a basic common subset of markdown fields/annotations > > that > >>>>> implementations would be expected to support. For clarity, I'm > > not > >>>>> suggesting that the draft should define a new markdown language, > > I > >>> think > >>>>> that it would be better to use an existing markdown language, > > but > >>>>> perhaps simplified. > >>>> > >>>> In my view, this needs to remain purely optional, so > > implementations > >>>> won't be expected to support anything. It should be perfectly = fine > > to > >>>> leave description texts unprocessed, or process only selected > >>>> constructs. > >>>> > >>>>> > >>>>> I want to avoid the scenario where each group of YANG modelers > > could > >>>>> decide to use a different incompatible variant of text/markdown, > > and > >>>>> hence generic tools would not be able to reliably render the > > markup for > >>>>> a generic YANG module. > >>>> > >>>> On the other hand, particular markup conventions might be = dictated > > by > >>>> external circumstances. For example, for modules hosted at = GitHub, > > the > >>>> GFM variant of text/markdown looks like a natural choice but > > elsewhere > >>>> it can be something different. William also suggested that = certain > >>>> YANG-specific constructs may also be introduced. > >>>> > >>>>> > >>>>> Care would need to be taken with which variant of the Markdown > > language > >>>>> is chosen as a base (RFC 7764 may be of use) . E.g. the github > > markup > >>>>> language has been previously suggested, but the specification > > document > >>>>> for that variant is long (approx 120 pages). > >>>> > >>>> RFC 7763 also notes that markdown itself by design has no concept > > of > >>>> validity, so I think it is appropriate to take it easy and avoid > >>>> overspecifying things. > >>>> > >>>> I guess the key point here is "lighweight markup": if and > > implementation > >>>> can make use of it, then fine, but module readers should have > > little > >>>> difficulty if not. > >>>> > >>>> Thanks, Lada > >>>> > >>>>> > >>>>> Thanks, > >>>>> Rob > >>>>> > >>>>> > >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote: > >>>>>> As the author: yes/support. > >>>>>> > >>>>>> Two changes seemed to have support in IETF 98 audience: > >>>>>> > >>>>>> 1. Apart from text/plain, the media type SHOULD be > > text/markdown > >>>>>> (variants permitted). > >>>>>> > >>>>>> 2. The "text-media-type" extension can appear anywhere in a > >>> (sub)module, > >>>>>> and will be scoped to the parent statement and its substaments > > (unless > >>>>>> overriden). > >>>>>> > >>>>>> Lada > >>>>>> > >>>>>> Kent Watsen writes: > >>>>>> > >>>>>>> All, > >>>>>>> > >>>>>>> This is start of a two-week poll on making the following draft > > a > >>>>>>> NETMOD working group document: > >>>>>>> > >>>>>>> draft-lhotka-netmod-yang-markup-00 > >>>>>>> > >>>>>>> Please send email to the list indicating "yes/support" or > > "no/do not > >>>>>>> support". If indicating no, please state your reservations > > with the > >>>>>>> document. If yes, please also feel free to provide comments > > you'd > >>>>>>> like to see addressed once the document is a WG document. > >>>>>>> > >>>>>>> Thank you, > >>>>>>> NETMOD WG Chairs > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> netmod mailing list > >>>>>>> netmod@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > >>>>> > >>>> > >>>> -- > >>>> Ladislav Lhotka, CZ.NIC Labs > >>>> PGP Key ID: 0xB8F92B08A9F76C67 > >>>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > > > > > > = ------------------------------------------------------------------------ > > -------- > > > > > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 13 13:33:02 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91CF12951C for ; Thu, 13 Apr 2017 13:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmImGBlbIpjR for ; Thu, 13 Apr 2017 13:32:59 -0700 (PDT) Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 70B3112943E for ; Thu, 13 Apr 2017 13:32:59 -0700 (PDT) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0C8631E07D0 for ; Thu, 13 Apr 2017 14:32:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 7wYv1v00U2SSUrH01wYylx; Thu, 13 Apr 2017 14:32:59 -0600 X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=Hv_YnvB0JoLW7w7YuRUA:9 a=pILNOxqGKmIA:10 a=rKrVYePj7rwA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=D1hgCnkmjWrY5pkjR35RPMhtFgMA/5SD/tJxLHaATKI=; b=V3AwMB2rFEV5cAUMGgO6uTOWeR BbVws0Av/eMKHZzMpQRZ+gRphTUHd8HpUM3fp7oOEcV5dAl9wcmA1K1O+AUNYsu6mGqHWS8mfqrld dGXP6DTs56sCkYJy769gIq9JS; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:41496 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cylQF-0003r0-Bc; Thu, 13 Apr 2017 14:32:55 -0600 To: Kent Watsen , "netmod@ietf.org" References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Cc: "netmod-chairs@ietf.org" From: Lou Berger Message-ID: Date: Thu, 13 Apr 2017 16:32:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cylQF-0003r0-Bc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:41496 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 20:33:01 -0000 Hi, As contributor: I don't know of any IPR on this document, and support its adoption. Lou On 4/7/2017 7:22 PM, Kent Watsen wrote: > All, > > This is start of a two-week poll on making the following draft a > NETMOD working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Apr 13 16:42:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967B912EB49 for ; Thu, 13 Apr 2017 16:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBcbBBgYiYOl for ; Thu, 13 Apr 2017 16:42:30 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8BA129AD0 for ; Thu, 13 Apr 2017 16:42:29 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id u2so56606638wmu.0 for ; Thu, 13 Apr 2017 16:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t4i9UlzEh8gG3/Q/UaEphJcUkc4HAYW6LJCo4P6Zf+0=; b=mj2w26m9SzMsrghI7c/KkrhlK1ZEqQdJ74bpYLwRCfVyqWMUNtBunCEB2ZvdNEMuJ3 AuGKkbfuCadpWxerKELLXRCfe9Rcmt0wqZZWcrmKyikKV+kCJGyzAATbjXlp0vIAY/Md M54rAg+9vE/blFDwqYWIZ/d1E887Ul6B/DK/FOH1dUHY0P42VgMG1SyQNWVYclmoUQFa 3fm6C9etK6CLPmloWUjOc7eQ1cpFu5QIbXBKnaL+VDYvfS66ByHgG+5Q0W8REAtUVhZX 42cfC906ZQjc3T3IHti9wj0PXv5n/hQnDm/CRMlfBzXg3u9txckg5wNZpTci9PWdePmH zypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t4i9UlzEh8gG3/Q/UaEphJcUkc4HAYW6LJCo4P6Zf+0=; b=nx6nOsszqHJgjUTsJsob/v25GoQenfqecR2RUnBP0ItmH3qh4jKjCx1rf6G4elgXXa zhtIkX/Tm1wd7h+PkgG4jpC5sxgEMOpkWS7SnDgCgnZHbKWI3VKrDGN5XO+/Ci0a59bO sNKQJtUMAA6eaZ8H6hjiGfev7uqCTQaAQ/CbxquBAYyLWGobfunCT9WYFx66Bjb0xZUh nnb4qBCTLB1tmO59s0hmuSLzt9/hFeYVbeLeU5z2E/nYoOKd98GqPcI56roLtqCyyPW8 IN3jooQm9l5Rd1PF7Bu+mCT2RfktLOMU9CDPQpAzA7WVO7LUVcPmnFF68MtcwuK2PlGL kXRQ== X-Gm-Message-State: AN3rC/5ubM2/0Lou2sTkXKY3u1riRZNqL39UioXgROhuwHCF7SAo2ZpR H+GT65LdFgX/qRhDRpnZB7TLYxWUEA== X-Received: by 10.28.46.213 with SMTP id u204mr5100200wmu.136.1492126948087; Thu, 13 Apr 2017 16:42:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Thu, 13 Apr 2017 16:42:27 -0700 (PDT) In-Reply-To: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> From: Andy Bierman Date: Thu, 13 Apr 2017 16:42:27 -0700 Message-ID: To: Ladislav Lhotka Cc: "t.petch" , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Robert Wilton , Kent Watsen , NETMOD WG , NetMod WG Chairs Content-Type: multipart/alternative; boundary=001a11497aceb36b56054d14e09a Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 23:42:32 -0000 --001a11497aceb36b56054d14e09a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 13, 2017 at 11:41 AM, Ladislav Lhotka wrote: > > > On 13 Apr 2017, at 18:08, Andy Bierman wrote: > > > > > > > > On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka wrote: > > > > > On 13 Apr 2017, at 13:34, t.petch wrote: > > > > > > > > > ----- Original Message ----- > > > From: "Andy Bierman" > > > Sent: Wednesday, April 12, 2017 5:44 PM > > > > > >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > >>> I think it is crucial that descriptions etc. remain human readable > > >>> using plain text readers. Having to run a renderer to make sense out > > >>> of descriptions etc. would be a big failure and things are even > > > worse > > >>> if modules use different dialects all over the place. > > >>> > > >>> I believe there is way more important work to get done than this > > > (and > > >>> I fear endless discussions about which adapted subsets of markdown > > > or > > >>> (whatever comes next) to use). I do not object this work, but I also > > >>> do not support it at this point in time. > > >>> > > >>> > > >> +1 > > >> > > >> IMO this makes YANG less readable, especially without any agreement > > >> on the specific markup supported. A YANG module should be readable by > > > humans > > >> without any special tools required. > > > > > > I agree. I would say that if you cannot say it in text/plain, then you > > > probably should not be saying it (something I would extend to e-mail > but > > > realise that I am less likely to get support there:-) > > > > OK, so if somebody writes > > > > leaf foo { > > description "This is my *favourite* leaf."; > > type string; > > } > > > > > > Your premise is that the description-stmt is for the > > benefit of the model writer, not the model reader. > > My premise is that such *lightweight* markup is being used and will be > used. So it is better to be prepared, and accomodate it in an acceptable > form, rather than fight it. > You mean there are YANG RFCs that contain markup in description-stmts? Indicating that both the IESG and RFC Editor have approved this practice? If not, then such markup is not actually being used in published YANG modules. > And I explicitly want to avoid standardizing a particular markup format, > at this stage at least. > > > That means the burden is on the YANG reader to be aware of every possible markup variant anybody might want to use. Of course the user must understand the "extra" chars thrown in with the plain English. One cannot assume it will be obvious to every reader which chars are extra, especially with no constraints at all on the markup syntax and semantics. Andy > > Since YANG explicitly states this statement contains a human-readable > > string, it seems clear the benefit to the readers is more important. > > What exactly is non-human-readable in my example? > > Moreover, different communities may want to add e.g. metadata in a certain > formalized format. To some extent, we already do it in the initial > decription of our modules. IMO there is nothing wrong on specifying the > format that is being used. > > > > > > > you may not like it, but it is absolutely legal and IMO also readable by > humans. As William previously mentioned, some communities are already doing > similar things. The principal aim of my I-D is to allow module authors to > explicitly state that they adhere to some rules, which helps authors of > tools reduce guesswork. > > > > > > You may decide to ignore the intent of the description-stmt. > > That doesn't mean we should change the definition in the standard. > > IMO plain text is human-readable. Anything that requires parsing, > > reinterpreting and re-rendering is not human friendly. > > My draft doesn't propose anything like this. Lightweight markup such as > markdown doesn't require parsing, and is as human-readable as anything else. > > Lada > > > > > > > The example with email is actually very relevant. I would also love if > people and MUAs only used plain text but, as you say, this is not going to > happen. If we accept this as a fact, is it better or worse for > interoperability that MUAs provide media type in mail headers? > > > > Lada > > > > Andy > > > > > > > > > > Tom Petch > > > > > >>> /js > > >>> > > >>> > > >> Andy > > >> > > >> > > >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: > > >>>> Robert Wilton writes: > > >>>> > > >>>>> Yes/support. But with the condition that I would still like the > > > draft > > >>>>> to define a basic common subset of markdown fields/annotations > > > that > > >>>>> implementations would be expected to support. For clarity, I'm > > > not > > >>>>> suggesting that the draft should define a new markdown language, > > > I > > >>> think > > >>>>> that it would be better to use an existing markdown language, > > > but > > >>>>> perhaps simplified. > > >>>> > > >>>> In my view, this needs to remain purely optional, so > > > implementations > > >>>> won't be expected to support anything. It should be perfectly fine > > > to > > >>>> leave description texts unprocessed, or process only selected > > >>>> constructs. > > >>>> > > >>>>> > > >>>>> I want to avoid the scenario where each group of YANG modelers > > > could > > >>>>> decide to use a different incompatible variant of text/markdown, > > > and > > >>>>> hence generic tools would not be able to reliably render the > > > markup for > > >>>>> a generic YANG module. > > >>>> > > >>>> On the other hand, particular markup conventions might be dictated > > > by > > >>>> external circumstances. For example, for modules hosted at GitHub, > > > the > > >>>> GFM variant of text/markdown looks like a natural choice but > > > elsewhere > > >>>> it can be something different. William also suggested that certain > > >>>> YANG-specific constructs may also be introduced. > > >>>> > > >>>>> > > >>>>> Care would need to be taken with which variant of the Markdown > > > language > > >>>>> is chosen as a base (RFC 7764 may be of use) . E.g. the github > > > markup > > >>>>> language has been previously suggested, but the specification > > > document > > >>>>> for that variant is long (approx 120 pages). > > >>>> > > >>>> RFC 7763 also notes that markdown itself by design has no concept > > > of > > >>>> validity, so I think it is appropriate to take it easy and avoid > > >>>> overspecifying things. > > >>>> > > >>>> I guess the key point here is "lighweight markup": if and > > > implementation > > >>>> can make use of it, then fine, but module readers should have > > > little > > >>>> difficulty if not. > > >>>> > > >>>> Thanks, Lada > > >>>> > > >>>>> > > >>>>> Thanks, > > >>>>> Rob > > >>>>> > > >>>>> > > >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote: > > >>>>>> As the author: yes/support. > > >>>>>> > > >>>>>> Two changes seemed to have support in IETF 98 audience: > > >>>>>> > > >>>>>> 1. Apart from text/plain, the media type SHOULD be > > > text/markdown > > >>>>>> (variants permitted). > > >>>>>> > > >>>>>> 2. The "text-media-type" extension can appear anywhere in a > > >>> (sub)module, > > >>>>>> and will be scoped to the parent statement and its substaments > > > (unless > > >>>>>> overriden). > > >>>>>> > > >>>>>> Lada > > >>>>>> > > >>>>>> Kent Watsen writes: > > >>>>>> > > >>>>>>> All, > > >>>>>>> > > >>>>>>> This is start of a two-week poll on making the following draft > > > a > > >>>>>>> NETMOD working group document: > > >>>>>>> > > >>>>>>> draft-lhotka-netmod-yang-markup-00 > > >>>>>>> > > >>>>>>> Please send email to the list indicating "yes/support" or > > > "no/do not > > >>>>>>> support". If indicating no, please state your reservations > > > with the > > >>>>>>> document. If yes, please also feel free to provide comments > > > you'd > > >>>>>>> like to see addressed once the document is a WG document. > > >>>>>>> > > >>>>>>> Thank you, > > >>>>>>> NETMOD WG Chairs > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> netmod mailing list > > >>>>>>> netmod@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod > > >>>>> > > >>>> > > >>>> -- > > >>>> Ladislav Lhotka, CZ.NIC Labs > > >>>> PGP Key ID: 0xB8F92B08A9F76C67 > > >>>> > > >>>> _______________________________________________ > > >>>> netmod mailing list > > >>>> netmod@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > >>> -- > > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > >>> Fax: +49 421 200 3103 > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netmod > > >>> > > >> > > > > > > > > > ------------------------------------------------------------ > ------------ > > > -------- > > > > > > > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org > > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a11497aceb36b56054d14e09a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 13, 2017 at 11:41 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

> On 13 Apr 2017, at 18:08, Andy Bierman <andy@yumaworks.com> wrote:
>
>
>
> On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 13 Apr 2017, at 13:34, t.petch <ietfc@btconnect.com> wrote:
> >
> >
> > ----- Original Message -----
> > From: "Andy Bierman" <andy@yumaworks.com>
> > Sent: Wednesday, April 12, 2017 5:44 PM
> >
> >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > >> j.sch= oenwaelder@jacobs-university.de> wrote:
> >>
> >>> I think it is crucial that descriptions etc. remain human= readable
> >>> using plain text readers. Having to run a renderer to mak= e sense out
> >>> of descriptions etc. would be a big failure and things ar= e even
> > worse
> >>> if modules use different dialects all over the place.
> >>>
> >>> I believe there is way more important work to get done th= an this
> > (and
> >>> I fear endless discussions about which adapted subsets of= markdown
> > or
> >>> (whatever comes next) to use). I do not object this work,= but I also
> >>> do not support it at this point in time.
> >>>
> >>>
> >> +1
> >>
> >> IMO this makes YANG less readable, especially without any agr= eement
> >> on the specific markup supported. A YANG module should be rea= dable by
> > humans
> >> without any special tools required.
> >
> > I agree.=C2=A0 I would say that if you cannot say it in text/plai= n, then you
> > probably should not be saying it (something I would extend to e-m= ail but
> > realise that I am less likely to get support there:-)
>
> OK, so if somebody writes
>
> leaf foo {
>=C2=A0 =C2=A0 =C2=A0description "This is my *favourite* leaf."= ;;
>=C2=A0 =C2=A0 =C2=A0type string;
> }
>
>
> Your premise is that the description-stmt is for the
> benefit of the model writer, not the model reader.

My premise is that such *lightweight* markup is being used and will be used= . So it is better to be prepared, and accomodate it in an acceptable form, = rather than fight it.


Yo= u mean there are YANG RFCs that contain markup in =C2=A0description-stmts?<= /div>
Indicating that both the IESG and RFC Editor have approved this p= ractice?
If not, then such markup is not actually being used in p= ublished YANG modules.



And I explicitly want to avoid standardizing a particular markup format, at= this stage at least.



That means the burden is on the YANG r= eader to be aware of every possible
markup variant anybody might = want to use.=C2=A0 Of course the user must understand
the "e= xtra" chars thrown in with the plain English. One cannot assume it wil= l
be obvious to every reader which chars are extra, especially wi= th no constraints
at all on the markup syntax and semantics.


Andy


=C2=A0
> Since YANG explicitly states this statement contains a human-readable<= br> > string, it seems clear the benefit to the readers is more important.
What exactly is non-human-readable in my example?

Moreover, different communities may want to add e.g. metadata in a certain = formalized format. To some extent, we already do it in the initial decripti= on of our modules. IMO there is nothing wrong on specifying the format that= is being used.

>
>
> you may not like it, but it is absolutely legal and IMO also readable = by humans. As William previously mentioned, some communities are already do= ing similar things. The principal aim of my I-D is to allow module authors = to explicitly state that they adhere to some rules, which helps authors of = tools reduce guesswork.
>
>
> You may decide to ignore the intent of the description-stmt.
> That doesn't mean we should change the definition in the standard.=
> IMO plain text is human-readable.=C2=A0 Anything that requires parsing= ,
> reinterpreting and re-rendering is not human friendly.

My draft doesn't propose anything like this. Lightweight markup such as= markdown doesn't require parsing, and is as human-readable as anything= else.

Lada

>
>
> The example with email is actually very relevant. I would also love if= people and MUAs only used plain text but, as you say, this is not going to= happen. If we accept this as a fact, is it better or worse for interoperab= ility that MUAs provide media type in mail headers?
>
> Lada
>
> Andy
>
>
> >
> > Tom Petch
> >
> >>> /js
> >>>
> >>>
> >> Andy
> >>
> >>
> >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka= wrote:
> >>>> Robert Wilton <rwilton@cisco.com> writes:
> >>>>
> >>>>> Yes/support.=C2=A0 But with the condition that I = would still like the
> > draft
> >>>>> to define a basic common subset of markdown field= s/annotations
> > that
> >>>>> implementations would be expected to support.=C2= =A0 For clarity, I'm
> > not
> >>>>> suggesting that the draft should define a new mar= kdown language,
> > I
> >>> think
> >>>>> that it would be better to use an existing markdo= wn language,
> > but
> >>>>> perhaps simplified.
> >>>>
> >>>> In my view, this needs to remain purely optional, so<= br> > > implementations
> >>>> won't be expected to support anything. It should = be perfectly fine
> > to
> >>>> leave description texts unprocessed, or process only = selected
> >>>> constructs.
> >>>>
> >>>>>
> >>>>> I want to avoid the scenario where each group of = YANG modelers
> > could
> >>>>> decide to use a different incompatible variant of= text/markdown,
> > and
> >>>>> hence generic tools would not be able to reliably= render the
> > markup for
> >>>>> a generic YANG module.
> >>>>
> >>>> On the other hand, particular markup conventions migh= t be dictated
> > by
> >>>> external circumstances. For example, for modules host= ed at GitHub,
> > the
> >>>> GFM variant of text/markdown looks like a natural cho= ice but
> > elsewhere
> >>>> it can be something different. William also suggested= that certain
> >>>> YANG-specific constructs may also be introduced.
> >>>>
> >>>>>
> >>>>> Care would need to be taken with which variant of= the Markdown
> > language
> >>>>> is chosen as a base (RFC 7764 may be of use) .=C2= =A0 E.g. the github
> > markup
> >>>>> language has been previously suggested, but the s= pecification
> > document
> >>>>> for that variant is long (approx 120 pages).
> >>>>
> >>>> RFC 7763 also notes that markdown itself by design ha= s no concept
> > of
> >>>> validity, so I think it is appropriate to take it eas= y and avoid
> >>>> overspecifying things.
> >>>>
> >>>> I guess the key point here is "lighweight markup= ": if and
> > implementation
> >>>> can make use of it, then fine, but module readers sho= uld have
> > little
> >>>> difficulty if not.
> >>>>
> >>>> Thanks, Lada
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Rob
> >>>>>
> >>>>>
> >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote:
> >>>>>> As the author: yes/support.
> >>>>>>
> >>>>>> Two changes seemed to have support in IETF 98= audience:
> >>>>>>
> >>>>>> 1. Apart from text/plain, the media type SHOU= LD be
> > text/markdown
> >>>>>> (variants permitted).
> >>>>>>
> >>>>>> 2. The "text-media-type" extension = can appear anywhere in a
> >>> (sub)module,
> >>>>>> and will be scoped to the parent statement an= d its substaments
> > (unless
> >>>>>> overriden).
> >>>>>>
> >>>>>> Lada
> >>>>>>
> >>>>>> Kent Watsen <kwatsen@juniper.net> writes:
> >>>>>>
> >>>>>>> All,
> >>>>>>>
> >>>>>>> This is start of a two-week poll on makin= g the following draft
> > a
> >>>>>>> NETMOD working group document:
> >>>>>>>
> >>>>>>>=C2=A0 =C2=A0draft-lhotka-netmod-yang-markup-00
> >>>>>>>
> >>>>>>> Please send email to the list indicating = "yes/support" or
> > "no/do not
> >>>>>>> support".=C2=A0 If indicating no, pl= ease state your reservations
> > with the
> >>>>>>> document.=C2=A0 If yes, please also feel = free to provide comments
> > you'd
> >>>>>>> like to see addressed once the document i= s a WG document.
> >>>>>>>
> >>>>>>> Thank you,
> >>>>>>> NETMOD WG Chairs
> >>>>>>>
> >>>>>>>
> >>>>>>> ____________________________________= ___________
> >>>>>>> netmod mailing list
> >>>>>>> netmod= @ietf.org
> >>>>>>> https://www.ietf.org/m= ailman/listinfo/netmod
> >>>>>
> >>>>
> >>>> --
> >>>> Ladislav Lhotka, CZ.NIC Labs
> >>>> PGP Key ID: 0xB8F92B08A9F76C67
> >>>>
> >>>> _______________________________________________<= br> > >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/= listinfo/netmod
> >>>
> >>> --
> >>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
> >>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Campus Ring 1 | 28759 Bremen |
> > Germany
> >>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/list= info/netmod
> >>>
> >>
> >
> >
> > ------------------------------------------------------------= ------------
> > --------
> >
> >
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinf= o/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67






--001a11497aceb36b56054d14e09a-- From nobody Thu Apr 13 17:34:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0E12EB61 for ; Thu, 13 Apr 2017 17:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUbri-9VO2mQ for ; Thu, 13 Apr 2017 17:34:28 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5F12EB5F for ; Thu, 13 Apr 2017 17:34:27 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 82C2E5BD22; Fri, 14 Apr 2017 00:34:26 +0000 (UTC) Date: Fri, 14 Apr 2017 00:34:26 +0000 From: heasley To: netmod@ietf.org Message-ID: <20170414003426.GO2149@shrubbery.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3768EA5B-2691-4854-A8F7-5C07410956E2@nic.cz> User-Agent: Mutt/1.8.0 (2017-02-23) Archived-At: Subject: Re: [netmod] netmod Digest, Vol 109, Issue 17 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 00:34:29 -0000 > > On 13 Apr 2017, at 09:14, Juergen Schoenwaelder wrote: > > > > On Thu, Apr 13, 2017 at 08:28:08AM +0200, Ladislav Lhotka wrote: > >> > >> We are talking past each other. Are you willing to admit that my draft has nothing to do with the *presence* of markup in a description text, as long as it remains a valid YANG string? > >> > > > > I think you do not understand what I am saying. The main purpose of > > description statements etc. is that they are easily to read by humans. > > > > 7.21.3. The "description" Statement > > > > The "description" statement takes as an argument a string that > > contains a human-readable textual description of this definition. > > > > I disagree with your claim that human-readable text is markup. The > > whole RFC series is formatted human-readable text, not markup. I > > believe this work is heading in the wrong direction, it will lead to > > endless discussions of many different flavors of markup used in > > description clauses, and it will harm interoperability at the human > > eye level. > > > > I believe there are way more important problems to work on. I am out > > of this thread (since there is more important work to do). > > I believe your discussion habits are sometimes aggressive and unacceptable. > > Lada I think that Juergen is to the point - and along with Andy is quite correct that this seems like a distraction and unnecessary. From nobody Thu Apr 13 21:03:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777201294BF; Thu, 13 Apr 2017 21:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.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 UXFEXYUmV2Bk; Thu, 13 Apr 2017 21:03:51 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0124.outbound.protection.outlook.com [104.47.41.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0EC1243F6; Thu, 13 Apr 2017 21:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gXEgoY8mJUKGENO/PvqIAysAJAzPVnIMP+6103Pm6QM=; b=i/WCJeJ6D2pu7rL8iY52V5cER6Jlg1WadqnxsPxstvaGzCb55c96KbsBbqeyPRbf8GWxnC20rVAmWMw0zmR3KKfUPmX4x0TIEeWhReRIX07jtXH0pIPLaANzOFcS6X1geKJ4lhKAYVXPu/JmPf+eHN6Y9sPr3PFIWY/XC2d0aAc= Received: from CO2PR05CA015.namprd05.prod.outlook.com (10.141.241.143) by BLUPR05MB531.namprd05.prod.outlook.com (10.141.29.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Fri, 14 Apr 2017 04:03:50 +0000 Received: from BY2NAM05FT055.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by CO2PR05CA015.outlook.office365.com (2a01:111:e400:1429::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Fri, 14 Apr 2017 04:03:49 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT055.mail.protection.outlook.com (10.152.100.192) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Fri, 14 Apr 2017 04:03:49 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 13 Apr 2017 21:03:48 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v3E43lUu009625; Thu, 13 Apr 2017 21:03:47 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v3E3xgwh093454; Thu, 13 Apr 2017 23:59:42 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201704140359.v3E3xgwh093454@idle.juniper.net> To: Ladislav Lhotka CC: t.petch , , NETMOD WG In-Reply-To: <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> Date: Thu, 13 Apr 2017 23:59:42 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(39860400002)(2980300002)(199003)(189002)(9170700003)(77096006)(6246003)(1076002)(7126002)(105596002)(8936002)(38730400002)(110136004)(5660300001)(8666007)(53936002)(230783001)(8276002)(86362001)(81166006)(48376002)(50466002)(6916009)(2950100002)(54356999)(2810700001)(356003)(8676002)(47776003)(50986999)(76506005)(4326008)(53416004)(7696004)(2906002)(189998001)(106466001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB531; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT055; 1:nmc1aYaU9iRHAVTbyUFpknOxXSsXbvYlXa3JGPJv5m3b7YJUADoVC1gyaHANO56OXnosYk8pAKFxvNhbvDsDpviVdfe2ZNd+ck+4CfB2So0AuXfTN5VBdR69TfhQ2qME39sa5frU8LHzhNMQhbE87EWadlAhphck2ngk4XbYftwhtI0+BbMnuokrQOKRZRk1CI7hCgBBFwvcTGav253l4Nl1//zO2ABl3iRb0Zl/ZVDbmf2hpLEu4hx4EWicAhBGlrT/iFTfvfJp1QPhUl50H8nuRjpIjz55r5L77Y3hLZmhWXIKs7yANNpsb5hlLnbjfHJ4SqRLnuBQr+hJhT9eldtA27CNaRIACqrfwLWo5goC36JlffuW3+Ndgj1KiGHtd4p+RmLoJZUuaBYDB338yOO4UWS3km4mQV83ItCPNZ8ixh6DEXVpoFsVCGCip4nfv2+LmKTq0y+VVhccpB2iz0QgPrAsORN+iVe1y6uqpwOU2CQi0iunOY1d71IsGDyx2GVr7s1286TfBLAVjb7aiNfOXgjMIfRChvIAXZ4I7vYImPvkiEdIYJ3ts750Y0uJduP9urtVfroat6T4pEvgNN7u6IgHul0mBwsZaMuYSr2lgmzr+LAzHuRsEUdAoOcn X-MS-Office365-Filtering-Correlation-Id: d659bd56-389c-43c1-ef49-08d482eb41b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB531; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 3:zYwm5cye2fGc44Me3XUljxdvGIRbp0j6iXcQ6zMKVpmZg+ayPF6v6wtPR5E5nj1Dwey/EP8eSADTZAVUqJo95/b+eWyIB2ReEURAalqSoHmk/KGt8zN1d7yrB9r1ZBTViLdKUbYXuJprrIr5/mc5zjqp4u7IxdIN18Bs6xGU07bfpy04QVO3kGAWXQa+ip8w8s+fAkhBeOGiLBPZhz4PisUgsyKLrBA6RNKj/QQGQd6PJ7IlsU4VJAuDZcfMUnLaumtJze8rDo0KEJQRsawbXmAC5kNtHwuYxG3S9YttqUw968drWqMWWIxBA7X8Ses5odi5y//vq2OXaBeflCYlqPrE2aqZ3JEFQ+D3bPVvXUIeEPPP1ynzWu+Ik2ua+w1t955SV65vZRtiipAJ21oZIqefA4rGYlJtja1aZOfwDZX0pNMfjZ886uPrzUF4BKQD9jfejaELBmPtOLvXi0Gjtvz8EkNHdcn6/igzAWNutIjZNkr4ei4Y9kbY4wS87yJm X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 25:RUWUiMXn/BWbV1lx1M4R6mjKMuqykznB36htzxuD+BHxuHvtY9Xeec2GM6AhIEwTx/QKjXRXmRFoBsXOdwllz/MO7kgSmQMHzpzdo1U3Papb8+qgexfi6gGPXrJpqlSmaJeegH4GiHOHZLs4qbzCj6gqIGLeqGtk3M/Yfu3CqAsuiiJfPW4QaaFaDhFEvogeUQT5LD3HzYPxG+u6DXKmAXFu0d1FbH+pM6cLrr7FzgrVXLGtw7axZYAnCZtENfEswvr1lzreJzVxqyLnpThEq1nI0ORP+/CqqiSkKooKF9Ve69gGT+1IUgNPj+kzpoIuDzaiT9NLfkpQxwvxw3HLGJgSmWll+ptTqGJGhBwjzYs9eQEeoJq2Ey0Hf1aXTIzAn2TgsT6Uub+aRShZ8iWgjZTVuJ8gZnQ03cWvEffo2nhd9JFtYEgoINlAMWBV7MuC6qNgvCPY/TfDFLeu8K3Lyw==; 31:ZHCely4ERPkU9HF464lyjGJfR1bvSbtK1bMcj6u5mj2JRMb03NHRxXUlyJB+cuaQizurFTWACGrUcxfe872hF4brsftd4TkdKao65IcTNlVzig8meAUT9P4n9KLxU9k0zxwnk45w/IaS57MAhek/giwb6sjl2WnJ5k6/Dnb8xu5Q5PRP2ni0NWp1E3xZGV8SnQUqHwLxsERyf68B9HeGJe2Nc0Tp7fMtt7SE4pcsc6nmNUXxZMCHqWiIITOQuXDxTmAlXwRaNmYbd9ORGw3tMX59WREhaJ31G11kxe0XP04= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 20:7EXmZurlXRz/7kNMNCB7DjdjSll7X0lNdgH4Heh3RDW++4t8DbTbjmzImHKkdWcympluFBrZHdmXbTH4aa0i7rGk51f8GqUfNOhq5KHrphfztTbVnQgHzPKxryRv3n5ZSRST2GCuIWP7mCfl81viIAALY0Zo3SfVhpvEKlKMXnppieDQUSj5xT0NkTqv1vp9G6beKfmUICHshlAnFk5BgxdFg+qtKojokdc+EKVyTrwEkZqINjMbJv/OmCXwEU+L4xw/bVSsi6xU+pr6ppAwAjOKFwxskPDin+I9Cp3ibbTap3DhMRaWD31PKRB2KBUcSOluQj7a/6oSXf6SwCoCBXpj05RavorPFrHYxJrsdvS/iaL56q/a4NsCUpsxv7oBRB4txZlbyB77J4n2CXuLdifwELpGVe/CDqKXbcU1sDig4i8oY4vgWcJ/D/xZ+HjzCj+D8UCH28nnjcRKmbxd4hjYkKTsfMGPeahspQqNSkEaZ8RFpJxYwIh5vnV672wT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(13018025)(13023025)(13015025)(5005006)(8121501046)(13024025)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:BLUPR05MB531; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB531; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 4:uk2jwd1CX8uvrtZWbYbe2Yg5XKL/KrLbxUmzayiSIG00GPxukzE+vMX1Vc4RZZ2FzYEadJIK3Z8Smz0AYYwdg4FTzHVSbsXF6UjiGUuO3G6H983cqash2+NofrcUdmhAxcVvzGAl3Pm2QbzR7G4Le90i7ZK9qw4mRFRqWPdo3ERfkBrV6Zpa925wBiYRkdDGX+JPvpIHTVl58J2rJm6KHktUBzLsnca7GEPha9AqcVreRMw6u1RNjdahj8b0Blr5ssXAJu4/ajY0c0Vpo7yE9sonq8D7+Che0zq3CxaTzsoleBONExTVDTgVSHqo+a43EW42bo9nwdtIEzyQKenf0GQK9O1AMPkAEeLUExwlOOqtYEyJ0wgg/L1nuswZDftv9CB3VnoBKRiup1mGZJIeBkX3CLzR5ORhwHi0Om6S66G8KJe21Q9myssamOUUJQBl6TW8C4tQlfghUwMyndRf3AkmjMoVrSb07PdHcmpd9dI9KRlATRXm2YjFRbhpAgtTDOLGj85hYlkmtJ7WeZDnCahM50hTdXUIA3JiTiP4dE7KTc8WVrqizyDewx67Hu2uGCv2Ct1zhJLIasMk27qUL3jU1wE5Wtt8BF0Y2PKTwcqrWfZ0kkVskyjo2JyFmnbCQA/8YpAQdRuAcK7jfXPlQCHhffQEpHosebIgC316i6D4ChPzKWFpLL/vp1H9jQF4M8Pn1pwqH05l5wG+TsdDbQWahWArhAczLsIMyevyfk9rwFJ7uiFsNN/egKsjtlyp/VRs3c8cg7AzEIcyIMrDEGp9JE8j8hpjOmcuU9L3nHSML52vY+tIozY0Yg2E3UcfOTXWElbAvMPFeQt8cMsl09Uz2NL/etj7CzWGSjFm9p8= X-Forefront-PRVS: 02778BF158 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB531; 23:u9hTO46JAC4ljq89LI3fD5vCe3MtqJoTBdYOJo1Xf4?= =?us-ascii?Q?jnIdbi1sXlNqYUY6wxkYQDaGQqmZYikGQmaJOOVbmSHWsp6qzAHvGWyjMmDe?= =?us-ascii?Q?O15GwxjqxkV2NnSVLudUwqVeUA+pOlIWLB5umXu+TMT46/+VxTpPvibbwlIj?= =?us-ascii?Q?rFDlaGTkV7W05uWoh5/+pTF/DPEK88Y9DQ3gIYD0Z09aDAcqJcOvvOMcMsFd?= =?us-ascii?Q?CCLNldS1i9YC7xqe7aMv0gzSkmFM6Fc5eLko7kIm4/Lnmi8KTyOMxiFqkzq8?= =?us-ascii?Q?+QYlY6TvLsUlHD5IRqNZti9J/iMS5RnudzY05txfGUK1BAA5/y211COtPNSm?= =?us-ascii?Q?ZNUW8GGF8p529FC782DUAx7YsZZsgL5LsAGMHxyNxzi9wMKmFzs2i05cXfXO?= =?us-ascii?Q?sd1CoP2NpzafdmOk9Tc2y2movp/o7WyVPZgR3j37ywEBs17elXUY2bmRYnfq?= =?us-ascii?Q?BzsTyoAKjAJGg400StpwCF7PFipdFOLJYNUpXfen1ms5wx0ZFhLKHhpcAmQg?= =?us-ascii?Q?aXaS5YQS2CKnFa+2geolYdpFAT+GTzy5QFQP/v3vBuchBa+ulSGDZZjSlm5x?= =?us-ascii?Q?a6wkbwjPP1ewvcgU111Jvd1mfQCqmYaccaT1XipDFqmYC+cWLPhNqi91kWSj?= =?us-ascii?Q?p+QXtEiIpXRqsTeAh1ooceCWRnUfoU3m1E8E8GZZy48N7+wPn6CcFGn5N+rt?= =?us-ascii?Q?Pz3AieSRFPIycBnD/t7g5pcBCIWTu0bPfKg5lPId2ZZwplSTootItREm6d6r?= =?us-ascii?Q?uW0zarOLy8P16l5CbinL5qD+E6io9bSG/QTzzWv/ORZGCPr32tCiC7Xrvfuc?= =?us-ascii?Q?JAPBgWTywH36NaIsHGgunyX/WWF5fZRC7O203QvABcjgYHl2gOAxQejHqosc?= =?us-ascii?Q?KXcDL7qq+YmFFr28DIzqcY1rlXT0H5sK1UTNH2b76eerJ7WW54z6dEa3L1qS?= =?us-ascii?Q?9OKYHOi44ghBVcds1sOOvfHpejTSiXb7rNNiNkvzN0+yycU9RBWnmykZPp6E?= =?us-ascii?Q?7aBOvOUofwVRBxbtPxj3MzB5Ilp9jaelTuFjang9v5zpFcLL6eIJPO6sUoE7?= =?us-ascii?Q?/han1rGI5p0LIdUaToW+8ggfJMI15fk/E7A8UM6+Dw1YlPKA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 6:zRQ0QXmOcu/s75LwRjRMh8d1NvW3xCnj0pQu1xdZn+FWhEv2AoFr7TBasMWvvGO/6JnzMnedmhRONOE//jKNjXk1UOXBqEZA56DhF6+Pqmbkb/2hpWhO6XzjJJMQXcly1ZI5qpypHfWiwz6EfF2HeXkQxB0rgAfoV8NYw36s49JoKMwqPIydjHLl7HAHbo5IxCTL9n1+gFUu+//8axPxeJgWYbMfzukak/0jW5K0cdTyNSsRf4of1WRdWJl1yNT2GAJdx6cldWQlhKkDhk0vsc/HLa3xJpnGe1T8uXijiZTQALyOeqTBL6ZL86hyBr6VLRtXettV51Xd9lx5pND+lcBYrdu9e6ySsbOfyEvqiRqj3rJTqBjPSDAuhqQq6z08XbSNQf9i2psICaa5eMigxz3WQIzlyGt1M1pVedIa7pyDYAXGdHYqsYSJIgofAToii3Bk2dhizaAWJX8VgrKJ2ZibkTNyg4oNuArTID77Cpk=; 5:h04F+h4B507o9Jki4k4YperwqVt+V53Wp/NT+29uyASPhTNY7byMFTEXuHNa0NqicJT0mmS3SfzHFRdB5xReSJGJ1Tn2xxBiicfGeJp6qhofO6FNZ2LdHUgCi49fvSt8DNe/Ctk49iC8fCQNwvpm+Q==; 24:wjb0shZyHaLOZ5SksQDt0UX5rLfjhCI429ryyeEXd7a+FFvOiNaDWXEyBGR4emJ+LVItwl/u+MFPtS0xJ70Tta88fBmQIR6tZU7wRcj+GJs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 7:2ghw/s0IvtmOYeFfvZkWkuR5Sp8aATlaNXfdziEPGsxRHGFztSDS8pWBTr0IgMSVsX79J6q3g3aY6lEqybuRZQ367sloe3VFi4gRDHs0xFmtUxgUQSt0jXlg6MysLRL4Szovdo6EHQHzHvi81eTiEMZygnm3dmnannLAAkNaqFFiSAmb4sfgdIl1pw2N9/AmgYf3P+25rkCsgeGClc72BNIMY6axqRcKBlzaR96NTfO1llR89v6nm6Bl6I3VkNTXWNa7+0QH+/ShTqyEMnOyqA/WlJCVDoxqfnEL221zLlgWmc/9CwMeoV+4F2FkE+jdmpe0u3p+yBsLmGskFHRpFQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2017 04:03:49.5151 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB531 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 04:03:54 -0000 Ladislav Lhotka writes: >leaf foo { > description "This is my *favourite* leaf."; > type string; >} > >you may not like it, but it is absolutely legal and IMO also readable by humans. As William previously mentioned, some communities are already doing similar things. The principal aim of my I-D is to allow module authors to explicitly state that they adhere to some rules, which helps authors of tools reduce guesswork. 1) I think there's a difference between people using our ancient ascii-based conventions that help the reader grok the author's meaning, and supporting markdown (plus other syntaxes) that allow ascii documents to produce HTML. 2) It's not something where one can say "don't use it if you don't like it", because we will have to read these description statements for review, etc. 3) Markdown is a class of tools, not a common tool. CommonMark works to standardize this, but I've no clue how "common" it is. 4) Consider that github supports >9 formats. Are we expecting readers/reviewers to become knowledgable about each of these? Thanks, Phil From nobody Fri Apr 14 10:56:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E56120725; Fri, 14 Apr 2017 10:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0zQevcRzqXc; Fri, 14 Apr 2017 10:56:01 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E52A1294F5; Fri, 14 Apr 2017 10:56:00 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id t14so9041026oif.1; Fri, 14 Apr 2017 10:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=bS63lj2aR/vffrvciSY/izhLPFv8JM6twx4rv7kYmBo=; b=uJPeCu388g53Hal50ZzT9E5DJYTPm0QFKe16SOXLQ45XKXInHjrCNQobb7Nu+Rx4eq H8dY4ceJa4HfGrDRdMkX/UdCLfbfTUlonc5rfjnd1V5RGbkgnnIiYDpX7+q/MoeaYxtz hKl+gMKyGTJc4O1MjPT4mN/IzdzUDc6CisvWSPCVmu2hTQA91gyTT7N7NiBDJFx1VEZ2 BLP1DDonZbgNFInh/ZRARhLPAXQLkQ0VolKfjSWwhQg9tTZIcMIvkD+ZmuPhmuRsIz1+ PSOtqRwILrMufkJ7eM5XhbJ4dXDXCQM6OIvcdf8IFcQvYUl8LJbsg5+Ge1qrWbC8luA7 v58w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=bS63lj2aR/vffrvciSY/izhLPFv8JM6twx4rv7kYmBo=; b=tSwpV2/f3rqXDL6wzBb2rO88NMnGCK5voICpasdhEScbmnEBzhee6cOXytBWeZJ5HB xp17jJp0/E8ALpD47kLO7mNY7Jj4Sap14ERsdVRCviuTv2CSiMHa4vZRbnRdllPyztqQ xWbHMQXTHvgVvxcTCf2K38EZIQoksXpQ38EFzvQ2a7n8DZ0kSGCQ4JtWraPlojAlpZ2u 5NSJLSupLmx6uuajwX90mlkC0MYMn5Emu8ZH4xa3/xdYcaJGZyE1Y+X1dQul17RTxNOx YAAd4rYgIdr96h1n1KvJPAC6uMO0pwRYr/bjlBzGPm5q0gQ8bUlM7OsKeKEOJSrLMDs2 rOOA== X-Gm-Message-State: AN3rC/7w1di/kRvWopnLC+6Uk/qKkd9pcVWTbMZ0hPK0msUPNaCxrWWq JQtIs1jfQ1WhFw== X-Received: by 10.202.95.137 with SMTP id t131mr5121879oib.53.1492192559733; Fri, 14 Apr 2017 10:55:59 -0700 (PDT) Received: from xliuus (ip72-209-195-86.dc.dc.cox.net. [72.209.195.86]) by smtp.gmail.com with ESMTPSA id x54sm1090147otd.11.2017.04.14.10.55.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Apr 2017 10:55:59 -0700 (PDT) From: "Xufeng Liu" To: "'Kent Watsen'" , Cc: References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> In-Reply-To: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Date: Fri, 14 Apr 2017 13:56:02 -0400 Message-ID: <006001d2b548$61bf1070$253d3150$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKCjyNRoSCDo6ZO7JaNB8DJ0/EXK6BlcmlA Content-Language: en-us Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 17:56:04 -0000 yes/support. Regards, - Xufeng > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen > Sent: Friday, April 7, 2017 7:23 PM > To: netmod@ietf.org > Cc: netmod-chairs@ietf.org > Subject: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree- > diagrams > > All, > > This is start of a two-week poll on making the following draft a NETMOD > working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > > Please send email to the list indicating "yes/support" or "no/do not support". If > indicating no, please state your reservations with the document. If yes, please > also feel free to provide comments you'd like to see addressed once the > document is a WG document. > > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Apr 14 14:23:52 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E217129511 for ; Fri, 14 Apr 2017 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaTElFmrLnn1 for ; Fri, 14 Apr 2017 14:23:49 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 89415126D74 for ; Fri, 14 Apr 2017 14:23:49 -0700 (PDT) Received: (qmail 32535 invoked by uid 0); 14 Apr 2017 21:23:49 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 14 Apr 2017 21:23:49 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 8MPl1v00V2SSUrH01MPooy; Fri, 14 Apr 2017 15:23:49 -0600 X-Authority-Analysis: v=2.2 cv=LIwWeNe9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=Fm8F0NncYRAA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=AzvcPWV-tVgA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=SHTEAq+fXcNaCT8TwWyXbL+UPZykCseTnVJdMGzcu7I=; b=O77Jko01kGr1kDDtmUpAqi4zIR r8yN7hOBi77HRgOPOTAanlDf7adxajnBXozRcFcEvxUP+jDtlezf0EjSy+vyddd3CpEYVXVjMpW8F b/GhDwGIkWBRw8pWzn1en5HbI; Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:50682 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cz8gz-00077P-6Z; Fri, 14 Apr 2017 15:23:45 -0600 From: Lou Berger To: Anees Shaikh , Rob Shakir , kd6913@att.com Cc: NetMod WG , NetMod Chairs Message-ID: Date: Fri, 14 Apr 2017 17:23:42 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.84.20 X-Exim-ID: 1cz8gz-00077P-6Z X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:50682 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [netmod] Regarding IPR on draft-openconfig-netmod-model-catalog X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 21:23:51 -0000 Authors, Contributors, WG, As part of preparation for WG Adoption Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, NETMOD WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Fri Apr 14 15:00:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF41129AE7 for ; Fri, 14 Apr 2017 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkOvadirUe9a for ; Fri, 14 Apr 2017 15:00:13 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DD7129AD3 for ; Fri, 14 Apr 2017 15:00:13 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id b187so101724577oif.0 for ; Fri, 14 Apr 2017 15:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rGX3QtYkFxmQKkPbZxzoayKo/DPotB6Uk8s1HGDuAO0=; b=j6PxJjKCthW1XYNrpT0m6F3FHZQ3s04WvcrGqmD7tcC3Zm1gvIB936MF+8d4nXhUOi 8dsIZn0+ZPLWpFJd/hdLzFrcFR4XTKWlWjKQyehuBT46pzDCTzQ98+j/7qj+RuLxOqQy PcaRbNDNqT0zEz56CuLVTpSJru8ht6+9j0By1s9Dai+OGIoLq5GrCADakm7mTA/MHFwV Nj4DmgbI8OmEQm3IT0rMOUbPIfpeKyvpYUfSc1byp+aKxOny4W1fFBvdZrG2O0zIQDcM IxcfUT6m4S4nu1LyEhpPcssGfwjE2GxVbL60+ObVJ0mGWhfTZqPQyfpgkknuVDr8Giha Nkiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rGX3QtYkFxmQKkPbZxzoayKo/DPotB6Uk8s1HGDuAO0=; b=L9fz/1LtJT/OHri3KcNVeR9z1rQ61C0aSNa2krmHEaJT+LJLLSnuz8a+vYDmFHzrSa IbeHc2XWEYDo1+0xi6cenA1tE+ixG1aRohXu2S66eBoywuLOPrYHeB8grekhWsHjOjkJ DY5/orvLS8Qskc3Z0VpW5hoJWJbl014wds6j10bFy16f9gxGK+HIF+6jiEGFF6njsugu bMu20xvOk/pzOxfAOYe/Fof8bjZMxx7zuyvZ5SqOUb5q2X7BcB58DmJ5yEY/5mE9sdcn juOqIsUIrtbiqFpjYz3gMcCrAIiieDlrRZMdwv66mk2RIPT4q3ENbEBUzD9ZNeHt5z1W ZNhw== X-Gm-Message-State: AN3rC/4mrYE9Z37eZQkus+KwIcq3lwVLP1Of7wo+H9RRt5E8DfVuxfHC llkl28yHXL01ZdcJXi/b6PCb/l76OyOZ X-Received: by 10.157.47.206 with SMTP id b14mr6037554otd.203.1492207212402; Fri, 14 Apr 2017 15:00:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.109.201 with HTTP; Fri, 14 Apr 2017 14:59:51 -0700 (PDT) In-Reply-To: References: From: Anees Shaikh Date: Fri, 14 Apr 2017 14:59:51 -0700 Message-ID: To: Lou Berger Cc: Rob Shakir , "Kevin D'Souza" , NetMod WG , NetMod Chairs Content-Type: multipart/alternative; boundary=001a113de438d3eae3054d2790f0 Archived-At: Subject: Re: [netmod] Regarding IPR on draft-openconfig-netmod-model-catalog X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 22:00:16 -0000 --001a113de438d3eae3054d2790f0 Content-Type: text/plain; charset=UTF-8 Thanks Lou. Regarding draft-openconfig-netmod-model-catalog: No, I'm not aware of any IPR that applies to this draft . -- Anees On Fri, Apr 14, 2017 at 2:23 PM, Lou Berger wrote: > > Authors, Contributors, WG, > > As part of preparation for WG Adoption > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > --001a113de438d3eae3054d2790f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Lou.=C2=A0

Regarding draft-openconfig-= netmod-model-catalog: =C2=A0No, I'm no= t aware of any IPR that applies to this draft .

-- Anees

On Fri, Apr 14, 2017 at 2:23 PM, Lou Berger <lberger@lab= n.net> wrote:

Authors, Contributors, WG,

As part of preparation for WG Adoption

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S<= br> TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/= group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NETMOD WG Chairs

PS Please include all listed in the headers of this message in your
response.



--001a113de438d3eae3054d2790f0-- From nobody Fri Apr 14 19:57:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D3129B7A; Fri, 14 Apr 2017 19:57:39 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJJLrgdY8H7O; Fri, 14 Apr 2017 19:57:38 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id F123B129B77; Fri, 14 Apr 2017 19:57:37 -0700 (PDT) Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 177F962E51; Sat, 15 Apr 2017 02:57:37 +0000 (UTC) References: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Kent Watsen Cc: "netmod\@ietf.org" , "netmod-chairs\@ietf.org" In-reply-to: <159225DB-1D0D-4A75-BFE8-C28F651AE4F0@juniper.net> Date: Fri, 14 Apr 2017 22:57:35 -0400 Message-ID: <87tw5qnzs0.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] WG adoption poll draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 02:57:39 -0000 --=-=-= Content-Type: text/plain yes/support. Thanks, Chris. Kent Watsen writes: > All, > > This is start of a two-week poll on making the following draft a > NETMOD working group document: > > draft-bjorklund-netmod-yang-tree-diagrams > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > > Thank you, > NETMOD WG Chairs > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAljxjB8ACgkQLh2DDte4 MCX79xAAnq0P60Q1WrIFXKzkmapumSQQSDquk0YLPA4L1GavTfquhP+aN/p8jk9B IRkcSjKVZ/tUldyQgc6Z5dfHKKSGdMYNTtbl9j1lyqX+Lf/m/6jlXK1vzCdPLKsI xJF2/u72lZ4fbsemTEuwAzflB8wrRc1PEsdUOSSxkZT1r9lNBWMysLNu6p1dKqhj AVFgWrQ36iaKZ9Rygh8eja7KVNVL+/XVZ7BzMpmJioDVKZZO84+aUSjsk47XnqI9 9NDF2JRpmKag/F4jA5wTuiHw8bgbZMKbK0tnNvolgDeb5QuY1NoFUwoH1q227GbD 4QKx3bKHFBSABqiW9TeNonXR1XV15X/yPobrgnPJtOroWwZQyg4m1c4ui88d/+iV SgZa6TFzcnhYcS9StB1TR6g9x1hAPphmnQpADS36xXwOmt3lKurRTEMq8/AQVDXF TzwD9C1UWIVL1nJ2Kpllc7XMjt757sj9eNdJor1ZINqMWb0/K8Jn6xm7oGa+JTgV r8nmOzK/AznswowVwjlXAQApDP1e06wq4HnYyj+zjRJZ4c3/rEFncJY8a0dRTrom hyUhnskU64CTCHUUfFMBkNr50rYJ8qNjZrVbNYaxO9DVEXqfZghk/t/+P3jyXVKV xVJKttQ+/PUgO9E1w/BXPzAGTccxOiVSi8JvH9IE8n6EBOrhvuw= =R2pv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Apr 17 10:44:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD713170D; Mon, 17 Apr 2017 10:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 lz4zuiFMhQvb; Mon, 17 Apr 2017 10:44:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15EE4131706; Mon, 17 Apr 2017 10:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2927; q=dns/txt; s=iport; t=1492451060; x=1493660660; h=from:to:cc:subject:date:message-id:mime-version; bh=ZEAXSmz9Kzkh3Xdebt5lPriqX0JRCQgQ5xcVZYDtVXA=; b=kbx0g53oeu9956m+QHsjAGxsmcq0iRnAXJvjf8FZsZrgRTFnfKVQ5DX5 uhLj3OYXAlTGVkr+KzwAZoqm5AJJrL4CIM5XTjquWM9IN3gOpJXHfndI/ gm2V8ALH5UcGdWF45QWYHZ9Kf1SDRKN8yVikP9Z5SVIlJ8NR47w8tFuBB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AgBN/vRY/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5lYYELB4NfihWiCIU0gg8shXgcg2g/GAECAQEBAQEBAWsohT9?= =?us-ascii?q?WEgEMAQ0wAgQwFxAEDoocDqsCgiaLFwEBAQEBAQEBAQEBAQEBAQEBARsFiC+EZ?= =?us-ascii?q?4YOgl8FnRsBgVWRD5FGlAkBHzhYLWMVhyl1AYgNgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,215,1488844800"; d="scan'208,217";a="411457328" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Apr 2017 17:44:17 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3HHiHJZ017558 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Apr 2017 17:44:17 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Apr 2017 13:44:16 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 17 Apr 2017 13:44:16 -0400 From: "Acee Lindem (acee)" To: Routing WG CC: "netmod@ietf.org" Thread-Topic: Impact of "Network Management Datastore Architecture" (NMDA) on ietf-key-chain Thread-Index: AQHSt6I8WwCYI94mMEy+O1Ae6VizeQ== Date: Mon, 17 Apr 2017 17:44:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.197] Content-Type: multipart/alternative; boundary="_000_D51A772BA8ED9aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Impact of "Network Management Datastore Architecture" (NMDA) on ietf-key-chain X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Apr 2017 17:44:22 -0000 --_000_D51A772BA8ED9aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIHRob3NlIHdobyBhcmUgbm90IGZvbGxvd2luZyB0aGUgZHJhZnQgb3IgZGlzY3Vzc2lvbiwg SeKAmW0gcmVmZXJyaW5nIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtbmV0 bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy0wMS50eHQNCg0KQWZ0ZXIgbnVtZXJvdXMgbWVldGluZ3Mg b24gdGhlIE5NREEsIEkgd291bGQgYXNzZXJ0IHRoYXQgdGhlIGlldGYta2V5LWNoYWluIG1vZGVs IGlzIGluIHRoZSBjYXRlZ29yeSB3aGljaCBjYW4gZ28gZGlyZWN0bHkgdG8gTk1EQSB3aXRob3V0 IGFueSBtaWdyYXRpb24uIEkgYmFzZSB0aGlzIG9uIHRoZSBmYWN0IHRoYXQgZ2l2ZW4gdGhhdCBr ZXktY2hhaW5zIGFyZSBtZXJlbHkgYSBkYXRhYmFzZSBvZiBsaXN0cyBvZiBrZXlzIHRoYXQgY2Fu IGJlIHVwZGF0ZWQgaW1tZWRpYXRlbHksIHRoZXJlIHNob3VsZCBiZSBsaXR0bGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIHRoZSDigJhydW5uaW5n4oCZIGFuZCDigJhpbnRlbmRlZOKAmSBkYXRhc3RvcmVz LiBOb3RlIHRoYXQgdGhpcyBpcyBjb25zaXN0ZW50IHdpdGggdGhlIEFDTCBtb2RlbDogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTEwLnR4dA0KDQpE b2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRoIHRoaXMgYXNzZXJ0aW9uPw0KDQpUaGFua3MsDQpBY2Vl DQoNCg== --_000_D51A772BA8ED9aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5Gb3IgdGhvc2Ug d2hvIGFyZSBub3QgZm9sbG93aW5nIHRoZSBkcmFmdCBvciBkaXNjdXNzaW9uLCBJ4oCZbSByZWZl cnJpbmcgdG8mbmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDEudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDEudHh0PC9hPjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWZ0ZXIgbnVtZXJvdXMgbWVldGluZ3Mgb24gdGhlIE5N REEsIEkgd291bGQgYXNzZXJ0IHRoYXQgdGhlIGlldGYta2V5LWNoYWluIG1vZGVsIGlzIGluIHRo ZSBjYXRlZ29yeSB3aGljaCBjYW4gZ28gZGlyZWN0bHkgdG8gTk1EQSB3aXRob3V0IGFueSBtaWdy YXRpb24uIEkgYmFzZSB0aGlzIG9uIHRoZSBmYWN0IHRoYXQgZ2l2ZW4gdGhhdCBrZXktY2hhaW5z IGFyZSBtZXJlbHkgYSBkYXRhYmFzZSBvZiBsaXN0cyBvZiBrZXlzIHRoYXQgY2FuDQogYmUgdXBk YXRlZCBpbW1lZGlhdGVseSwgdGhlcmUgc2hvdWxkIGJlIGxpdHRsZSBkaWZmZXJlbmNlIGJldHdl ZW4gdGhlIOKAmHJ1bm5pbmfigJkgYW5kIOKAmGludGVuZGVk4oCZIGRhdGFzdG9yZXMuIE5vdGUg dGhhdCB0aGlzIGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgQUNMIG1vZGVsOiBodHRwczovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTAudHh0PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5Eb2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRoIHRoaXMgYXNzZXJ0 aW9uPyZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0K PGRpdj5BY2VlICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_D51A772BA8ED9aceeciscocom_-- From nobody Tue Apr 18 02:32:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97070129646; Tue, 18 Apr 2017 02:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 sW2sIzxo3FIY; Tue, 18 Apr 2017 02:32:25 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA46C129505; Tue, 18 Apr 2017 02:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8598; q=dns/txt; s=iport; t=1492507945; x=1493717545; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=NXIuSa9+ienknAPbjbnqcVc4QOifySQmLLzDEJ/QQfM=; b=XmRRiL5hOna/fNdNcZAMx6qKmBqYaBs07YhSMK/9HrtuG9ehNswipOz4 IBB2SRO2LY6PRzI4YuS4gNSI3I0cZqkFTmD7B3YLpe/c9urtP0YjbKK+N vG7ZtBgXK9UnAtjK5tpYobUud8b8BGtUlLEivB9XE8phvlFY9kmBbL+p9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAQDR3PVY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhT+DZooVc5BskC2FNIIPhiQChC0YAQIBAQEBAQEBayiFFQEBAQE?= =?us-ascii?q?CASNWBQcECxAFAQInAwICRhEGAQwGAgEBig0IqhOCJiuKdwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GUoIIgm2BPIYhgl8FnSKSaoprhl2LcYgdHziBBSYdCBgVhTa?= =?us-ascii?q?BdD81iQsBAQE?= X-IronPort-AV: E=Sophos;i="5.37,218,1488844800"; d="scan'208,217";a="651222479" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 09:32:05 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3I9W5uD008879; Tue, 18 Apr 2017 09:32:05 GMT To: Andy Bierman , Ladislav Lhotka References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> Cc: "t.petch" , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Kent Watsen , NETMOD WG , NetMod WG Chairs From: Robert Wilton Message-ID: Date: Tue, 18 Apr 2017 10:32:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E9F270571BF333AF7489494" Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 09:32:29 -0000 This is a multi-part message in MIME format. --------------1E9F270571BF333AF7489494 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 13/04/2017 17:08, Andy Bierman wrote: > > > On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka > wrote: > > > > On 13 Apr 2017, at 13:34, t.petch > wrote: > > > > > > ----- Original Message ----- > > From: "Andy Bierman" > > > Sent: Wednesday, April 12, 2017 5:44 PM > > > >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de > > wrote: > >> > >>> I think it is crucial that descriptions etc. remain human readable > >>> using plain text readers. Having to run a renderer to make > sense out > >>> of descriptions etc. would be a big failure and things are even > > worse > >>> if modules use different dialects all over the place. > >>> > >>> I believe there is way more important work to get done than this > > (and > >>> I fear endless discussions about which adapted subsets of markdown > > or > >>> (whatever comes next) to use). I do not object this work, but > I also > >>> do not support it at this point in time. > >>> > >>> > >> +1 > >> > >> IMO this makes YANG less readable, especially without any agreement > >> on the specific markup supported. A YANG module should be > readable by > > humans > >> without any special tools required. > > > > I agree. I would say that if you cannot say it in text/plain, > then you > > probably should not be saying it (something I would extend to > e-mail but > > realise that I am less likely to get support there:-) > > OK, so if somebody writes > > leaf foo { > description "This is my *favourite* leaf."; > type string; > } > > > Your premise is that the description-stmt is for the > benefit of the model writer, not the model reader. > Since YANG explicitly states this statement contains a human-readable > string, it seems clear the benefit to the readers is more important. I see that the benefit of allowing markdown really is for the model reader. Longer term, I assume that operators using YANG models probably won't interact so much with the raw YANG models themselves, but will be much more likely to interact with the constructed tree structure through a web browser, or generated APIs. Allowing markup, e.g. so a paragraph of text can re-flow to fill a box seems useful to me, as does some sort of emphasis and lists. I also note that quite a lot (most?) language API documentation tools generally take some form of structured text, rather than relying on text/plain. But I do agree to the point that this work seems less urgent than some of other items that are being worked on in NETMOD. Rob --------------1E9F270571BF333AF7489494 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 13/04/2017 17:08, Andy Bierman wrote:


On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 13 Apr 2017, at 13:34, t.petch <ietfc@btconnect.com> wrote:
>
>
> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> Sent: Wednesday, April 12, 2017 5:44 PM
>
>> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> I think it is crucial that descriptions etc. remain human readable
>>> using plain text readers. Having to run a renderer to make sense out
>>> of descriptions etc. would be a big failure and things are even
> worse
>>> if modules use different dialects all over the place.
>>>
>>> I believe there is way more important work to get done than this
> (and
>>> I fear endless discussions about which adapted subsets of markdown
> or
>>> (whatever comes next) to use). I do not object this work, but I also
>>> do not support it at this point in time.
>>>
>>>
>> +1
>>
>> IMO this makes YANG less readable, especially without any agreement
>> on the specific markup supported. A YANG module should be readable by
> humans
>> without any special tools required.
>
> I agree.  I would say that if you cannot say it in text/plain, then you
> probably should not be saying it (something I would extend to e-mail but
> realise that I am less likely to get support there:-)

OK, so if somebody writes

leaf foo {
    description "This is my *favourite* leaf.";
    type string;
}


Your premise is that the description-stmt is for the
benefit of the model writer, not the model reader.
Since YANG explicitly states this statement contains a human-readable
string, it seems clear the benefit to the readers is more important.

I see that the benefit of allowing markdown really is for the model reader.  Longer term, I assume that operators using YANG models probably won't interact so much with the raw YANG models themselves, but will be much more likely to interact with the constructed tree structure through a web browser, or generated APIs.

Allowing markup, e.g. so a paragraph of text can re-flow to fill a box seems useful to me, as does some sort of emphasis and lists.

I also note that quite a lot (most?) language API documentation tools generally take some form of structured text, rather than relying on text/plain.

But I do agree to the point that this work seems less urgent than some of other items that are being worked on in NETMOD.

Rob






--------------1E9F270571BF333AF7489494-- From nobody Tue Apr 18 09:31:58 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59628128E19 for ; Tue, 18 Apr 2017 09:31:56 -0700 (PDT) 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYAHnMPGDM6x for ; Tue, 18 Apr 2017 09:31:54 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FAD512EC2D for ; Tue, 18 Apr 2017 09:31:54 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id z109so106356002wrb.1 for ; Tue, 18 Apr 2017 09:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gs0uIh1epM/yMQgmTSqWrc8WJv/KHQSUYPaZJ27oaXc=; b=dIq0HcgTOhhDhiE/BXJ2CGmyQ0xguxAgvF/CAHMsMcNR7bZb6M2Hrr35qXIEJq8ztm HaAtumEbA5RCnXTt6pqQyZppsCwDvCgK0h87RP9IrT48pNalH/ULygl4ca+CkoGFy1C6 4Df6G4H5s/hZYcCrMEr7T2olblYHFAOLPBWLl4ew7d2UritYtUhkKXDdppF7URbgji8k dxZgveg5jKqtBGGGA5C/XHRVd/KSRi4waRnk4bT3TnD9ZoAM8W0NlKN1kQrjrLahD2Qv l2xjWHpS5bB5Z7ycDCzHPm9rnf1yOb/Xuz+J6VZilNYaLrDH8jhsQiYIatPpX68+9vyd LHTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gs0uIh1epM/yMQgmTSqWrc8WJv/KHQSUYPaZJ27oaXc=; b=G/K3s0V2NO+BGB2PKDm0NAN5/coYCRCVMT/VNEFn0qTOaGCtJMEfgNqLY8Ej97WFG/ Fq04gVlW7yNBRwWaLxL/6nGDQsT7ZsLNT+KYkafxDNhXl//JCKCFljljiMHquCyecjFj GJx6Q73esA6uMBkRI8fik5o3CL+y2srd5nWlWclCEpyY3ZE/3GI4JWOyWMGxBsibw8uR tILI7OhTEbLX+NGUmbr37BsD64yJ8HxIjjiIi1MDxLZxa45Kfb2QzfqJWW11guRYdUKh aqmiY3bwS7ALc4Xlabw3hgGFjNzwtUVOpdaMD2OF2KJf2LtmwqtUDJQLMoXb8+sFfrwV KL0w== X-Gm-Message-State: AN3rC/7S1L2kJUvOEtKTMZR4r8Z1Q7AwqupP7zL3N7C/jCV0nPm0962f fAgiB1BmZNo0/FuN7cBNNrPeVPBENw== X-Received: by 10.223.129.4 with SMTP id 4mr26020178wrm.62.1492533112621; Tue, 18 Apr 2017 09:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Tue, 18 Apr 2017 09:31:51 -0700 (PDT) In-Reply-To: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> From: Andy Bierman Date: Tue, 18 Apr 2017 09:31:51 -0700 Message-ID: To: Robert Wilton Cc: Ladislav Lhotka , "t.petch" , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Kent Watsen , NETMOD WG , NetMod WG Chairs Content-Type: multipart/alternative; boundary=94eb2c068598fe802d054d737167 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 16:31:56 -0000 --94eb2c068598fe802d054d737167 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 18, 2017 at 2:32 AM, Robert Wilton wrote: > > > On 13/04/2017 17:08, Andy Bierman wrote: > > > > On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka wrote: > >> >> > On 13 Apr 2017, at 13:34, t.petch wrote: >> > >> > >> > ----- Original Message ----- >> > From: "Andy Bierman" >> > Sent: Wednesday, April 12, 2017 5:44 PM >> > >> >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < >> >> j.schoenwaelder@jacobs-university.de> wrote: >> >> >> >>> I think it is crucial that descriptions etc. remain human readable >> >>> using plain text readers. Having to run a renderer to make sense out >> >>> of descriptions etc. would be a big failure and things are even >> > worse >> >>> if modules use different dialects all over the place. >> >>> >> >>> I believe there is way more important work to get done than this >> > (and >> >>> I fear endless discussions about which adapted subsets of markdown >> > or >> >>> (whatever comes next) to use). I do not object this work, but I also >> >>> do not support it at this point in time. >> >>> >> >>> >> >> +1 >> >> >> >> IMO this makes YANG less readable, especially without any agreement >> >> on the specific markup supported. A YANG module should be readable by >> > humans >> >> without any special tools required. >> > >> > I agree. I would say that if you cannot say it in text/plain, then you >> > probably should not be saying it (something I would extend to e-mail but >> > realise that I am less likely to get support there:-) >> >> OK, so if somebody writes >> >> leaf foo { >> description "This is my *favourite* leaf."; >> type string; >> } >> >> > Your premise is that the description-stmt is for the > benefit of the model writer, not the model reader. > Since YANG explicitly states this statement contains a human-readable > string, it seems clear the benefit to the readers is more important. > > > I see that the benefit of allowing markdown really is for the model > reader. Longer term, I assume that operators using YANG models probably > won't interact so much with the raw YANG models themselves, but will be > much more likely to interact with the constructed tree structure through a > web browser, or generated APIs. > > IMO it is more robust not to assume people never see the real YANG statements. What if these tools have bugs? How would we ever know? Allowing markup, e.g. so a paragraph of text can re-flow to fill a box > seems useful to me, as does some sort of emphasis and lists. > This part confuses me. I've written YANG to HTML tools (e.g., netconfcentral.org). The tool has to render the entire module, not individual description-stmts. Emphasis is usually formula-driven (like the keywords). The tool has to know about the entire YANG module, not just the descriptions. > > I also note that quite a lot (most?) language API documentation tools > generally take some form of structured text, rather than relying on > text/plain. > This makes sense if (1) the entire document is subject to markup, not little pieces (2) the only tool that needs to use the raw markup is a browser (3) the actual markup allowed is strictly controlled and standardized > But I do agree to the point that this work seems less urgent than some of > other items that are being worked on in NETMOD. > Good -- work such as the OpenConfig module catalog will have a much bigger impact demystifying YANG than bold text or an IMG bullet points instead of *. > > Rob > > > > > > > Andy --94eb2c068598fe802d054d737167 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 18, 2017 at 2:32 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 13/04/2017 17:08= , Andy Bierman wrote:
=20


On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 13 Apr 2017, at 13:34, t.petch <ietfc@btconnect.com> wrote:
>
>
> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> Sent: Wednesday, April 12, 2017 5:44 PM
>
>> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> I think it is crucial that descriptions etc. remain human readable
>>> using plain text readers. Having to run a renderer to make sense out
>>> of descriptions etc. would be a big failure and things are even
> worse
>>> if modules use different dialects all over the place.
>>>
>>> I believe there is way more important work to get done than this
> (and
>>> I fear endless discussions about which adapted subsets of markdown
> or
>>> (whatever comes next) to use). I do not object this work, but I also
>>> do not support it at this point in time.
>>>
>>>
>> +1
>>
>> IMO this makes YANG less readable, especially without any agreement
>> on the specific markup supported. A YANG module should be readable by
> humans
>> without any special tools required.
>
> I agree.=C2=A0 I would say that if you cannot say it in text/plain, then you
> probably should not be saying it (something I would extend to e-mail but
> realise that I am less likely to get support there:-)
OK, so if somebody writes

leaf foo {
=C2=A0 =C2=A0 description "This is my *favourite* leaf.&= quot;;
=C2=A0 =C2=A0 type string;
}


Your premise is that the description-stmt is for the
benefit of the model writer, not the model reader.
Since YANG explicitly states this statement contains a human-readable
string, it seems clear the benefit to the readers is more important.

I see that the benefit of allowing markdown really is for the model reader.=C2=A0 Longer term, I assume that operators using YANG models probably won't interact so much with the raw YANG models themselves= , but will be much more likely to interact with the constructed tree structure through a web browser, or generated APIs.


IMO it is more robust not to= assume people never see the real YANG statements.
What if these = tools have bugs?=C2=A0 How would we ever know?

Allowing markup, e.g. so a paragraph of text can re-flow to fill a box seems useful to me, as does some sort of emphasis and lists.


This part confuses me.= =C2=A0 I've written YANG to HTML tools (e.g., netconfcentral.org).
The tool has to render the = entire module, not individual description-stmts.
Emphasis is usua= lly formula-driven (like the keywords). The tool has to know about the enti= re YANG module, not
just the descriptions.=C2=A0

=C2=A0

I also note that quite a lot (most?) language API documentation tools generally take some form of structured text, rather than relying on text/plain.

=C2=A0=
This makes sense if=C2=A0
=C2=A0 (1) the entire docume= nt is subject to markup, not little pieces
=C2=A0 (2) the only to= ol that needs to use the raw markup is a browser
=C2=A0 (3) the a= ctual markup allowed is strictly controlled and standardized

=

But I do agree to the point that this work seems less urgent than some of other items that are being worked on in NETMOD.

Good -- work such as the OpenConfig module catal= og will have a much bigger impact
demystifying YANG than bold tex= t or an IMG bullet points instead of *.

=C2=A0

Rob







Andy

--94eb2c068598fe802d054d737167-- From nobody Tue Apr 18 10:08:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6961292C5; Tue, 18 Apr 2017 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0T0W1gBMj749; Tue, 18 Apr 2017 10:08:35 -0700 (PDT) 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 7232E1200F1; Tue, 18 Apr 2017 10:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19823; q=dns/txt; s=iport; t=1492535314; x=1493744914; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=KNydwddV1qyXhDYQXDJwIvz1x5clK/kSRLJlfJh+Gbc=; b=Yh63J+lhWusbT0sucafTDXIx36bj3sSXya9hsBwLj5ILU4AtPxv7lFIW sm+OJ7qhhTA1b2zXRuV2UNeRAwJWt6NJlL3VuYhQKoP2Bsz4gNwEJMdqm Fu/EFH1H185AurJtwKaKP6gmh9FAafzlAPO2m9VxjHLmcaj8U+pY+epwi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAQA8R/ZY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDQxWoNmihVzkE8hlWGCDyiFfAKEMxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBI1YFBwQLEAUBAicDAgJGEQYNBgIBAYoNCKsbgiYringBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdhlKCCAqCY4E8hiGCXwWLMYsDhm6HBItmglWIFoZdi3GIHR8?= =?us-ascii?q?4gQUmHQgYFYU2gXQ/NYkLAQEB?= X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="scan'208,217";a="652254887" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 17:08:32 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v3IH8Vq7006778; Tue, 18 Apr 2017 17:08:31 GMT To: Andy Bierman References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> Cc: Ladislav Lhotka , "t.petch" , =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= , Kent Watsen , NETMOD WG , NetMod WG Chairs From: Robert Wilton Message-ID: Date: Tue, 18 Apr 2017 18:08:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D64175936175313A231AFB47" Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:08:38 -0000 This is a multi-part message in MIME format. --------------D64175936175313A231AFB47 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 18/04/2017 17:31, Andy Bierman wrote: > > > On Tue, Apr 18, 2017 at 2:32 AM, Robert Wilton > wrote: > > > > On 13/04/2017 17:08, Andy Bierman wrote: >> >> >> On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka > > wrote: >> >> >> > On 13 Apr 2017, at 13:34, t.petch > > wrote: >> > >> > >> > ----- Original Message ----- >> > From: "Andy Bierman" > > >> > Sent: Wednesday, April 12, 2017 5:44 PM >> > >> >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < >> >> j.schoenwaelder@jacobs-university.de >> > wrote: >> >> >> >>> I think it is crucial that descriptions etc. remain human >> readable >> >>> using plain text readers. Having to run a renderer to >> make sense out >> >>> of descriptions etc. would be a big failure and things >> are even >> > worse >> >>> if modules use different dialects all over the place. >> >>> >> >>> I believe there is way more important work to get done >> than this >> > (and >> >>> I fear endless discussions about which adapted subsets of >> markdown >> > or >> >>> (whatever comes next) to use). I do not object this work, >> but I also >> >>> do not support it at this point in time. >> >>> >> >>> >> >> +1 >> >> >> >> IMO this makes YANG less readable, especially without any >> agreement >> >> on the specific markup supported. A YANG module should be >> readable by >> > humans >> >> without any special tools required. >> > >> > I agree. I would say that if you cannot say it in >> text/plain, then you >> > probably should not be saying it (something I would extend >> to e-mail but >> > realise that I am less likely to get support there:-) >> >> OK, so if somebody writes >> >> leaf foo { >> description "This is my *favourite* leaf."; >> type string; >> } >> >> >> Your premise is that the description-stmt is for the >> benefit of the model writer, not the model reader. >> Since YANG explicitly states this statement contains a human-readable >> string, it seems clear the benefit to the readers is more important. > > I see that the benefit of allowing markdown really is for the > model reader. Longer term, I assume that operators using YANG > models probably won't interact so much with the raw YANG models > themselves, but will be much more likely to interact with the > constructed tree structure through a web browser, or generated APIs. > > > IMO it is more robust not to assume people never see the real YANG > statements. I don't want the real YANG statements to become unreadable or even less readable. But I think that description formatted as markdown is quite readable anyway (which is why people choose to use it). > What if these tools have bugs? How would we ever know? > > Allowing markup, e.g. so a paragraph of text can re-flow to fill a > box seems useful to me, as does some sort of emphasis and lists. > > > > This part confuses me. I've written YANG to HTML tools (e.g., > netconfcentral.org ). > The tool has to render the entire module, not individual > description-stmts. > Emphasis is usually formula-driven (like the keywords). The tool has > to know about the entire YANG module, not > just the descriptions. You render the module exactly as you do today, but allows the description statements to be formatted cleanly. E.g. looking at your tool, the formatting of the description text looks a bit clunky in places. In some places, you have a wide box, but the description is rendered in a monospace format, with lines artificially wrapping half way across the box. It seems that the description isn't being treated as a string so much as a manual space character formatted block of text. In other places, you have allowed the description statement to re-flow to fit the box, but this will be messy/wrong if the author has used whitespace to format the description. Using markup would allow both cases to rendered correctly. > > > I also note that quite a lot (most?) language API documentation > tools generally take some form of structured text, rather than > relying on text/plain. > > > This makes sense if > (1) the entire document is subject to markup, not little pieces The rest of YANG is already structured, no markup is required. > (2) the only tool that needs to use the raw markup is a browser It doesn't have to just be a browser, it can be rendered for anything. Browser, print, mobile, whatever. > (3) the actual markup allowed is strictly controlled and standardized This I agree with, hence why I proposed that only a small common subset of markdown be specified. > > > But I do agree to the point that this work seems less urgent than > some of other items that are being worked on in NETMOD. > > > Good -- work such as the OpenConfig module catalog will have a much > bigger impact > demystifying YANG than bold text or an IMG bullet points instead of *. > > > Rob > > > > > > > > Andy > Rob --------------D64175936175313A231AFB47 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 18/04/2017 17:31, Andy Bierman wrote:


On Tue, Apr 18, 2017 at 2:32 AM, Robert Wilton <rwilton@cisco.com> wrote:



On 13/04/2017 17:08, Andy Bierman wrote:


On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 13 Apr 2017, at 13:34, t.petch <ietfc@btconnect.com> wrote:
>
>
> ----- Original Message -----
> From: "Andy Bierman" <andy@yumaworks.com>
> Sent: Wednesday, April 12, 2017 5:44 PM
>
>> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> I think it is crucial that descriptions etc. remain human readable
>>> using plain text readers. Having to run a renderer to make sense out
>>> of descriptions etc. would be a big failure and things are even
> worse
>>> if modules use different dialects all over the place.
>>>
>>> I believe there is way more important work to get done than this
> (and
>>> I fear endless discussions about which adapted subsets of markdown
> or
>>> (whatever comes next) to use). I do not object this work, but I also
>>> do not support it at this point in time.
>>>
>>>
>> +1
>>
>> IMO this makes YANG less readable, especially without any agreement
>> on the specific markup supported. A YANG module should be readable by
> humans
>> without any special tools required.
>
> I agree.  I would say that if you cannot say it in text/plain, then you
> probably should not be saying it (something I would extend to e-mail but
> realise that I am less likely to get support there:-)

OK, so if somebody writes

leaf foo {
    description "This is my *favourite* leaf.";
    type string;
}


Your premise is that the description-stmt is for the
benefit of the model writer, not the model reader.
Since YANG explicitly states this statement contains a human-readable
string, it seems clear the benefit to the readers is more important.

I see that the benefit of allowing markdown really is for the model reader.  Longer term, I assume that operators using YANG models probably won't interact so much with the raw YANG models themselves, but will be much more likely to interact with the constructed tree structure through a web browser, or generated APIs.


IMO it is more robust not to assume people never see the real YANG statements.
I don't want the real YANG statements to become unreadable or even less readable.  But I think that description formatted as markdown is quite readable anyway (which is why people choose to use it).


What if these tools have bugs?  How would we ever know?

Allowing markup, e.g. so a paragraph of text can re-flow to fill a box seems useful to me, as does some sort of emphasis and lists.


This part confuses me.  I've written YANG to HTML tools (e.g., netconfcentral.org).
The tool has to render the entire module, not individual description-stmts.
Emphasis is usually formula-driven (like the keywords). The tool has to know about the entire YANG module, not
just the descriptions.
You render the module exactly as you do today, but allows the description statements to be formatted cleanly.

E.g. looking at your tool, the formatting of the description text looks a bit clunky in places.  In some places, you have a wide box, but the description is rendered in a monospace format, with lines artificially wrapping half way across the box.  It seems that the description isn't being treated as a string so much as a manual space character formatted block of text.

In other places, you have allowed the description statement to re-flow to fit the box, but this will be messy/wrong if the author has used whitespace to format the description.

Using markup would allow both cases to rendered correctly.


 

I also note that quite a lot (most?) language API documentation tools generally take some form of structured text, rather than relying on text/plain.

 
This makes sense if 
  (1) the entire document is subject to markup, not little pieces
The rest of YANG is already structured, no markup is required.


  (2) the only tool that needs to use the raw markup is a browser
It doesn't have to just be a browser, it can be rendered for anything.  Browser, print, mobile, whatever.


  (3) the actual markup allowed is strictly controlled and standardized
This I agree with, hence why I proposed that only a small common subset of markdown be specified.



But I do agree to the point that this work seems less urgent than some of other items that are being worked on in NETMOD.

Good -- work such as the OpenConfig module catalog will have a much bigger impact
demystifying YANG than bold text or an IMG bullet points instead of *.
 

Rob







Andy

Rob
--------------D64175936175313A231AFB47-- From nobody Tue Apr 18 10:24:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E803E12EBD5; Tue, 18 Apr 2017 10:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obSLKhBL37fg; Tue, 18 Apr 2017 10:24:28 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A579128DE7; Tue, 18 Apr 2017 10:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=37CfAfo3J1JJjBEPNCA9VhrMx+mP75WuBwTeYIW5Nho=; b=Gq+G6eOCct93xjBCnCb7dz4pTOw6a3ZL/doJbpYsSIE5YqcYF/6w2fo6i+OAhNAQ2kwqAhWkiVYYzmtI5WT5+UqKh8xkx86iEAq2eAxqBbcmSX3s6VzR/yYB/j1ZhseZSt4krMm0oOR4OU/Jr/JtPJnQf0t9TOKw5p0fj6n1j/k= Received: from DM5PR05CA0014.namprd05.prod.outlook.com (10.173.226.24) by SN2PR05MB2493.namprd05.prod.outlook.com (10.166.213.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Tue, 18 Apr 2017 17:24:26 +0000 Received: from DM3NAM05FT003.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by DM5PR05CA0014.outlook.office365.com (2603:10b6:3:d4::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Tue, 18 Apr 2017 17:24:27 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT003.mail.protection.outlook.com (10.152.98.108) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Tue, 18 Apr 2017 17:24:26 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Apr 2017 10:24:17 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v3IHOGfe007433; Tue, 18 Apr 2017 10:24:17 -0700 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v3IHKCJ7045659; Tue, 18 Apr 2017 13:20:12 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201704181720.v3IHKCJ7045659@idle.juniper.net> To: Andy Bierman CC: Robert Wilton , NetMod WG Chairs , NETMOD WG In-Reply-To: Date: Tue, 18 Apr 2017 13:20:11 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(2980300002)(189002)(199003)(9170700003)(2906002)(81166006)(2810700001)(1076002)(77096006)(8936002)(54356999)(8676002)(8276002)(86362001)(53416004)(105596002)(189998001)(50986999)(558084003)(6246003)(76506005)(230783001)(47776003)(48376002)(53936002)(38730400002)(4326008)(110136004)(54906002)(7126002)(5003940100001)(7696004)(50466002)(229853002)(2950100002)(6916009)(5660300001)(305945005)(356003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2493; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT003; 1:awORokGaw4s0uZ70SZ3UX+x13Wt4jeLH1pC/d9jjIu2ysvjgnJz9T21n0zqJXFoOJIXYYPikVl01KnTSbB0e8LePBZVebDj4lGOcKtscb4CGw44+xHlPV2Txx31lI7jcAxfF9qNAjfqiZuinzVZgR3g/loLieKGYmJ8q+qcUH4VjVBjLVob/TQPqiC+Yy+tB7o+gd75Lky4K5LgzUz91hFCyPgHOM+6NI5GWnk0FVCeobwcGGSSLyemIl2yNeqyPeozBJKeraBAMSQQrMTKH0o00AgKCZjSmUHj+HsAhz6wSdjS4tprvwPSKG+NaIm1zzy6N6itfUco2WB9BUtxP7gjQMYPpFH2XXTab3OUeg2xFiYT/MTbUACnu8plYWZUaH5T8MYCKiWE1IHvb+6aFBOjEdfVCEQlNJC1j9ZFW+kyJmYf3EJIFkkktLnIzjSl0l33zpIphcv4kGO9whip1hTFScoq3gDAjEnyytOMafvZ41z71yD711q0Xodv8XukDN49uZ9Hi75JV7Gy1jUy8rBKewzSIIQuGmBWNfUhNcbjT+ABkkmBIIooMglpLnTyQIKxGRRaXe+C24VvsUgjrrMqwBht7WbZuHJXTXhEVUggqKJaJ8mNO0BXOsn9xHKHM X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cc75abde-5aba-4f75-201e-08d4867fc3eb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR05MB2493; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 3:UerUW264aZBlDJI2XY6ZRtzbFL2DMcn0Vq9MfERwWXB8nc6Io4IlIVMUiFawIBfoRrcYsaI9APD0TYU15xE1JoufXOwJIEduSXNnddGkF2Zv/mmaGGggvGjunhC7p2pLbzoTnyqPOAlWXrATOEBg0a3FkKXIvay4tqC5rfrpFkWixWAL3WD4iYPNsbYpHp92fyNtpvYLC4m0anuoo2LNjcpvTCtJVZ2V5WkjPoQEM0T16n25ULOfyqGMnMEoMjrzyi6tupldYBd+k1d7rWC+RdgVg6U7rguNJJnb0YlH87nH3m9UB8rKomlue6a8BcDJyppfhFR5cvS18qhAcdhOafoN9dksK8E+iXaQBhcLx7tgXD8K46Uzf0F3XEkf3QUJYKoS+5OjZG2TwQXo8OEwdgX1byzHScihFj8GYjzFmoemMNlb+FmZNZbi0HdgI/OZQFVJbrQjGBqe62YbzkJ0fQ== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 25:MrrNUvifqTlnYQLPRP3hUtNxWEyrDvMP2FFRGvW0lGYn4QccM3RG20+e+ZRgHcr6oskr0y1bKFHRvDRWrrZO1eoYzYe1I6ODpZcRDc6uMQIdsqmTf0a5C5ZUQXbwST1XZ4mxye63YPQFVdAVDHrhfp1UQ2IGa7GVEukEnd99LCeGASQRwYCxAgXQQ8f7IW/YsOD66+fsw1MEGEQSTNCTVW8tSkhYLPfPY9ix6KH9fUTOsO8M9kz3RR8NUBetvTsnsL8f8fmVyTEoEBy3PNEiZy2Lkp2ITKl9oIn8g4rnc6iOnb3aTeWZHchTaUms6tyQz32eeainJQtuF+mZDPfU8wEEOpcHQLKQTksnL9oC3JF8VW2Ut0uaGmJ/m9vylwTEKUR0d6xh9FHKTNJtVVkcKbtxObCCjUkYjuTwYJqCbxt5AdUB3fGj4bUg3uXkDRZkK5QwZXj/3ZLr5n28rVOIvxOUDFbjSudc/SmRzTcGD4Y=; 31:vmNzqkm5USliM8pepv4O/XFYdtDygFVe4Jd11vegEjpMw3SmO+wiPvnjWT6tjwsfhQPOFJFIaZhgOGT+jwSrwb4HsFSVJ/L1oCLalzpHwqof3ZOJMRZ9u0z+ADeYdj00YCkmrRVQk0RCAyT0/eMJwYrYLh2PNrNP9rAVTPgtAapQH+T15z8H4EZK9KgUguul5jcvxYcRUTDPjVkAmS4rm9qIwrlOjxkGiSsppIwp9gDq1BxDYEDRRlBCXzPjDyk3 X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 20:BZGd9nzKjjj4/e+TIPaQ9ScMoHrlsbj8qKt1HFU8RMgrzDpv9NZJDWvQOWnY9jqifw+b+WY/hBRlag6iy12lKnvBiAzaZP2oInTrmYkLX0IvbVu47yccGdzBjn6Nj/7JP52iuFb6bgpK0G+q4RT+PRoNsA4Y8rtlgrHjWffVQK9bGS/Qex/vNk3xy33naLnF3+WI7+XiC/2HbaXR4SdaG++Xlj2xG2Y4Yr+95jtKgWyvQkCfwpuYEN96QNEr4elronDvvAwt6qn+xas5WMXv/7ljqmNGsFNe34fiSg29Hc4weJT/mWPd49CRlAXCAEbbWGjCfOnCbrztTLxbMoLmSUFlbSsjnVTc2Z6YPNkvFsH4Tr9Ahh6Oh5QLQxI1ef7Vs76Ty+82tIkyo5VNVPJmlY/zDzKY32u2nEXxsvGwCfBUz1eh9Ds/KZmS2FFgvZ9b0ChK9NZbHykPAq7xIhCIbZfri43iAGF1ShGglYMJVs5nn5wbye6TxMRLUcovhSis X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(8121501046)(13015025)(13024025)(13023025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(6072148); SRVR:SN2PR05MB2493; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2493; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 4:328yVGswd8GDrCKz61No4ykUHm+5tTlYNaDmn5+UuIgWcce0qe3NRYrdLnwsa31yGH8DkzZANfPbbErlLGBq2c8TKTgWrlKk+ZFQ+MfCostuslPq6ruVjPthaVJKrPOyIgzRSGsVNWkAn+dAuLlI3CFB4xgkN8hUFLpJ0eA9ziMNuAtN7SKNJBFQEjR56By7NITbk4V8K7g1lBI2dbAN3XLwBFYvVhGd/VCdwMTlebCPgqIGbOez4Az7Ak+iCY5YeWv9LVnB8eD6+jvnE+HhgNzIgIt6WJQB7dLIuJUlG/TywIAJAOg4BLyEFaUcp88caDGL+LMlsadBAhtANr+QKtGtKl4Ccq4zdIhvWo+mn7KlXfn+RNFdC1FGBd3ESv+PqnEPLxm971KDTwoLMPChatd1eFgeGt8n50U3DFB9WUvbjnXkQheq46YtrgY+jnSJqeNyJVMtIK9yTMg7dzBr9BVPIc+n701IhhVptjD/B4Cn96xwgnDP9jpgYLj94EAol4y9tDvOc4rPW19TbBiistWFxC12fVX0vdsWOAPkUKNVsDCv4RCKXbSrvDL6rc4L6Z3FOYoEvxpbnqdtNZFgk8ep+9WWF8hg7gX23BPqRY26LohW7r/HLF/4C9uYhD2A/+ZqKNjyAb0hzVF4mdldh4+BqpusW6jXCx+Zr8tzlfpn8+K9i0JoEUNdcsFcBGSod2cHlMO8wb0UITytda10IkNlBy2kzQ/0ibEkxKzhvIk/4jghcdmPSZPOqExQTffRAlTh3XPYCkEqsHaJYVP5RrxlNYkefxEbRJPC/iWxhks0aEadZUBvmjb0j98TcKxz X-Forefront-PRVS: 028166BF91 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2493; 23:nN+MeJAk6nwi8Y8Aa+0Gx7j4Ar9hXgvcPPhziaFD1?= =?us-ascii?Q?xJa8pyYl48qunztH9hTazkanl3JRdxlAz1L9muF9NROrLurZ+hS4TkU2ScBT?= =?us-ascii?Q?igRf56O1nFBLaxYc7ustqcsI6+B2X+SDwAC+y5osJ8mws9vUjvJEh/2Y3lvZ?= =?us-ascii?Q?b4X2WAaAXuBFfQVG/1WA3qjNtzBtkZcwGajUv3fg0wGUM44EHIOu1tJ1nX+N?= =?us-ascii?Q?RXxLMmEbCshiOrO2/pUAASk3lrmEm/XhAmf7wFGfTe+qik/5u96B2DZXoaFA?= =?us-ascii?Q?HPtj5QUTaf9twpy3+M8y4GRMttJjuQlH1nvDZfQ8oMecUbbdJCK2NJcF2BWD?= =?us-ascii?Q?T5G1B7Hs8NQJR/dlHlpkG+f6hb5FrcGNNZRNcQ7PFrc+2snENMjhDVfEbDJw?= =?us-ascii?Q?cdlm2jggIeW6bF+M5Ho3VBOvQUb9gheOPX7eqiSuDKkErScqpGPG5YOf9aXC?= =?us-ascii?Q?88SI7HpQobWe9xKHjgnpLwGNeS+X18Jb92exFC8y0xPN7tD0E5DuESFpVxEr?= =?us-ascii?Q?8kOVthPCQRY3XFp3ivS9khnRLYLZ2+hRMOmXggTDEAdye9GCerex9I8IY1dA?= =?us-ascii?Q?ALUxM2vmcTxB9yEeJgAFWCqSHFpu73ASCSGgmdzO1Opy1fR0GTUsZrnhpWMs?= =?us-ascii?Q?WEr50g8fI62Kst/eM+drevq6D/f7ATHXpVnmPa1WlGpNuDD7+1sPnCtXyT8S?= =?us-ascii?Q?pBqTOYghoPJuYPHGm9219RI0rgQE0Z4kd+/J3cG2aq4eAyzkZDWC5uVZ8etk?= =?us-ascii?Q?7PYjOMR1nYRAMlO8U8rBpJ3bnElM3oiFNtqlj5fFl0sKAi1h7wXUDzF2txzB?= =?us-ascii?Q?FcIpVlApfOlVTj9Wm4EHSa6WDikIXOeZDNT03TnAwyR+Bqr++0PMOhZXt/Sf?= =?us-ascii?Q?MC4mtWY+wcmI3ACZ8k+NCku6EuZlDI6xn9mCj1vbzTDZvXhm7zSn+nLmHhRI?= =?us-ascii?Q?Pwejy287xOx1RfhU636/VY4G0c+bu0KWsqHvRaNiMStZrUQwIeDHCvkP1HHG?= =?us-ascii?Q?LJavLaRKcGB0qCJv1cYQDfLFopF3zxJWPhQZdBD9Ly800JhgXkXv3iMnKA26?= =?us-ascii?Q?pNuLRc8vUcWThypOB1rHUWP1VE8RNAV7IHPDD8Nq2q3Px+ahmvP9hV2HKc+K?= =?us-ascii?Q?/qmnpxUuaoNU20rb4tSOMmoySKSrsPgvCezK3O4XLZhwXmfP25SyA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 6:GKHieX0sYdFBMu23c6+JZxS5RZqbmpmWiAve1FhIqvKc7eqOGOvgF5TEXay3qzJF53mpC03t1DQ8KDYMSf6N3i6V2AunTqIKtG7tZt2HllPYKEkFyM8xnt+7Wspozl16+jUr5qYXAW6PEcU5piGmSTii1zL6ZlZ03xHsI4YbOLn+iqJsEYONlnLbWXMqevgzUWINCZSM8v5TBBs75d3adhby8MpYe0mLoBfWZwPIXhpJxnohVY44vd0JheiEiL9ai5u8JrZ/RrIyI7n5wE5DUDjPKWMuhh2RU3jUm2lbM+bOcFL45hgoebOOad6J+jk0yD8+Ytsk/1Aak9rpqeTpavhf60a/NjOdLrn6XkOdCmThc5WyBv7267pVs6BW4o5NSe7EA/Ib+QyCgRy8ryKa3TI+4DgwMhw9DXPmtGztrnRXUWN5l5jKgu6NHdaSVT6zAp9l0UgosIbVIRNdUkxd+ml/ncJw/Xhr1R986Dc1Wz4=; 5:o5JNmuuCrPUcsr2TeItKPXnCJVINQfUy1PDFznbmupMpU3+wMsnF8mPr+LZaBzSFQZnre+Nf6jgRlhaFNLTc2Cy6tQ8Rzyh7dKKq+CONn9PEyYMWBXIqieUnz8JK1gtP51Oipw/V9zsg0ps7W4csHQ==; 24:4XSPdyxHf9u2HRR3rsZ7cWaLiVQArH/U+WHycVZagG+NUtVX3B3SloOgCdY90fkoxfgEpCAa5TOqapRVBglht2SsG9hu6Qw573cvvMZnDCk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 7:Ga4n8a6tu959FO+ink91oj5iCoJOD38W1YkroXh5zFt91p2kLEG9f0Fz4rfVounWbOzMJ8oJ+Q4CfddxBVI1vnD+y/TVGYKexQ5E6eRpKLE4caGcjfhR6adSLttRtsAe+r+lgwjHaE16hgT4mMd7mCKpYEgYtBKAENLSE3Q2ZRwF2XOeLjI/A/L6NuIqS//FFwtScNpGCg+WFP0h7w5865/VWWYKyNMuhfJrudVpOyQb6XCbJ+sXWj+CEy+xrH8igTSTPBI4QS59NOgJQAoBXPE/H6/V+SA8WUTXWAbKUCnEX2Byc5yO9m/oJE4d7SAOC2RCMKK3171ETzTuHWiB0Q== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2017 17:24:26.5367 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR05MB2493 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 17:24:30 -0000 Andy Bierman writes: >IMO it is more robust not to assume people never see the real YANG >statements. Exactly. We made YANG readable so that we wouldn't _need_ to view it using tools. This was one of the "insta-death" factors for UML. Thanks, Phil From nobody Wed Apr 19 01:30:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B664913156E; Wed, 19 Apr 2017 01:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6d7mD3vlRW3e; Wed, 19 Apr 2017 01:30:34 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 660F9131572; Wed, 19 Apr 2017 01:30:33 -0700 (PDT) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id 353A41820043; Wed, 19 Apr 2017 10:31:18 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman Cc: "t.petch" , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6Rs?= =?utf-8?B?ZGVy?= , Robert Wilton , Kent Watsen , NETMOD WG , NetMod WG Chairs In-Reply-To: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> Date: Wed, 19 Apr 2017 10:30:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:30:38 -0000 Andy Bierman writes: > On Thu, Apr 13, 2017 at 11:41 AM, Ladislav Lhotka wrote: > >> >> > On 13 Apr 2017, at 18:08, Andy Bierman wrote: >> > >> > >> > >> > On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka wrote: >> > >> > > On 13 Apr 2017, at 13:34, t.petch wrote: >> > > >> > > >> > > ----- Original Message ----- >> > > From: "Andy Bierman" >> > > Sent: Wednesday, April 12, 2017 5:44 PM >> > > >> > >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < >> > >> j.schoenwaelder@jacobs-university.de> wrote: >> > >> >> > >>> I think it is crucial that descriptions etc. remain human readable >> > >>> using plain text readers. Having to run a renderer to make sense out >> > >>> of descriptions etc. would be a big failure and things are even >> > > worse >> > >>> if modules use different dialects all over the place. >> > >>> >> > >>> I believe there is way more important work to get done than this >> > > (and >> > >>> I fear endless discussions about which adapted subsets of markdown >> > > or >> > >>> (whatever comes next) to use). I do not object this work, but I also >> > >>> do not support it at this point in time. >> > >>> >> > >>> >> > >> +1 >> > >> >> > >> IMO this makes YANG less readable, especially without any agreement >> > >> on the specific markup supported. A YANG module should be readable by >> > > humans >> > >> without any special tools required. >> > > >> > > I agree. I would say that if you cannot say it in text/plain, then you >> > > probably should not be saying it (something I would extend to e-mail >> but >> > > realise that I am less likely to get support there:-) >> > >> > OK, so if somebody writes >> > >> > leaf foo { >> > description "This is my *favourite* leaf."; >> > type string; >> > } >> > >> > >> > Your premise is that the description-stmt is for the >> > benefit of the model writer, not the model reader. >> >> My premise is that such *lightweight* markup is being used and will be >> used. So it is better to be prepared, and accomodate it in an acceptable >> form, rather than fight it. >> > > > You mean there are YANG RFCs that contain markup in > description-stmts? A trivial one is, for example, bulleted lists are quite common. So it would be helpful to add ymt:text-media-type "text/markdown; charset=UTF-8"; even to these RFCs because then processing tools can expect bulleted lists to be formatted according to markdown rules, e.g. [1] List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab. Another example are hyperlinks that sometimes occur, e.g., in "reference" statements. They are formatted in various different ways, and there is IMO nothing wrong (or unreadable) on using markdown conventions, for example [ISO9834-1](https://www.iso.org/standard/58055.html "Information technology -- Open Systems Interconnection -- Procedures for the operation of OSI Registration Authorities: General procedures and top arcs of the ASN.1 Object Identifier tree") Moreover, not all YANG modules are being produced in the IETF. William Lupton noted proviously that mediawiki-like markup is supported in TR-069 data model description strings. And finally, I do believe (as William also suggested) that YANG could benefit from YANG-specific markup constructs, especially in error messages. For example, it might be useful to be able to include incorrect values taken from actual instance data. This is not a topic of this draft but it provides a straightforward way to realize this extension. [1] https://daringfireball.net/projects/markdown/syntax#list > Indicating that both the IESG and RFC Editor have approved this practice? > If not, then such markup is not actually being used in published YANG > modules. > > > >> And I explicitly want to avoid standardizing a particular markup format, >> at this stage at least. >> >> >> > That means the burden is on the YANG reader to be aware of every possible > markup variant anybody might want to use. Of course the user must The basic assumption is that the text can be left unprocessed without being difficult to read and understand. Lightweight markup syntaxes such as markdown are unobtrusive by design. > understand > the "extra" chars thrown in with the plain English. One cannot assume it > will > be obvious to every reader which chars are extra, especially with no > constraints > at all on the markup syntax and semantics. The reader can look up the rules if necessary. I am not against standardizing something but it can be difficult to agree on a format that works for everybody and is sufficiently future-proof. Lada > > > Andy > > > > >> > Since YANG explicitly states this statement contains a human-readable >> > string, it seems clear the benefit to the readers is more important. >> >> What exactly is non-human-readable in my example? >> >> Moreover, different communities may want to add e.g. metadata in a certain >> formalized format. To some extent, we already do it in the initial >> decription of our modules. IMO there is nothing wrong on specifying the >> format that is being used. >> >> > >> > >> > you may not like it, but it is absolutely legal and IMO also readable by >> humans. As William previously mentioned, some communities are already doing >> similar things. The principal aim of my I-D is to allow module authors to >> explicitly state that they adhere to some rules, which helps authors of >> tools reduce guesswork. >> > >> > >> > You may decide to ignore the intent of the description-stmt. >> > That doesn't mean we should change the definition in the standard. >> > IMO plain text is human-readable. Anything that requires parsing, >> > reinterpreting and re-rendering is not human friendly. >> >> My draft doesn't propose anything like this. Lightweight markup such as >> markdown doesn't require parsing, and is as human-readable as anything else. >> >> Lada >> >> > >> > >> > The example with email is actually very relevant. I would also love if >> people and MUAs only used plain text but, as you say, this is not going to >> happen. If we accept this as a fact, is it better or worse for >> interoperability that MUAs provide media type in mail headers? >> > >> > Lada >> > >> > Andy >> > >> > >> > > >> > > Tom Petch >> > > >> > >>> /js >> > >>> >> > >>> >> > >> Andy >> > >> >> > >> >> > >>> On Wed, Apr 12, 2017 at 02:53:08PM +0200, Ladislav Lhotka wrote: >> > >>>> Robert Wilton writes: >> > >>>> >> > >>>>> Yes/support. But with the condition that I would still like the >> > > draft >> > >>>>> to define a basic common subset of markdown fields/annotations >> > > that >> > >>>>> implementations would be expected to support. For clarity, I'm >> > > not >> > >>>>> suggesting that the draft should define a new markdown language, >> > > I >> > >>> think >> > >>>>> that it would be better to use an existing markdown language, >> > > but >> > >>>>> perhaps simplified. >> > >>>> >> > >>>> In my view, this needs to remain purely optional, so >> > > implementations >> > >>>> won't be expected to support anything. It should be perfectly fine >> > > to >> > >>>> leave description texts unprocessed, or process only selected >> > >>>> constructs. >> > >>>> >> > >>>>> >> > >>>>> I want to avoid the scenario where each group of YANG modelers >> > > could >> > >>>>> decide to use a different incompatible variant of text/markdown, >> > > and >> > >>>>> hence generic tools would not be able to reliably render the >> > > markup for >> > >>>>> a generic YANG module. >> > >>>> >> > >>>> On the other hand, particular markup conventions might be dictated >> > > by >> > >>>> external circumstances. For example, for modules hosted at GitHub, >> > > the >> > >>>> GFM variant of text/markdown looks like a natural choice but >> > > elsewhere >> > >>>> it can be something different. William also suggested that certain >> > >>>> YANG-specific constructs may also be introduced. >> > >>>> >> > >>>>> >> > >>>>> Care would need to be taken with which variant of the Markdown >> > > language >> > >>>>> is chosen as a base (RFC 7764 may be of use) . E.g. the github >> > > markup >> > >>>>> language has been previously suggested, but the specification >> > > document >> > >>>>> for that variant is long (approx 120 pages). >> > >>>> >> > >>>> RFC 7763 also notes that markdown itself by design has no concept >> > > of >> > >>>> validity, so I think it is appropriate to take it easy and avoid >> > >>>> overspecifying things. >> > >>>> >> > >>>> I guess the key point here is "lighweight markup": if and >> > > implementation >> > >>>> can make use of it, then fine, but module readers should have >> > > little >> > >>>> difficulty if not. >> > >>>> >> > >>>> Thanks, Lada >> > >>>> >> > >>>>> >> > >>>>> Thanks, >> > >>>>> Rob >> > >>>>> >> > >>>>> >> > >>>>> On 10/04/2017 12:45, Ladislav Lhotka wrote: >> > >>>>>> As the author: yes/support. >> > >>>>>> >> > >>>>>> Two changes seemed to have support in IETF 98 audience: >> > >>>>>> >> > >>>>>> 1. Apart from text/plain, the media type SHOULD be >> > > text/markdown >> > >>>>>> (variants permitted). >> > >>>>>> >> > >>>>>> 2. The "text-media-type" extension can appear anywhere in a >> > >>> (sub)module, >> > >>>>>> and will be scoped to the parent statement and its substaments >> > > (unless >> > >>>>>> overriden). >> > >>>>>> >> > >>>>>> Lada >> > >>>>>> >> > >>>>>> Kent Watsen writes: >> > >>>>>> >> > >>>>>>> All, >> > >>>>>>> >> > >>>>>>> This is start of a two-week poll on making the following draft >> > > a >> > >>>>>>> NETMOD working group document: >> > >>>>>>> >> > >>>>>>> draft-lhotka-netmod-yang-markup-00 >> > >>>>>>> >> > >>>>>>> Please send email to the list indicating "yes/support" or >> > > "no/do not >> > >>>>>>> support". If indicating no, please state your reservations >> > > with the >> > >>>>>>> document. If yes, please also feel free to provide comments >> > > you'd >> > >>>>>>> like to see addressed once the document is a WG document. >> > >>>>>>> >> > >>>>>>> Thank you, >> > >>>>>>> NETMOD WG Chairs >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> _______________________________________________ >> > >>>>>>> netmod mailing list >> > >>>>>>> netmod@ietf.org >> > >>>>>>> https://www.ietf.org/mailman/listinfo/netmod >> > >>>>> >> > >>>> >> > >>>> -- >> > >>>> Ladislav Lhotka, CZ.NIC Labs >> > >>>> PGP Key ID: 0xB8F92B08A9F76C67 >> > >>>> >> > >>>> _______________________________________________ >> > >>>> netmod mailing list >> > >>>> netmod@ietf.org >> > >>>> https://www.ietf.org/mailman/listinfo/netmod >> > >>> >> > >>> -- >> > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> > > Germany >> > >>> Fax: +49 421 200 3103 >> > >>> >> > >>> _______________________________________________ >> > >>> netmod mailing list >> > >>> netmod@ietf.org >> > >>> https://www.ietf.org/mailman/listinfo/netmod >> > >>> >> > >> >> > > >> > > >> > > ------------------------------------------------------------ >> ------------ >> > > -------- >> > > >> > > >> > >> _______________________________________________ >> > >> netmod mailing list >> > >> netmod@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/netmod >> > >> > -- >> > Ladislav Lhotka, CZ.NIC Labs >> > PGP Key ID: 0xB8F92B08A9F76C67 >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 19 01:50:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD2313158E for ; Wed, 19 Apr 2017 01:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DXjaLd57-FNS for ; Wed, 19 Apr 2017 01:50:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8A929131589 for ; Wed, 19 Apr 2017 01:50:12 -0700 (PDT) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id 3049C1820043; Wed, 19 Apr 2017 10:50:59 +0200 (CEST) From: Ladislav Lhotka To: heasley , netmod@ietf.org In-Reply-To: <20170414003426.GO2149@shrubbery.net> References: <20170414003426.GO2149@shrubbery.net> Date: Wed, 19 Apr 2017 10:50:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] netmod Digest, Vol 109, Issue 17 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:50:14 -0000 heasley writes: >> > On 13 Apr 2017, at 09:14, Juergen Schoenwaelder wrote: >> > >> > On Thu, Apr 13, 2017 at 08:28:08AM +0200, Ladislav Lhotka wrote: >> >> >> >> We are talking past each other. Are you willing to admit that my draft has nothing to do with the *presence* of markup in a description text, as long as it remains a valid YANG string? >> >> >> > >> > I think you do not understand what I am saying. The main purpose of >> > description statements etc. is that they are easily to read by humans. >> > >> > 7.21.3. The "description" Statement >> > >> > The "description" statement takes as an argument a string that >> > contains a human-readable textual description of this definition. >> > >> > I disagree with your claim that human-readable text is markup. The >> > whole RFC series is formatted human-readable text, not markup. I >> > believe this work is heading in the wrong direction, it will lead to >> > endless discussions of many different flavors of markup used in >> > description clauses, and it will harm interoperability at the human >> > eye level. >> > >> > I believe there are way more important problems to work on. I am out >> > of this thread (since there is more important work to do). >> >> I believe your discussion habits are sometimes aggressive and unacceptable. >> >> Lada > > I think that Juergen is to the point - and along with Andy is quite correct > that this seems like a distraction and unnecessary. Neither I nor the draft propose anything that would be difficult to read in an unprocessed form. The draft says it quite clearly: It is RECOMMENDED to use only media types representing "lightweight" markup that is easy to read even in the unprocessed source form, such as "text/markdown". I don't mind adding another recommendation that even lightweight markup be used sparingly but, on the other hand, I don't see any reason to ban it. Those who think it is uinmportant or unnecessary can simply avoid it in their YANG modules and ignore this document and the extension defined therein. Lada > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 19 02:09:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E057B1315AD; Wed, 19 Apr 2017 02:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XGZIH2Yptvp0; Wed, 19 Apr 2017 02:09:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 36D551315AC; Wed, 19 Apr 2017 02:09:12 -0700 (PDT) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id 014491820043; Wed, 19 Apr 2017 11:09:58 +0200 (CEST) From: Ladislav Lhotka To: Robert Wilton , Andy Bierman Cc: "t.petch" , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6Rs?= =?utf-8?B?ZGVy?= , Kent Watsen , NETMOD WG , NetMod WG Chairs In-Reply-To: References: <10335DBC-AF4B-4CEF-AC4C-F0E4D27C13A6@juniper.net> <80e51c0a-9463-8ebe-c35d-9f1fae8c07e9@cisco.com> <20170412130207.GA83817@elstar.local> <06e201d2b44f$35c0a780$4001a8c0@gateway.2wire.net> <82424428-C5C0-4EA8-BBD2-6F52EEFD300F@nic.cz> Date: Wed, 19 Apr 2017 11:09:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 09:09:14 -0000 Robert Wilton writes: > On 13/04/2017 17:08, Andy Bierman wrote: >> >> >> On Thu, Apr 13, 2017 at 5:45 AM, Ladislav Lhotka > > wrote: >> >> >> > On 13 Apr 2017, at 13:34, t.petch > > wrote: >> > >> > >> > ----- Original Message ----- >> > From: "Andy Bierman" > > >> > Sent: Wednesday, April 12, 2017 5:44 PM >> > >> >> On Wed, Apr 12, 2017 at 6:02 AM, Juergen Schoenwaelder < >> >> j.schoenwaelder@jacobs-university.de >> > wrote: >> >> >> >>> I think it is crucial that descriptions etc. remain human readable >> >>> using plain text readers. Having to run a renderer to make >> sense out >> >>> of descriptions etc. would be a big failure and things are even >> > worse >> >>> if modules use different dialects all over the place. >> >>> >> >>> I believe there is way more important work to get done than this >> > (and >> >>> I fear endless discussions about which adapted subsets of markdown >> > or >> >>> (whatever comes next) to use). I do not object this work, but >> I also >> >>> do not support it at this point in time. >> >>> >> >>> >> >> +1 >> >> >> >> IMO this makes YANG less readable, especially without any agreement >> >> on the specific markup supported. A YANG module should be >> readable by >> > humans >> >> without any special tools required. >> > >> > I agree. I would say that if you cannot say it in text/plain, >> then you >> > probably should not be saying it (something I would extend to >> e-mail but >> > realise that I am less likely to get support there:-) >> >> OK, so if somebody writes >> >> leaf foo { >> description "This is my *favourite* leaf."; >> type string; >> } >> >> >> Your premise is that the description-stmt is for the >> benefit of the model writer, not the model reader. >> Since YANG explicitly states this statement contains a human-readable >> string, it seems clear the benefit to the readers is more important. > > I see that the benefit of allowing markdown really is for the model > reader. Longer term, I assume that operators using YANG models probably > won't interact so much with the raw YANG models themselves, but will be > much more likely to interact with the constructed tree structure through > a web browser, or generated APIs. > > Allowing markup, e.g. so a paragraph of text can re-flow to fill a box > seems useful to me, as does some sort of emphasis and lists. Absolutely. People are converting YANG modules to UML and other formats. > > I also note that quite a lot (most?) language API documentation tools > generally take some form of structured text, rather than relying on > text/plain. > > But I do agree to the point that this work seems less urgent than some > of other items that are being worked on in NETMOD. Of course, I am far from claiming that this is urgent or terribly important, I just realized in my recent work that lightweight markup can make life of tool makers easier without significantly complicating the reading of module source text. Lada > > Rob > > > > > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 19 02:35:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40540128CFF; Wed, 19 Apr 2017 02:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7qeOOZAqAjY5; Wed, 19 Apr 2017 02:35:11 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6604F1293D6; Wed, 19 Apr 2017 02:35:11 -0700 (PDT) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id B3C3F1820043; Wed, 19 Apr 2017 11:35:58 +0200 (CEST) From: Ladislav Lhotka To: Phil Shafer , Andy Bierman Cc: NetMod WG Chairs , NETMOD WG In-Reply-To: <201704181720.v3IHKCJ7045659@idle.juniper.net> References: <201704181720.v3IHKCJ7045659@idle.juniper.net> Date: Wed, 19 Apr 2017 11:35:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 09:35:13 -0000 Phil Shafer writes: > Andy Bierman writes: >>IMO it is more robust not to assume people never see the real YANG >>statements. > > Exactly. We made YANG readable so that we wouldn't _need_ to view > it using tools. This was one of the "insta-death" factors for UML. I have to reiterate that the idea is to continue to be able to view YANG modules *without* using tools, but provide some aid to tools that can make use of certain well-defined lightweight markup conventions. Everybody with a practical experience of converting YANG automatically to something else (not only to HTML, it starts already with YIN) knows that transferring descriptions and other similar texts is tricky. Lada > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Apr 19 12:43:36 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BB3129526 for ; Wed, 19 Apr 2017 12:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sz-daDeq3Abs for ; Wed, 19 Apr 2017 12:43:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0109.outbound.protection.outlook.com [104.47.41.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D9C129C40 for ; Wed, 19 Apr 2017 12:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MZbQXelm6qfuBF0bW2hTIzgRZd5cZVWNWLi5Wvpmmz0=; b=HNzk67XVBs3RHKoyy9spiBKAlU+j/wRajbPEDkMZ6cT/d84dv/dZyZCYfzGXw+zXHKl8zz6+XWLttPQBFnWNJAODGc04KXCyl6tv5j/cK3Oy/ZJX04ketuVHeVPmGAyWIsPHLXt3lkHG6f+WQBPPXX1xUQo1bNbcIJ85/GxLpKs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 19:43:26 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1047.006; Wed, 19 Apr 2017 19:43:25 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: regarding yang-next Thread-Index: AQHSuUU1r9YWPr1F8UiDeRS+con7uQ== Date: Wed, 19 Apr 2017 19:43:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:aAdmzKk+dtBRElSsMjEwHg/L02CX7OwCNDvgRaShWFZTsdMb/ksAFwTLfeJVUOMncC02qq9BU5TfdnW8H+x0BjMrGDdZKKU9bPRCwW98Mmmng9hwDjewGTeEByISld5Da/1u9b94otXxdw3tYYV46vX8Ci+IJJTkspGf+aDjReUiPV/PFhR2vmmYoCtJj9EtH8nbrfwzNeOLmh4W7DRie10LKOQj1wE+QP+pRklwTry6KaEE5KuyXYGw6O14OEnn6VAblZcREyLbh+s5yL4n7Y4zVt8JwrcD+oy3B8REgJbi6o2w/WtZIToP5ChyVCSrFHK+42wTsDbHM4a1K91ymQ== x-ms-office365-filtering-correlation-id: d488ae5a-cd0b-43f3-6d8c-08d4875c5881 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1444; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39450400003)(39410400002)(39860400002)(39840400002)(39400400002)(4001350100001)(2351001)(83506001)(82746002)(5640700003)(99286003)(6306002)(6512007)(83716003)(66066001)(6436002)(2501003)(6916009)(38730400002)(5660300001)(110136004)(6506006)(77096006)(86362001)(3660700001)(25786009)(53936002)(189998001)(2900100001)(6486002)(50986999)(54356999)(305945005)(33656002)(8676002)(2906002)(1730700003)(81166006)(3280700002)(122556002)(8936002)(6116002)(102836003)(3846002)(7736002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <356A55B41B989D4E94E3D72CED1403BD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 19:43:25.4918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444 Archived-At: Subject: [netmod] regarding yang-next X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:43:35 -0000 DQpUaGUgWUFORyBOZXh0IGRpc2N1c3Npb24gZnJvbSB0aGUgQ2hpY2FnbyBtZWV0aW5nIHdhcyBp bnRlcmVzdGluZy4gIA0KV2hhdCBJIHRvb2sgYXdheSBmcm9tIGl0IGlzIHRoYXQgaXQgd291bGQg YmUgZ29vZCB0byBmaW5kIGEgd2F5IA0KdG8gdXBkYXRlIFlBTkcgbW9yZSByYXBpZGx5LCBzb21l d2hhdCBsaWtlIGNvZGUgd2l0aCBwYXRjaGVzIGFuZA0KYnJhbmNoZXMuDQoNCkluIHRoZSBlbmQs IEkgdmlld2VkIHRoaXMgbW9yZSBvZiBhbiBSRkMtcHVibGlzaGluZyB0aGluZyB0aGFuIGENCk5F VE1PRCB0aGluZy4gIEZvciBpbnN0YW5jZSwgaW1hZ2luZSB3ZSBoYXZlOg0KDQogIDc5NTAgLSBZ QU5HIDEuMQ0KICA4eHh4IC0gVGhlICdtYXAnIHN0YXRlbWVudCAgICAgICAodXBkYXRlcyA3OTUw KQ0KICA4eXl5IC0gVGhlICd0ZW1wbGF0ZScgc3RhdGVtZW50ICAodXBkYXRlcyA3OTUwKQ0KICA4 enp6IC0gVGhlICdpbmFjdGl2ZScgYXR0cmlidXRlICAodXBkYXRlcyA3OTUwKQ0KICA5OTk5IC0g WUFORyAxLjIgPSBZMS4xICsgOHh4eCArIDh5eXkgKyA4enp6DQoNCkkgZG91YnQgdGhhdCB0aGUg UkZDIEVkaXRvciB3b3VsZCBldmVyIGRvIHNvbWV0aGluZyBhcyBjYWxsb3VzIGFzIA0KdGhhdCBi dXQsIHN0aWxsLCB0aGUgdGFrZWF3YXkgZm9yIHVzLCBmb3Igbm93IGF0IGxlYXN0LCBpcyB0byB3 b3JrDQpvbiBzaW1wbGUgZHJhZnRzIHRoYXQgdXBkYXRlIDc5NTAgcmF0aGVyIHRoYW4gd29yayBv biBhIDc5NTBiaXMuDQoNClNvIHRoYXQgc2V0dGxlcyB0aGUgWUFORyBOZXh0IGRpc2N1c3Npb24g Zm9yIGEgd2hpbGUuICBQbGVhc2Ugc3RpbGwNCnVzZSB0aGUgWWFuZyBOZXh0IGlzc3VlIHRyYWNr ZXIgd2hlbiB5b3UgaGF2ZSBpZGVhcyBmb3IgWUFORyBjYW4gYmUNCmltcHJvdmVkOiAgaHR0cHM6 Ly9naXRodWIuY29tL25ldG1vZC13Zy95YW5nLW5leHQvaXNzdWVzLg0KDQpUaGFua3MsDQpLZW50 IC8vIGNvLWNoYWlyDQoNCg0KDQoNCg0K From nobody Wed Apr 19 12:49:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096CA12948B for ; Wed, 19 Apr 2017 12:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1NN10Pgx46s for ; Wed, 19 Apr 2017 12:49:53 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0112.outbound.protection.outlook.com [104.47.34.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C795128D40 for ; Wed, 19 Apr 2017 12:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xXyq0V4JCgGhrD5w35KZlXaO7j9Nv+XSu0Zrxt3+6fM=; b=Xq7wyLQJmK0MYzFPcBsvK4hWVTNQgZo89fkKNU80mYNTHf8XxgOrzCf82kOxjghUqGmKbOa3CWGc5El2SkuI0q+ecTOuzbMLuwdWZeEZlpwRbR3RbOY7MI/IIXoW7Abv2uwEJRbiHtGfiK+ZWooV0HYeQZYsdPJKC1R/5y4wKGE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 19:49:52 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1047.006; Wed, 19 Apr 2017 19:49:52 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: draft minutes posted Thread-Index: AQHSuUYcDAK8V16RmEagDqN1Us4WYw== Date: Wed, 19 Apr 2017 19:49:52 +0000 Message-ID: <16450BC2-5BB9-4F54-B2ED-B502DB0E2E20@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:ID3wU/ehTRnsQHiqjRy5FBwrecPWa6kGXUShp6XXUfeY3Z+d/U3S/AO0UzoYHMuapEcmkn/CWUpzKUigmmExT1OXAvd+vzT51qnF7e9mXRug+T57iELxZSHff5Bw1FSChbAeA9XgaSVZZBW75vhfwhzuX0QedqcR8N0xH8rsSBX7Ocgaw0ZYfCCQQMTT1gUjnnKcctDpGN2eOb6rQ5GPhk/Dc8Zn0I6TI4YIZeophaVQ0tXR1JEni776EffpLwRbRPaRTTVxzA4MWwgHw0tYOD9aBQaWtvwZKVTZt5xpBVBkDqMJyXOLvN8uPjb/5v8sxTf2mDAFINQjFWgpied1vg== x-ms-office365-filtering-correlation-id: aa47bc78-4a2e-455d-bb1b-08d4875d3f0f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(279900001)(8936002)(36756003)(3480700004)(189998001)(86362001)(2501003)(4001350100001)(93376004)(7116003)(5660300001)(1730700003)(8676002)(81166006)(54356999)(50986999)(33656002)(2351001)(2906002)(110136004)(38730400002)(3660700001)(3280700002)(6916009)(2900100001)(66066001)(122556002)(305945005)(7736002)(25786009)(99286003)(6306002)(53936002)(6512007)(83716003)(6116002)(102836003)(3846002)(77096006)(966004)(6486002)(6436002)(6506006)(83506001)(82746002)(5640700003)(133083001)(15302535012); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7F4AB617E4E41F47A50A70032549B8C0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 19:49:52.3854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [netmod] draft minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 19:49:55 -0000 DQpBbGwsIChlc3BlY2lhbGx5IHByZXNlbnRlcnMhKSwNCg0KUGxlYXNlIHRha2UgYSBsb29rIGF0 IHRoZSBtZWV0aW5nIG1pbnV0ZXMgaGVyZToNCg0KICBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0 Zi5vcmc6OTAwMC9wL25vdGVzLWlldGYtOTgtbmV0bW9kDQoNCk1pY2hhZWwsIExvdSwgYW5kIEkg aGF2ZSB1cGRhdGVkIHRoZSBldGhlcnBhZCBzaW5jZSB0aGUgbWVldGluZw0KdG8gZmlsbCBpbiBt aXNzaW5nIG9yIGltY29tcGxldGUgY29tbWVudHMsIGFzIHdlbGwgYXMgdG8gZml4DQp0eXBvcyBh bmQgZmlsbCBpbiBjb21wbGV0ZSBuYW1lcy4gIFN0aWxsLCB0aGVyZSBpcyBhIGNoYW5jZSB0aGF0 DQpzb21ldGhpbmcgd2FzIG1pc3NlZC4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIExvdSkNCg0KDQo= From nobody Wed Apr 19 14:05:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D17129400; Wed, 19 Apr 2017 14:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4jOaKgqClH6; Wed, 19 Apr 2017 14:05:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0125.outbound.protection.outlook.com [104.47.38.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4B8129BE0; Wed, 19 Apr 2017 14:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Fe/FXZl2Cju/HIPGVTTLz8bK/a6aRDMAm72pfNS+Oo=; b=VQBxYbc2LziVRIeqNaZceB1SfsN0xNtDwaWila51TNPxwcn+jjXmJ7YEMCBHEnKL/NmNEutGhVJHQRXYgoM6NDsheWaWBuP9pbTEON3kPSpsMFewqrlv8xxDXQ1la+/7mJZEOEC6OT9OxcKPuZ8FlhdAp99rzIFXUj875tOLBxg= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by CY4PR05MB2824.namprd05.prod.outlook.com (10.169.182.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 21:05:36 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1047.006; Wed, 19 Apr 2017 21:05:36 +0000 From: Kent Watsen To: Ladislav Lhotka , Phil Shafer , "Andy Bierman" CC: NetMod WG Chairs , NETMOD WG Thread-Topic: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 Thread-Index: AQHSr/YXcDS5bbna6UeIPfM5lrW/TKG+nTTogAMc3TeAAD4cAIABRu52gAAIhYCAADjwAIAHbMmAgAB1S4CAAA2BgIABEGeAgAB92YA= Date: Wed, 19 Apr 2017 21:05:36 +0000 Message-ID: References: <201704181720.v3IHKCJ7045659@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: nic.cz; dkim=none (message not signed) header.d=none;nic.cz; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB2824; 7:Dr0IltgOdN4kufqshcxGQfNsoRxIYGZ+trglLY+I7zt7V4YEPKWQzvq8TaTft/pagRUwfQpkk+BQxr2sj20aZ/E+78FwddluXrM6MnGNOAOxUYZKCL5P3k3dHfoohtU2vOLY/F6wHiCILb1EXg7pfh3GKvcm0S968emQADYQcCKM+xE7MXl7y8ddorBRbkfbxhD1iQOzXHmemnfCwS2FICGzrNRaHZP70mbGZUAvIj9P7yyX7xQdf0heKNER3Yn64y2Iu9I0VS3Pw7fMlc02esupGqxQCew/mqalgpL8pweOu9zfTP7t7WFmmsp9X1cyMWt6U5t60IAlRTqFzKQt1Q== x-ms-office365-filtering-correlation-id: ffcb0ad8-4f66-4df0-ce58-08d48767d35b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CY4PR05MB2824; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR05MB2824; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB2824; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39410400002)(39840400002)(39400400002)(39850400002)(83506001)(83716003)(3660700001)(82746002)(77096006)(2950100002)(122556002)(36756003)(2906002)(6486002)(6246003)(25786009)(3846002)(54356999)(50986999)(38730400002)(66066001)(102836003)(4326008)(6116002)(5660300001)(76176999)(6506006)(8676002)(8936002)(6306002)(6436002)(305945005)(81166006)(53936002)(6512007)(189998001)(54906002)(86362001)(7736002)(4001350100001)(229853002)(2900100001)(3280700002)(33656002)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB2824; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 21:05:36.2141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB2824 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 21:05:40 -0000 DQpBbGwsDQoNCldlJ3JlIGEgY291cGxlIGRheXMgYXdheSBmcm9tIHRoZSAyLXdlZWsgd2luZG93 LiAgQXMgb2Ygbm93LCB0aGUNCm1ham9yaXR5IGRvZXMgbm90IHN1cHBvcnQgYWRvcHRpbmcgdGhp cyBkcmFmdC4gIEFueSByZW1haW5pbmcNCm9waW5pb25zPw0KDQoNCkxhZGEsDQoNClRoZSBvYmpl Y3Rpb25zIHNlZW0gdG8gYmUgY29uY2VybiBmb3IgbmV0IHJlYWRhYmlsaXR5LCBhbmQgZm9yIHRo ZQ0KaW1wb3J0YW5jZSBvZiB0aGUgcHJvYmxlbSByZWxhdGl2ZSB0byBvdGhlciBhY3Rpdml0aWVz LiAgRm9yIHRoZQ0KZm9ybWVyIGNhc2UsIGl0IG1heSBoZWxwIGlmIHlvdSBwb3N0ZWQgc29tZSBl eGFtcGxlcy4gIEZvciB0aGUgDQpsYXR0ZXIgY2FzZSwgd2UgbWF5IHdhbnQgdG8ga2VlcCB0aGlz IGRyYWZ0IGNvb2tpbmcgaW4gdGhlIA0KYmFja2dyb3VuZC4NCg0KDQpLZW50IC8vIGFzIGNvLWNo YWlyIGFuZCBwb3RlbnRpYWwgc2hlcGhlcmQNCg0KDQoNClBoaWwgU2hhZmVyIDxwaGlsQGp1bmlw ZXIubmV0PiB3cml0ZXM6DQoNCj4gQW5keSBCaWVybWFuIHdyaXRlczoNCj4+SU1PIGl0IGlzIG1v cmUgcm9idXN0IG5vdCB0byBhc3N1bWUgcGVvcGxlIG5ldmVyIHNlZSB0aGUgcmVhbCBZQU5HDQo+ PnN0YXRlbWVudHMuDQo+DQo+IEV4YWN0bHkuICBXZSBtYWRlIFlBTkcgcmVhZGFibGUgc28gdGhh dCB3ZSB3b3VsZG4ndCBfbmVlZF8gdG8gdmlldw0KPiBpdCB1c2luZyB0b29scy4gIFRoaXMgd2Fz IG9uZSBvZiB0aGUgImluc3RhLWRlYXRoIiBmYWN0b3JzIGZvciBVTUwuDQoNCkkgaGF2ZSB0byBy ZWl0ZXJhdGUgdGhhdCB0aGUgaWRlYSBpcyB0byBjb250aW51ZSB0byBiZSBhYmxlIHRvIHZpZXcg WUFORw0KbW9kdWxlcyAqd2l0aG91dCogdXNpbmcgdG9vbHMsIGJ1dCBwcm92aWRlIHNvbWUgYWlk IHRvIHRvb2xzIHRoYXQgY2FuIG1ha2UNCnVzZSBvZiBjZXJ0YWluIHdlbGwtZGVmaW5lZCBsaWdo dHdlaWdodCBtYXJrdXAgY29udmVudGlvbnMuDQoNCkV2ZXJ5Ym9keSB3aXRoIGEgcHJhY3RpY2Fs IGV4cGVyaWVuY2Ugb2YgY29udmVydGluZyBZQU5HIGF1dG9tYXRpY2FsbHkNCnRvIHNvbWV0aGlu ZyBlbHNlIChub3Qgb25seSB0byBIVE1MLCBpdCBzdGFydHMgYWxyZWFkeSB3aXRoIFlJTikga25v d3MNCnRoYXQgdHJhbnNmZXJyaW5nIGRlc2NyaXB0aW9ucyBhbmQgb3RoZXIgc2ltaWxhciB0ZXh0 cyBpcyB0cmlja3kuDQoNCkxhZGENCg0KPg0KPiBUaGFua3MsDQo+ICBQaGlsDQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWls aW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tIA0KTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0K UEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0K From nobody Wed Apr 19 15:32:46 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C6212025C for ; Wed, 19 Apr 2017 15:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoJu5ldyheoJ for ; Wed, 19 Apr 2017 15:32:42 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C957C129C1B for ; Wed, 19 Apr 2017 15:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QPf88j9WBFv6dd0ghEWT/F4XmdSLWq0RdV563YVJObg=; b=Ue9lYFzZ9qDIgIISaQmRyv+WKDrn9jvvFSDvI5SQjFdXik9jcAFAl61KpDRRPbsGOPwKtBTcp+XwbPJ2Kr1xbaEiewhkv/mxL7/J/H4zctx3G6tgwf0HReH149sj7IPW1AXPd/8l01RQxWIHkxLcwmEXcs7xeAJDry7EDB/nWw8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 22:32:41 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1047.006; Wed, 19 Apr 2017 22:32:41 +0000 From: Kent Watsen To: Martin Bjorklund , Lou Berger CC: "netmod@ietf.org" Thread-Topic: Regarding IPR on draft-bjorklund-netmod-yang-tree-diagrams Thread-Index: AQHSuVzbmenTRtYj2kWG+HpFp7WkIg== Date: Wed, 19 Apr 2017 22:32:41 +0000 Message-ID: <5C4A45DC-CB9A-4391-A9A2-30CE727B1DB6@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:4ni6KtbxUr4jyBWMtHqqmX1YDXiquki+18qiWMLpvfdYg3MAmtNizd/UdkXxywf7pX91njdpmS/vVekhfpg1lSv5UxQUqETCOSIucpUhmXrjCvhzFmUvyD7FmAj49BPOuBUJuDdrFCuqxJw6QXqu/leqImhhQdalRIPh2uYx/XEGUTYMj2ytLExIrJkaYmMzavieuw9XBZiakQ0ETE45yYIfuxTxXYmnnm2v7uw9E9XCSgPQuq8UqLbRZchtejK8KcOL2FZKHbF7d4ZaYGCQq2fI80tXV6OryOh4jdLELYdUQlIRM7gau0483pHYTTbiVV2dnFWHgzijNtnasbp/6Q== x-ms-office365-filtering-correlation-id: aaef44b0-883b-4ff6-53b2-08d48773fe0f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39450400003)(39850400002)(39840400002)(39860400002)(8676002)(3660700001)(102836003)(6116002)(8936002)(3280700002)(38730400002)(81166006)(54356999)(3846002)(230783001)(66066001)(5660300001)(53936002)(6506006)(77096006)(305945005)(6512007)(6436002)(189998001)(6306002)(86362001)(50986999)(966004)(99286003)(33656002)(4001350100001)(7736002)(2900100001)(2906002)(36756003)(4326008)(25786009)(83506001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <15CE366875F3D646ABF3E2292064B036@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 22:32:41.7397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: [netmod] Regarding IPR on draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 22:32:45 -0000 QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiBwcmVwYXJhdGlvbiBmb3Ig V0cgQWRvcHRpb24gb2Y6IA0KICBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXlhbmctdHJlZS1kaWFn cmFtcw0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlk ZW50aWZpZWQgYWJvdmU/DQoNCg0KUGxlYXNlIHN0YXRlIGVpdGhlcjoNCiAgICAiTm8sIEknbSBu b3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3INCiAg ICAiWWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQoN CklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoN CiAgICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGgg SUVURiBJUFIgcnVsZXMiDQogIG9yDQogICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNj bG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFs IGRldGFpbHMgeW91IHRoaW5rDQphcHByb3ByaWF0ZS4NCg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciwgcGxlYXNlIGFuc3dlciB0aGUNCmFi b3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Ig bm90IHlvdSBhcmUNCmF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2ls bCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVl biByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiBOT1RF OiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MNClRP IExJTkVTLg0KDQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdH IG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZA0KYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlDQpJRVRGIElQUiBy dWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBh d2FyZQ0Kb2YgSVBSIG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm cmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcNCmluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lv biByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3INCm1vcmUgaW5mb3JtYXRpb24s IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZA0KaHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRo YW5rIHlvdSwNCk5FVE1PRCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3Rl ZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0KDQoN Cg0K From nobody Wed Apr 19 23:49:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA1B127ABE for ; Wed, 19 Apr 2017 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzsZwR7S_YHL for ; Wed, 19 Apr 2017 23:49:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67F2F1200C1 for ; Wed, 19 Apr 2017 23:49:22 -0700 (PDT) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F3701AE028E; Thu, 20 Apr 2017 08:49:21 +0200 (CEST) Date: Thu, 20 Apr 2017 08:49:32 +0200 (CEST) Message-Id: <20170420.084932.85187681596576701.mbj@tail-f.com> To: kwatsen@juniper.net Cc: lberger@labn.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <5C4A45DC-CB9A-4391-A9A2-30CE727B1DB6@juniper.net> References: <5C4A45DC-CB9A-4391-A9A2-30CE727B1DB6@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Regarding IPR on draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 06:49:24 -0000 Kent Watsen wrote: > Authors, Contributors, WG, > > As part of preparation for WG Adoption of: > draft-bjorklund-netmod-yang-tree-diagrams > > Are you aware of any IPR that applies to draft identified above? No, I'm not aware of any IPR that applies to this draft /martin > > > Please state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > > If you are listed as a document author or contributor, please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under the > IETF IPR rules which encourages you to notify the IETF if you are aware > of IPR of others on an IETF contribution, or to refrain from participating > in any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your response. > > > > From nobody Thu Apr 20 03:36:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01915124C27 for ; Thu, 20 Apr 2017 03:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TB4plyrmCGs for ; Thu, 20 Apr 2017 03:36:18 -0700 (PDT) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 412B31293D6 for ; Thu, 20 Apr 2017 03:36:18 -0700 (PDT) Received: from cmgw2 (cmgw3 [10.0.90.83]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id E860A175A2E for ; Thu, 20 Apr 2017 04:36:16 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id AacD1v0052SSUrH01acG8l; Thu, 20 Apr 2017 04:36:16 -0600 X-Authority-Analysis: v=2.2 cv=Ibz3YSia c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=AzvcPWV-tVgA:10 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=DyV4sogk8Mt7S7QuqkQA:9 a=CjuIK1q_8ugA:10 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Q0qtHiHtO5+u85RACZQlHFqDUDk2qMI/wqTKFdIDz88=; b=Q4xMM8B/MQXSTlg8H3Rp5fAJde ccEPmqIaxsqPjENjtwzBjk2VBah9LW3KSrwUmLQwe7XQXCkcw0gUPnjRYvg76POf5s5KjL6bCjKlk 8qtFMN8kD4n4H3sZLUa6wYWbE; Received: from [100.44.229.224] (port=41227) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d19Rc-0004po-Pi; Thu, 20 Apr 2017 04:36:12 -0600 From: Lou Berger To: Kent Watsen , Martin Bjorklund CC: Date: Thu, 20 Apr 2017 06:36:11 -0400 Message-ID: <15b8aeefd90.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <5C4A45DC-CB9A-4391-A9A2-30CE727B1DB6@juniper.net> References: <5C4A45DC-CB9A-4391-A9A2-30CE727B1DB6@juniper.net> User-Agent: AquaMail/1.8.2-216 (build: 100800200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.44.229.224 X-Exim-ID: 1d19Rc-0004po-Pi X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([100.44.229.224]) [100.44.229.224]:41227 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [netmod] Regarding IPR on draft-bjorklund-netmod-yang-tree-diagrams X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 10:36:20 -0000 No, I'm not aware of any IPR that applies to this draft. Lou On April 19, 2017 6:33:14 PM Kent Watsen wrote: > Authors, Contributors, WG, > > As part of preparation for WG Adoption of: > draft-bjorklund-netmod-yang-tree-diagrams > > Are you aware of any IPR that applies to draft identified above? > > > Please state either: > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > > If you are listed as a document author or contributor, please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under the > IETF IPR rules which encourages you to notify the IETF if you are aware > of IPR of others on an IETF contribution, or to refrain from participating > in any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > NETMOD WG Chairs > > PS Please include all listed in the headers of this message in your response. > > > > From nobody Thu Apr 20 05:28:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADEE12940B; Thu, 20 Apr 2017 05:28:12 -0700 (PDT) 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] 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 kbgvhn5QsZj3; Thu, 20 Apr 2017 05:28:10 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 467021294DA; Thu, 20 Apr 2017 05:28:09 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 83ECB1820043; Thu, 20 Apr 2017 14:28:48 +0200 (CEST) From: Ladislav Lhotka To: Kent Watsen , Phil Shafer , Andy Bierman Cc: NetMod WG Chairs , NETMOD WG In-Reply-To: References: <201704181720.v3IHKCJ7045659@idle.juniper.net> Date: Thu, 20 Apr 2017 14:28:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 12:28:12 -0000 Kent Watsen writes: > All, > > We're a couple days away from the 2-week window. As of now, the > majority does not support adopting this draft. Any remaining > opinions? > > > Lada, > > The objections seem to be concern for net readability, and for the > importance of the problem relative to other activities. For the > former case, it may help if you posted some examples. For the A typical lightweight markup language is markdown, and I believe most people are familiar with it - if not, examples are easy to find. The bare minimum of markdown features from which even existing modules could benefit may be this: - multiple paragraphs (separated by one or more blank lines) that can be re-flowed - bulleted and numbered lists, possibly with multiple levels and multiple paragraphs per list item - hyperlinks, such as [RFC 7950](https://tools.ietf.org/html/rfc7950) and perhaps also - *emphasis* and **strong emphasis** - code blocks for showing example snippets where line breaks need to be retained. > latter case, we may want to keep this draft cooking in the > background. I am going to use the above conventions in my modules, and support them in my tools. That's basically all what I need for the time being. Lada > > > Kent // as co-chair and potential shepherd > > > > Phil Shafer writes: > >> Andy Bierman writes: >>>IMO it is more robust not to assume people never see the real YANG >>>statements. >> >> Exactly. We made YANG readable so that we wouldn't _need_ to view >> it using tools. This was one of the "insta-death" factors for UML. > > I have to reiterate that the idea is to continue to be able to view YANG > modules *without* using tools, but provide some aid to tools that can make > use of certain well-defined lightweight markup conventions. > > Everybody with a practical experience of converting YANG automatically > to something else (not only to HTML, it starts already with YIN) knows > that transferring descriptions and other similar texts is tricky. > > Lada > >> >> Thanks, >> Phil >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Apr 20 06:37:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65988131461 for ; Thu, 20 Apr 2017 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5Q9fAnrCWAl for ; Thu, 20 Apr 2017 06:37:21 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D170A13145E for ; Thu, 20 Apr 2017 06:37:20 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id j9so38434489ywj.3 for ; Thu, 20 Apr 2017 06:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YCJgvLc4bhRtTeex+j6a66RoYFKaOQBdhH5XOYnIxs4=; b=E/LJrYyp4Tzc3mAUoirqZznzdUvleZdbCJ5mKKf2twuTjbHeGpgcNtxLFlTBdvvi3R kv9pBCSwhiOI4AuYC1zOPWzu8ehrEQde2TNiib0jKNUtLT00+lVyf9zuND+JtTbs9jrd /ztDVlrTFfhxLGNVl70MHqtEMZReKkhjqV0YaSL/G+JPGjZ+Xd7VLvfTJh0P/Uz3koX5 Qo6Rx8RQGILqYPwgz460DYsGwlrcGGYg1jAbDoXlQ853VqHZLueMNuczr8VP1fM4ZLXK vxEgkpeJe9SKHwLC3yYZVZVF/lfMgPXGinjCreaeVBKAsZOegXjVmSoB3cyOFLnDkCVS 7YFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YCJgvLc4bhRtTeex+j6a66RoYFKaOQBdhH5XOYnIxs4=; b=iuQmzpHK36PxkGiE+Z+HZuS9OcA2ftynap6W3TJHbDgr70RU/AL/UuPxZHMU6C4CNP +7CHPHKXLVBI3df27Y/2572AIhvFuOVoyw8rlwt5zdxQ4qBjEcrIZcwCyjsOqwzfCsFT KvPW1OJfxwau7RFMY6WWvb5cvVCJMbEJZBrdC/rTeXWshpWDIMI2zzff5tzJ2cNIGfe9 kPVB83h10otnL7qajVL65uwn40QwLqXPp6E0Cu5O1Crq/ZNaZn/K2ua0BJyuK0y9XU67 5eHrdYijVaa8c5dUhjQmtNg0j7ig0PZu+gBRtQQgUsjnEGt1HFLBFiAQj4Ql/rvqIHNh 6yGA== X-Gm-Message-State: AN3rC/5ggKLTkmaLuR3EtrUCkUVT/Gs42Ccva1JpeD8Qlc6fw2WCiP51 sfOL8X61pTufIZMCRrgAXfG78l0+DTULS6o= X-Received: by 10.13.247.134 with SMTP id h128mr7677645ywf.136.1492695439888; Thu, 20 Apr 2017 06:37:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.202.72 with HTTP; Thu, 20 Apr 2017 06:36:59 -0700 (PDT) From: Dhirendra Trivedi Date: Thu, 20 Apr 2017 19:06:59 +0530 Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08265673d99b054d993dd5 Archived-At: Subject: [netmod] Query on Announcing Conformance Information in the Message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 13:37:29 -0000 --94eb2c08265673d99b054d993dd5 Content-Type: text/plain; charset=UTF-8 Hi All, We had requirement of implementing ietf-netconf-monitoring YANG model and we did it but partially. Now we need to advertise the deviation module in the netconf server capability. I tried doing it like urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=ietf-netconf-monitoring&deviations=jnx-ietf-netocnf-monitoring-dev but it seems OpenDaylight controller is not taking it as valid capability. Not sure if the capability is syntactically incorrect or OpenDaylight controller is having bug. Is there way to validate the syntax of above capability? Regards, Dhirendra --94eb2c08265673d99b054d993dd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi All,<= /span>

=C2=A0

We had requirement of implementing ietf-netconf-monitoring YANG model

and we did it but par= tially. Now we need to advertise the deviation module

in the netconf server capability.

I tried doing it like=

<capability>

=C2=A0=C2=A0=C2=A0=C2= =A0 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=3Dietf-netco= nf-monitoring&amp;deviations=3Djnx-ietf-netocnf-monitoring-dev

</capability>

=C2=A0

but it seems OpenDayl= ight controller is not taking it as valid capability. Not sure

if the capability is = syntactically incorrect or OpenDaylight controller is having bug.

=C2=A0

Is there way to valid= ate the syntax of above capability?

=C2=A0

Regards,=

Dhirendra





--94eb2c08265673d99b054d993dd5-- From nobody Thu Apr 20 09:26:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15FB129ADA for ; Thu, 20 Apr 2017 09:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN67hGKrHsYg for ; Thu, 20 Apr 2017 09:26:01 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0129.outbound.protection.outlook.com [104.47.33.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B808E129AA1 for ; Thu, 20 Apr 2017 09:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3cf3qqzXkAFSP7qRi0GnBUUnHfzLTYgXLeHIdXfWQeo=; b=jN5gRnuec1w80SclDWU0oPWBwrFRFJbf6xO6/PY/wlyEyWy+6XPLk2Ja2WY7B1tQLag9p5FnoNY9nWPBJ5HaToeD452TITs5zgFLJpKT2C/wmDm5D2n+RNoU5ADBi6dYDJcEcRY3wWfy93vl2RdE6ume1+2NBTy9hc4+qygJ5vE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 16:26:00 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1047.006; Thu, 20 Apr 2017 16:26:00 +0000 From: Kent Watsen To: Dhirendra Trivedi , "netmod@ietf.org" Thread-Topic: [netmod] Query on Announcing Conformance Information in the Message Thread-Index: AQHSudtEYqwyD/LlkU+fOO+Ssy4doaHOLtAA Date: Thu, 20 Apr 2017 16:26:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:WDf5X6Ol+WLNXezEutVCioU6ta+qWKZU2oyoIsfXPHuMoyClIWB/SasHzeMDFMR2OZlLpNxtf0os1pNdmRTm1cjCoNC2zcdJlJnP9Ew9F6W/w4ZsgAjKExiA2eDbhq21TErJnRhqT6w5sLdxXU40SE1wVLhtcbNLSrFBjsKY70qwDGqthIxtbs6z98Yl6uNAZF0f3A25TvkkkV9mhKBEKvw/EhQJ1EgeHyA+nQxJsJCSkLOuPo4stAlI/vf0mjss0HaVEzbl/XkyutKXeP3xIxhNMAsQvFHBG2XjY4w8VtoBQGnYx1mbnr+HGiurS2zRoLfqew5mq2k8LGXUmxfHTw== x-ms-office365-filtering-correlation-id: 5af3dd75-37c1-4255-3884-08d48809eec2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR0501MB1442; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02830F0362 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39850400002)(39860400002)(39840400002)(39450400003)(39400400002)(377454003)(24454002)(189002)(199003)(53754006)(122556002)(25786009)(7736002)(53936002)(2420400007)(54896002)(77096006)(6306002)(99286003)(3280700002)(6486002)(15650500001)(2900100001)(3660700001)(2950100002)(229853002)(6506006)(6436002)(39060400002)(38730400002)(83506001)(82746002)(83716003)(3846002)(6512007)(6116002)(236005)(102836003)(66066001)(4001350100001)(5660300001)(86362001)(36756003)(8936002)(7110500001)(189998001)(6246003)(2501003)(2906002)(33656002)(10710500007)(8676002)(76176999)(50986999)(81166006)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A3ECEF2D843145F9BA2CF45F5282BDE3junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2017 16:26:00.5679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] Query on Announcing Conformance Information in the Message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:26:04 -0000 --_000_A3ECEF2D843145F9BA2CF45F5282BDE3junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlcmUgYSB0eXBvIGluIHlvdXIgY2FwYWJpbGl0eSBsaW5lPyAgcy9uZXRvY25mL25ldGNv bmYvDQpJcyB5b3VyIHNlcnZlciBhbHNvIGFkdmVydGlzaW5nIGpueC1pZXRmLW5ldG9jbmYtbW9u aXRvcmluZy1kZXYgaW4gaXRzIGhlbGxvIG1lc3NhZ2U/DQoNCkJUVywgYmUgYXdhcmUgdGhhdCBz ZXJ2ZXJzIHN1cHBvcnRpbmcgUkZDNzk1MCBubyBsb25nZXIgaGF2ZSAiZGV2aWF0aW9ucz0iIGlu IHRoZQ0KY2FwYWJpbGl0eSBzdHJpbmcsIGFzIHRoZSBzZXJ2ZXIgaXMgbm93IGV4cGVjdGVkIHRv IHVzZSBZQU5HIExpYnJhcnkgdG8gYW5ub3VuY2UNCmNvbmZvcm1hbmNlLg0KDQpLLg0KDQoNCk9u IDQvMjAvMTcsIDk6MzYgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIERoaXJlbmRyYSBUcml2ZWRp IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgZGhpcnV0cml2ZWRpQGdtYWlsLmNvbTxtYWlsdG86ZGhpcnV0cml2ZWRp QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBBbGwsDQoNCldlIGhhZCByZXF1aXJlbWVudCBvZiBp bXBsZW1lbnRpbmcgaWV0Zi1uZXRjb25mLW1vbml0b3JpbmcgWUFORyBtb2RlbA0KYW5kIHdlIGRp ZCBpdCBidXQgcGFydGlhbGx5LiBOb3cgd2UgbmVlZCB0byBhZHZlcnRpc2UgdGhlIGRldmlhdGlv biBtb2R1bGUNCmluIHRoZSBuZXRjb25mIHNlcnZlciBjYXBhYmlsaXR5Lg0KSSB0cmllZCBkb2lu ZyBpdCBsaWtlDQo8Y2FwYWJpbGl0eT4NCiAgICAgdXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5n OmlldGYtbmV0Y29uZi1tb25pdG9yaW5nP21vZHVsZT1pZXRmLW5ldGNvbmYtbW9uaXRvcmluZyZh bXA7ZGV2aWF0aW9ucz1qbngtaWV0Zi1uZXRvY25mLW1vbml0b3JpbmctZGV2DQo8L2NhcGFiaWxp dHk+DQoNCmJ1dCBpdCBzZWVtcyBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBpcyBub3QgdGFraW5n IGl0IGFzIHZhbGlkIGNhcGFiaWxpdHkuIE5vdCBzdXJlDQppZiB0aGUgY2FwYWJpbGl0eSBpcyBz eW50YWN0aWNhbGx5IGluY29ycmVjdCBvciBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBpcyBoYXZp bmcgYnVnLg0KDQpJcyB0aGVyZSB3YXkgdG8gdmFsaWRhdGUgdGhlIHN5bnRheCBvZiBhYm92ZSBj YXBhYmlsaXR5Pw0KDQpSZWdhcmRzLA0KRGhpcmVuZHJhDQoNCg0KDQoNCg== --_000_A3ECEF2D843145F9BA2CF45F5282BDE3junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPklzIHRoZXJl IGEgdHlwbyBpbiB5b3VyIGNhcGFiaWxpdHkgbGluZT8mbmJzcDsgcy9uZXRvY25mL25ldGNvbmYv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmkiPklzIHlvdXIgc2VydmVyIGFsc28gYWR2ZXJ0aXNpbmcgam54 LWlldGYtbmV0b2NuZi1tb25pdG9yaW5nLWRldiBpbiBpdHMgaGVsbG8gbWVzc2FnZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkJUVywgYmUgYXdhcmUg dGhhdCBzZXJ2ZXJzIHN1cHBvcnRpbmcgUkZDNzk1MCBubyBsb25nZXIgaGF2ZSAmcXVvdDtkZXZp YXRpb25zPSZxdW90OyBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Y2FwYWJpbGl0eSBzdHJp bmcsIGFzIHRoZSBzZXJ2ZXIgaXMgbm93IGV4cGVjdGVkIHRvIHVzZSBZQU5HIExpYnJhcnkgdG8g YW5ub3VuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Y29uZm9ybWFuY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA0LzIwLzE3LCA5OjM2IEFN LCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmIG9mIERoaXJlbmRyYSBUcml2ZWRpJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGll dGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpkaGlydXRyaXZlZGlAZ21h aWwuY29tIj5kaGlydXRyaXZlZGlAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SGkgQWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIGhhZCByZXF1aXJlbWVudCBvZiBpbXBsZW1lbnRp bmcgaWV0Zi1uZXRjb25mLW1vbml0b3JpbmcgWUFORyBtb2RlbDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PmFuZCB3ZSBkaWQgaXQgYnV0IHBhcnRpYWxseS4gTm93IHdlIG5lZWQgdG8gYWR2ZXJ0aXNlIHRo ZSBkZXZpYXRpb24gbW9kdWxlDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5pbiB0aGUgbmV0Y29uZiBz ZXJ2ZXIgY2FwYWJpbGl0eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHRyaWVkIGRvaW5nIGl0IGxp a2UNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZsdDtjYXBhYmlsaXR5Jmd0Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlh bmc6aWV0Zi1uZXRjb25mLW1vbml0b3Jpbmc/bW9kdWxlPWlldGYtbmV0Y29uZi1tb25pdG9yaW5n JmFtcDthbXA7ZGV2aWF0aW9ucz1qbngtaWV0Zi1uZXRvY25mLW1vbml0b3JpbmctZGV2PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Jmx0Oy9jYXBhYmlsaXR5Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmJ1dCBpdCBzZWVtcyBPcGVuRGF5bGlnaHQgY29udHJv bGxlciBpcyBub3QgdGFraW5nIGl0IGFzIHZhbGlkIGNhcGFiaWxpdHkuIE5vdCBzdXJlDQo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5pZiB0aGUgY2FwYWJpbGl0eSBpcyBzeW50YWN0aWNhbGx5IGluY29y cmVjdCBvciBPcGVuRGF5bGlnaHQgY29udHJvbGxlciBpcyBoYXZpbmcgYnVnLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIHRoZXJlIHdheSB0byB2YWxp ZGF0ZSB0aGUgc3ludGF4IG9mIGFib3ZlIGNhcGFiaWxpdHk/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5E aGlyZW5kcmE8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_A3ECEF2D843145F9BA2CF45F5282BDE3junipernet_-- From nobody Thu Apr 20 09:35:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0EF129AFF for ; Thu, 20 Apr 2017 09:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFKSC_GV3NaD for ; Thu, 20 Apr 2017 09:35:13 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D269129436 for ; Thu, 20 Apr 2017 09:35:13 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id o81so108177195wmb.1 for ; Thu, 20 Apr 2017 09:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LtmnbhkZSSVDuI+TZXNUBCiGPf3b2zd3N1+hD6eDyVc=; b=dKY+YMOIDo9CIfRNBOsq9IgTHLsREhpTRw/K6dw6vDpWBltJ2Znm8Az/09uNqOBShE AcLXfa7GdS20pDONQf+TTEzu1WzYM2QwgyaajmipUnks1JUtK0HBHRKjGPA0+1wzn92z 4MgxVajae42aMs3Gw3xa4x3MUaOxzCy3R8A8bbt2luc/rjr4nrFZpIG0gQrLZNsB5zkK 1xNb4Bi90r/aVDzxaJZNs33yF1pw1pAGPIKqDEtBRx3XltZxnOG4FlFgxR4CnBHzjzXU S4emAI6QxVaPKQgyaMsl+ZqniFU3gAI/BxXq+9HsOJ7MVy9fVIuvD0Pn9iDnWeizI8cB WXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LtmnbhkZSSVDuI+TZXNUBCiGPf3b2zd3N1+hD6eDyVc=; b=lvesiigIExjY7Mt62V0d9teP13B3I2IXjhTvvdM+bxowTt8bo2+Jmd9wTryhm2DtUz rtBQNuLCsWC5tN9e15kL9g0zq+5Iouotwgnv1f8B8wu479cjblt5jL2IRxL2j76jffad NrKraZ1xW4f2xQD13x9ViwEIbPJd1HdQdi3XEVn8/itBAQxXiwOFZvhkPt7ElIt8zcRK ypicpdZLhW5202LtljXeXafmtUmVZslz0ArlJZKBs6ikB0nsNgysWL8yloAai4Thnvuy Z61el5SGy6bQbF6bACcOTJEzS7BbCexnkdSTJ3sFS32eJszvS4YQr7m6RF/iA+OrkrRs F+QQ== X-Gm-Message-State: AN3rC/7yGuJsZ2XF+NkWTPJXwlXfphnmZ1c6ixRIJKG+OJdn940afeBc v4QzqveG1TLj3OZXim+lXIp7X386eg== X-Received: by 10.28.232.220 with SMTP id f89mr3776221wmi.99.1492706112120; Thu, 20 Apr 2017 09:35:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Thu, 20 Apr 2017 09:35:11 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Thu, 20 Apr 2017 09:35:11 -0700 Message-ID: To: Dhirendra Trivedi Cc: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a1147833e913fa3054d9bb936 Archived-At: Subject: Re: [netmod] Query on Announcing Conformance Information in the Message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:35:15 -0000 --001a1147833e913fa3054d9bb936 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 20, 2017 at 6:36 AM, Dhirendra Trivedi wrote: > Hi All, > > > > We had requirement of implementing ietf-netconf-monitoring YANG model > > and we did it but partially. Now we need to advertise the deviation module > > in the netconf server capability. > > I tried doing it like > > > > urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring? > module=ietf-netconf-monitoring&deviations=jnx- > ietf-netocnf-monitoring-dev > > > > > > but it seems OpenDaylight controller is not taking it as valid capability. > Not sure > > if the capability is syntactically incorrect or OpenDaylight controller is > having bug. > > > > Is there way to validate the syntax of above capability? > > > Yes -- it looks correct. The structure is defined in RFC 6020: https://tools.ietf.org/html/rfc6020#section-5.6.4 Regards, > > Dhirendra > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a1147833e913fa3054d9bb936 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 20, 2017 at 6:36 AM, Dhirendra Trivedi &l= t;dhirutrivedi@= gmail.com> wrote:

Hi All,<= /span>

=C2=A0

We had requirement of implementing ietf-netconf-monitoring YANG model

and we did it but par= tially. Now we need to advertise the deviation module

in the netconf server capability.

I tried doing it like=

<capability>

=C2=A0=C2=A0=C2=A0=C2= =A0 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module=3D= ietf-netconf-monitoring&amp;deviations=3Djnx-ietf-netocnf-mon= itoring-dev

</capability>

=C2=A0

but it seems OpenDayl= ight controller is not taking it as valid capability. Not sure

if the capability is = syntactically incorrect or OpenDaylight controller is having bug.

=C2=A0

Is there way to valid= ate the syntax of above capability?

=C2=A0


Yes -- it looks correct.
The structure is defined in RFC 6020:


Regards,=

Dhirendra




Andy
=C2=A0



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

--001a1147833e913fa3054d9bb936-- From nobody Thu Apr 20 09:42:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11308129B1A for ; Thu, 20 Apr 2017 09:42:22 -0700 (PDT) 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xrnfoLMFKvP for ; Thu, 20 Apr 2017 09:42:18 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD38131499 for ; Thu, 20 Apr 2017 09:42:18 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id o21so39424013wrb.2 for ; Thu, 20 Apr 2017 09:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gL7x4BBNHpfggT3+YLgeCOLPQ6xdU/3wcVu4aF6s3YQ=; b=CxgxqiZrtrKlEyNd3vsYj9S2xQsekm+nZQyCqZXdhKAp2Y44XlwmTDrQt0t2uPntcL jyD+4ALifD7TZJY/05Ay6wehVPcyTfXwRo16qgV4R5xbbpmSG3dcJwLmOUbti7F4ZSz5 sZ9Rd56LxGpPiZo9imN3OoJNHUmz734GAlqipU1gVcZVuezlzMtptKxLkCcSJOzqVcJs 6g4sIjEwYIz6HM6gdX/UDWmlwEAduD3M1zuR5078UCucBteXxE/tzNsxaUDMhxesdSAS 7EnddmIXtjfQXFECaOLYmd8tSqU/dRIAmf6BYQlAKKrj4IMJr4Mrn6GfALKC6uY3L/3d nv/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gL7x4BBNHpfggT3+YLgeCOLPQ6xdU/3wcVu4aF6s3YQ=; b=naPrGjGrdMw3fsSgVJvxmiQ0VxA8K15lWiSdWBcC9OKiyPGQrdFtmJqoUKcvdauhhZ gWURgSb8UHlUoWEkn27jhDzs7gwfZA/7nZ7CkLbtjkqaQBBlZ3/i0X1u+heo8c2k12w4 2nwYD0cn7fHqkcd+hSKZAeN/npJgV0GqbLFx1V1qpGsantP4CmbquhANIGfS1LoCYZMK V/xzO828+xdpP7IbJyVf5f3dWxnNqlvOIbm9lsPjR9fwZQXsd7r+OJuS+YomlLT9PBHh ukZY373W8bxJuZlZ7to93/ancg8gIbhJyurojfdWY8mGKncidF1UYRatxdO03+NHPX9H mImA== X-Gm-Message-State: AN3rC/6PWPuPdru+YjpK26ZI7F6kXw7CbXfyCoVic5mnjHddkg47ziXY XjiQ4uhCD5JZB9aHbJfjzoqsZx7Q+A== X-Received: by 10.223.148.7 with SMTP id 7mr8461997wrq.65.1492706536871; Thu, 20 Apr 2017 09:42:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Thu, 20 Apr 2017 09:42:16 -0700 (PDT) In-Reply-To: References: From: Andy Bierman Date: Thu, 20 Apr 2017 09:42:16 -0700 Message-ID: To: Kent Watsen Cc: Dhirendra Trivedi , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0d2286e28a9c054d9bd24f Archived-At: Subject: Re: [netmod] Query on Announcing Conformance Information in the Message X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:42:22 -0000 --94eb2c0d2286e28a9c054d9bd24f Content-Type: text/plain; charset=UTF-8 On Thu, Apr 20, 2017 at 9:26 AM, Kent Watsen wrote: > Is there a typo in your capability line? s/netocnf/netconf/ > > Is your server also advertising jnx-ietf-netocnf-monitoring-dev in its > hello message? > > > > BTW, be aware that servers supporting RFC7950 no longer have "deviations=" > in the > > capability string, as the server is now expected to use YANG Library to > announce > > conformance. > > > Not quite. YANG 1.0 modules are still advertised according to RFC 6020. YANG 1.1 module capability URIs are left out of the . We ignore that rule and put them in the server because most client tools don't follow the RFC 7950 rules correctly. In our client, if the server advertises "module-set-id" then we read the /modules-state subtree (unless our cached data matches the module-set-id). We read /netconf-state/schemas if needed as well. > K. > > > Andy > > > On 4/20/17, 9:36 AM, "netmod on behalf of Dhirendra Trivedi" < > netmod-bounces@ietf.org on behalf of dhirutrivedi@gmail.com> wrote: > > > > Hi All, > > > > We had requirement of implementing ietf-netconf-monitoring YANG model > > and we did it but partially. Now we need to advertise the deviation module > > in the netconf server capability. > > I tried doing it like > > > > urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring? > module=ietf-netconf-monitoring&deviations=jnx- > ietf-netocnf-monitoring-dev > > > > > > but it seems OpenDaylight controller is not taking it as valid capability. > Not sure > > if the capability is syntactically incorrect or OpenDaylight controller is > having bug. > > > > Is there way to validate the syntax of above capability? > > > > Regards, > > Dhirendra > > > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --94eb2c0d2286e28a9c054d9bd24f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 20, 2017 at 9:26 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Is there a typo = in your capability line?=C2=A0 s/netocnf/netconf/

Is your server a= lso advertising jnx-ietf-netocnf-monitoring-dev in its hello message?<= u>

=C2=A0=

BTW, be aware th= at servers supporting RFC7950 no longer have "deviations=3D" in t= he

capability strin= g, as the server is now expected to use YANG Library to announce<= /u>

conformance.<= /u>

=C2=A0


Not quite.
Y= ANG 1.0 modules are still advertised according to RFC 6020.
YANG = 1.1 module capability URIs are left out of the <hello>.
We ignore that rule and put them in the server <hello> be= cause most client tools don't follow
the RFC 7950 rules corre= ctly. In our client, if the server advertises "module-set-id"
then we read the /modules-state subtree (unless our cached data matc= hes the module-set-id).
We read /netconf-state/schemas if needed = as well.




<= div>
=C2=A0

K.=

=C2=A0


Andy
=C2=A0<= /div>

=C2=A0=

=C2=A0

Hi All,

=C2=A0

We had requirement = of implementing ietf-netconf-monitoring YANG model

and we did it but p= artially. Now we need to advertise the deviation module

in the netconf serv= er capability.

I tried doing it li= ke

<capability><= /span>

=C2=A0=C2=A0=C2=A0= =C2=A0 urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring?module= =3Dietf-netconf-monitoring&amp;deviations=3Djnx-ietf-netocnf-= monitoring-dev

</capability>=

=C2=A0

but it seems OpenDa= ylight controller is not taking it as valid capability. Not sure

if the capability i= s syntactically incorrect or OpenDaylight controller is having bug.<= u>

=C2=A0

Is there way to val= idate the syntax of above capability?

=C2=A0

Regards,<= /u>

Dhirendra=

=C2=A0

=C2=A0

=C2=A0

=C2=A0


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

--94eb2c0d2286e28a9c054d9bd24f-- From nobody Thu Apr 20 18:16:32 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFA9128D69 for ; Thu, 20 Apr 2017 18:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Af6mC5n0ZmP for ; Thu, 20 Apr 2017 18:16:29 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B07B12EAB1 for ; Thu, 20 Apr 2017 18:16:29 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id o22so105075330iod.3 for ; Thu, 20 Apr 2017 18:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gKDSD4QiE84DW1etjmFtjyMGeXPEaTf8vx2iSu0qI2Q=; b=TElpUSNkdW8P794FgF5QP5mwTJDcBAwxDbC9MDpGiN/PkOjyVc+rY2QdPwyNTKF2nb gUkLMcPCPPIRDH7vl+AHhkXcnjQzZh8EEgEsQR+mrvCzN/fMaf1YQgZkGWGd+79buUeM ZycsWvoXBqnfzuTRbHd1r9YqfacNpG1WTpPj52VPfG07plXSWUpYEkHiIgUQm9a+7ox9 UJqFTTqOES1RkU3LLzq4y23iY4DezOXuPAu0ReYZk4R/lRWHs6Wt1MYA56Oa0pDU79+T 65/XVVlfa1V8bsCMuPXzm2phVIIRsRqqdTZ95ixdBmCTYSAPnznKw/PnLUYCp4ks1Mzs Se7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gKDSD4QiE84DW1etjmFtjyMGeXPEaTf8vx2iSu0qI2Q=; b=PgN9NaEH+c9wD4D8hLO36XEka73M5iZoQ0dS7T3RNWPkzkhm3O47mf2jdw4PECIdZk JfolP3ovPi+bGI5vqkVNFn9NEwZgIRsCg3M/64/l8wQJnBvZwliAtM1AdNYpmb7k6Vz3 VFk/AprQle6ZzHuBWelBS7KWmW8+uCy6fSnleiv45WMqJhPAo/klLpHZZatGKRZsf3qD C5ioOzDvQBWoc2y0veGuHgalPKJu3+9CzuytoREQPGLh+xOgNs1T/4AcVTE6VennfUhs emcDSqaETKpaPCisRDgxs9P07kn8uxPF52jiMhQ/rYNBs7jDqSKG4tUeoZDgjJxZbWfs u0rw== X-Gm-Message-State: AN3rC/5zoShtSsr/qq8mWGv5e2is4c5m3aMtFOFk/6ffEhmocoEdLRux 6k3c8uPXXPpS7w== X-Received: by 10.99.3.8 with SMTP id 8mr9977198pgd.208.1492737388512; Thu, 20 Apr 2017 18:16:28 -0700 (PDT) Received: from ?IPv6:2001:420:30d:1254:8538:d76a:a2a9:9201? ([2001:420:30d:1254:8538:d76a:a2a9:9201]) by smtp.gmail.com with ESMTPSA id t3sm12465064pfi.127.2017.04.20.18.16.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Apr 2017 18:16:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_101A0416-0840-4A34-8B72-B5DBE0A990DA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <5C204D53-ECE0-4632-A34A-9BE96B913BD0@juniper.net> Date: Thu, 20 Apr 2017 18:16:25 -0700 Cc: "netmod@ietf.org" , Glenn Parsons , Norman Finn , Marc Holness , Dan Romascanu , Brian Weis Message-Id: <73E4F65E-C265-47C5-A32A-3C6688459A7C@gmail.com> References: <148939875845.17039.4017763838166134753.idtracker@ietfa.amsl.com> <4D50BFD4-0E59-4DF8-BEC9-0D9BE50F5BA6@juniper.net> <86AA35DF-0D22-45E7-A954-E766133ED49D@juniper.net> <5C204D53-ECE0-4632-A34A-9BE96B913BD0@juniper.net> To: Kent Watsen , David Bannister X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] New Version Notification for draft-ietf-netmod-acl-model-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 01:16:31 -0000 --Apple-Mail=_101A0416-0840-4A34-8B72-B5DBE0A990DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 7, 2017, at 4:33 PM, Kent Watsen wrote: >=20 > On 3/28/17, 2:59 PM, "David Bannister" > wrote: > =20 > I would agree that the mix of L2 and L3 in the same operational ACL is = a bit out of the ordinary. I could see where a combined approach may be = appealing to some. As a network operator I do not see this as a = negative. It would be nice to give the vendor the option to defer the = L2/3 combination but it does not look attainable in the current model. I would agree with this assertion. A proposal in the works uses feature = statements to let vendors decide which part of the model they want to = support. > =20 > "augmented by each vendor" There are many things missing in IETF = models and some things which are not under the IETF umbrella. In this = discussion the first that comes to mind is an 802.x model. It is good = to see there is currently an IEEE effort to develop one. However, it = does not exist today. The various ether types are covered in some of = the vendor models I have seen. We take the Newco example in the draft = which typedefs an enum of 'known-ether-type.' Meanwhile Oldco is using = a typedef of 'ethertype.' Both New and Old co both augment this draft. = In this scenario the network operator is stuck sorting out the logic in = which vendor model to use and having to deal with two data structures = for the same entity (ether-type). Using models this way does nothing = to simplify network coding and management. I am against augmentation = from vendor models for common items but it is ok for vendor unique = items. Ether-type is not vendor unique. Augmentation has its place but = it appears to be overused even within the context of IETF only models. I would agree. Ideally, IEEE should take up definition of ether-types = that are registered with them and define a ieee-ether-types.yang file. = Adding a few folks from IEEE that I know who could look at this. > =20 > Not sure if pointing out ietf-routing was a good idea. Five years in = the making and 42 augmenting models. :-) > =20 > If we can get the well known IETF standardized missing bits from L3, = L4 for v4 and v6 into this it would work for me but I think the IETF may = have missed the boat on this one. > =20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_101A0416-0840-4A34-8B72-B5DBE0A990DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 7, 2017, at 4:33 PM, Kent Watsen <kwatsen@juniper.net>= wrote:

On 3/28/17, 2:59 PM, "David Bannister" <dpb@netflix.com> wrote:
 
I would agree that the mix = of L2 and L3 in the same operational ACL is a bit out of the = ordinary.  I could see where a combined approach may be appealing = to some.  As a network operator I do not see this as a = negative.  It would be nice to give the vendor the option to defer = the L2/3 combination but it does not look attainable in the current = model.

I would = agree with this assertion. A proposal in the works uses feature = statements to let vendors decide which part of the model they want to = support.

 
"augmented by each vendor"  There are many = things missing in IETF models and some things which are not under the = IETF umbrella.  In this discussion the first that comes to mind is = an 802.x model.  It is good to see there is currently an IEEE = effort to develop one.  However, it does not exist today.  The = various ether types are covered in some of the vendor models I have = seen.  We take the Newco example in the draft which typedefs an = enum of 'known-ether-type.'  Meanwhile Oldco is using a typedef of = 'ethertype.'  Both New and Old co both augment this draft. In this = scenario the network operator is stuck sorting out the logic in which = vendor model to use and having to deal with two data structures for the = same entity (ether-type).   Using models this way does nothing to = simplify network coding and management.  I am against augmentation = from vendor models for common items but it is ok for vendor unique = items.  Ether-type is not vendor unique.  Augmentation has its = place but it appears to be overused even within the context of IETF only = models.

I = would agree. Ideally, IEEE should take up definition of ether-types that = are registered with them and define a ieee-ether-types.yang file. Adding = a few folks from IEEE that I know who could look at this.

 
Not sure if pointing out ietf-routing was a good idea. Five = years in the making and 42 augmenting models. :-)
 
If we can get the well known IETF standardized = missing bits from L3, L4 for v4 and v6 into this it would work for me = but I think the IETF may have missed the boat on this one.
 

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_101A0416-0840-4A34-8B72-B5DBE0A990DA-- From nobody Fri Apr 21 04:14:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E348129C71; Fri, 21 Apr 2017 04:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hansfords.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VvCCBN2VF80; Fri, 21 Apr 2017 04:14:49 -0700 (PDT) Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 C423F129C51; Fri, 21 Apr 2017 04:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:MIME-Version:Subject:References: In-Reply-To:Message-ID:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m66P82nOodKIb6ZmNS0fDE/E9x7yESqdc5OEh4IAPcA=; b=c50Gv8cS0TuRvjhDvYXx2ZxRJ Hcjn2xd9HlNX+Hlgzd4eHoG9zlF2tzUq1J+HGjrrYPZ35bB0en2UCDxYDXsqKSncZbISEiqG7xYis xIG1hLYMKll+DHbGbLX2+WBMyoKWdrwAacdURUjAWQlunO795zzmgDW8nw6QL/IzWm2th6w8TBXYN WUqUCVRYmq2sRcvthzAPnvZ/Mz89qhRXA7UU/mXpUAUlivu7n5pqTsw9SKYUWoDhgn1O+yozhOLpD uZKsKYxLGFi5tkyduryMD+zaHJSPQlvut3mAo9V+TRXEQWgDHKGi+vfSVrtvnbfNk3uMKjz+nC+uF jvT8sI0PQ==; Received: from [84.92.116.209] (port=51038 helo=[192.168.1.24]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1d1WWT-000A4B-QZ; Fri, 21 Apr 2017 12:14:45 +0100 Date: Fri, 21 Apr 2017 12:14:33 +0100 From: Jonathan Hansford To: Ladislav Lhotka , Phil Shafer , Andy Bierman , Kent Watsen Cc: NetMod WG Chairs , NETMOD WG Message-ID: <55a8f526-c507-4a26-9dff-ef9f06837445@Spark> In-Reply-To: References: <201704181720.v3IHKCJ7045659@idle.juniper.net> X-Readdle-Message-ID: 55a8f526-c507-4a26-9dff-ef9f06837445@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="58f9e9a5_327b23c6_d3" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.myfast.site X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hansfords.net X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 11:14:52 -0000 --58f9e9a5_327b23c6_d3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline I understand the primary need is to make the YANG modules accessible to readers, but some simple markup is identical to how text might be formatted when only raw ASCII is available (e.g. when using a simple email client) yet, when rendered as markup, the resulting text is easier on the eyes of the reader. I agree that some examples may better sell the idea. Also, if some YANG authors are already including markup, wouldn't it be better to standardise rather than allow for a free-for-all resulting in multiple styles that would impose a significant burden on any tool trying to render the text. Jonathan =O) On 19 Apr 2017, 22:05 +0100, Kent Watsen , wrote: > > All, > > We're a couple days away from the 2-week window. As of now, the > majority does not support adopting this draft. Any remaining > opinions? > > > Lada, > > The objections seem to be concern for net readability, and for the > importance of the problem relative to other activities. For the > former case, it may help if you posted some examples. For the > latter case, we may want to keep this draft cooking in the > background. > > > Kent // as co-chair and potential shepherd > > > > Phil Shafer writes: > > > Andy Bierman writes: > > > IMO it is more robust not to assume people never see the real YANG > > > statements. > > > > Exactly. We made YANG readable so that we wouldn't _need_ to view > > it using tools. This was one of the "insta-death" factors for UML. > > I have to reiterate that the idea is to continue to be able to view YANG > modules *without* using tools, but provide some aid to tools that can make > use of certain well-defined lightweight markup conventions. > > Everybody with a practical experience of converting YANG automatically > to something else (not only to HTML, it starts already with YIN) knows > that transferring descriptions and other similar texts is tricky. > > Lada > > > > > Thanks, > > Phil > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --58f9e9a5_327b23c6_d3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I understand the primary need is to = make the YANG modules accessible to readers, but some simple markup is id= entical to how text might be formatted when only raw ASCII is available (= e.g. when using a simple email client) yet, when rendered as markup, the = resulting text is easier on the eyes of the reader.

I agree that some examples may better sell the idea.

Also, if some YANG authors are already including markup, wouldn't it be b= etter to standardise rather than allow for a free-for-all resulting in mu= ltiple styles that would impose a significant burden on any tool trying t= o render the text.

Jonathan

=3DO)


On 19 Apr 2017, 22:05 +0100, Kent Watsen <kwatsen=40juniper.net>, w= rote:

All,

We're a couple days away from the 2-week window. As of now, the
majority does not support adopting this draft. Any remaining
opinions=3F


Lada,

The objections seem to be concern for net readability, and for the
importance of the problem relative to other activities. =46or the
former case, it may help if you posted some examples. =46or the
latter case, we may want to keep this draft cooking in the
background.


Kent // as co-chair and potential shepherd



Phil Shafer <phil=40juniper.net> writes:

Andy Bierman writes:
IMO it is more robust not to assume people = never see the real YANG
statements.

Exactly. We made YANG readable so that we wouldn't =5Fneed=5F to view
it using tools. This was one of the =22insta-death=22 factors for UML.

I have to reiterate that the idea is to continue to be able to view YANG<= br /> modules *without* using tools, but provide some aid to tools that can mak= e
use of certain well-defined lightweight markup conventions.

Everybody with a practical experience of converting YANG automatically to something else (not only to HTML, it starts already with YIN) knows that transferring descriptions and other similar texts is tricky.

Lada


Thanks,
Phil

=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
netmod mailing list
netmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8=4692B08A9=4676C67

=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
netmod mailing list
netmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod


=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
netmod mailing list
netmod=40ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--58f9e9a5_327b23c6_d3-- From nobody Fri Apr 21 05:53:47 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F83129478; Fri, 21 Apr 2017 05:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 AmlBq3MBmnDh; Fri, 21 Apr 2017 05:53:43 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E05129466; Fri, 21 Apr 2017 05:53:43 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:dd5:f7a0:97cf:1a50] (unknown [IPv6:2001:718:1a02:1:dd5:f7a0:97cf:1a50]) by mail.nic.cz (Postfix) with ESMTPSA id 0B8616013F; Fri, 21 Apr 2017 14:53:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492779222; bh=ALAkQGxTDTfys59ALC/pjR7QRpHi+1nsWrtDzU3NE9M=; h=From:Date:To; b=sC5oXPSNMT0P/qgvfVeOkWvC82+BUzZyxJxvnLevym0lhjZM42FI3WzFQmniE+We9 0ekWJ6mNS6vwn0Hy7XPESBPA9FnR0aRXyq2EFAuxdHepjvEeVzqCZdwQnsoAswTvO5 HJhmQkotQKXSWkXXZOQyngrzgZNVpP3yvva+rRSE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: <55a8f526-c507-4a26-9dff-ef9f06837445@Spark> Date: Fri, 21 Apr 2017 14:53:41 +0200 Cc: Phil Shafer , Andy Bierman , Kent Watsen , NetMod WG Chairs , NETMOD WG Content-Transfer-Encoding: quoted-printable Message-Id: <344A858F-77CF-4302-9E8C-A450B9A04571@nic.cz> References: <201704181720.v3IHKCJ7045659@idle.juniper.net> <55a8f526-c507-4a26-9dff-ef9f06837445@Spark> To: Jonathan Hansford X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:53:46 -0000 > On 21 Apr 2017, at 13:14, Jonathan Hansford = wrote: >=20 > I understand the primary need is to make the YANG modules accessible = to readers, but some simple markup is identical to how text might be = formatted when only raw ASCII is available (e.g. when using a simple = email client) yet, when rendered as markup, the resulting text is easier = on the eyes of the reader. Right, the key term really is "lightweight markup" [1]: "A lightweight markup language (LML), also termed a simple or humane = markup language, is a markup language with simple, unobtrusive syntax. = It is designed to be easy to create using any generic text editor, as = well as easy to read in its raw form. Lightweight markup languages are = used in applications where it may be necessary to read the raw document = as well as the final rendered output." Many tools might at least want to be able to reliably re-flow paragraphs = and lists to fit a desired text width, or render some constructs as = HTML. >=20 > I agree that some examples may better sell the idea. Some examples are in the "ietf-yang-text-media-type" module: https://tools.ietf.org/html/draft-lhotka-netmod-yang-markup-00#section-4 >=20 > Also, if some YANG authors are already including markup, wouldn't it = be better to standardise rather than allow for a free-for-all resulting = in multiple styles that would impose a significant burden on any tool = trying to render the text. My idea has been that 6087bis could recommend to use a (subset of) = specific LML, e.g. markdown or its variant, in IETF modules and indicate = it in them with the "text-media-type" extension. The advantage of doing = so is that it will be easier to use something else later and/or combine = IETF modules with others that may use something else. For instance, if = somebody wanted YANG-specific markup (similar to what is used in TR-069 = schemas, e.g. [2]), reStructuredText might be a better choice than = markdown. Lada [1] https://en.wikipedia.org/wiki/Lightweight_markup_language [2] https://www.broadband-forum.org/cwmp/tr-181-2-11-0.xml >=20 > Jonathan >=20 > =3DO) >=20 >=20 > On 19 Apr 2017, 22:05 +0100, Kent Watsen , wrote: >>=20 >> All, >>=20 >> We're a couple days away from the 2-week window. As of now, the >> majority does not support adopting this draft. Any remaining >> opinions? >>=20 >>=20 >> Lada, >>=20 >> The objections seem to be concern for net readability, and for the >> importance of the problem relative to other activities. For the >> former case, it may help if you posted some examples. For the >> latter case, we may want to keep this draft cooking in the >> background. >>=20 >>=20 >> Kent // as co-chair and potential shepherd >>=20 >>=20 >>=20 >> Phil Shafer writes: >>=20 >>> Andy Bierman writes: >>>> IMO it is more robust not to assume people never see the real YANG >>>> statements. >>>=20 >>> Exactly. We made YANG readable so that we wouldn't _need_ to view >>> it using tools. This was one of the "insta-death" factors for UML. >>=20 >> I have to reiterate that the idea is to continue to be able to view = YANG >> modules *without* using tools, but provide some aid to tools that can = make >> use of certain well-defined lightweight markup conventions. >>=20 >> Everybody with a practical experience of converting YANG = automatically >> to something else (not only to HTML, it starts already with YIN) = knows >> that transferring descriptions and other similar texts is tricky. >>=20 >> Lada >>=20 >>>=20 >>> Thanks, >>> Phil >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 21 06:03:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C112762F; Fri, 21 Apr 2017 06:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5Hesp04fStH7; Fri, 21 Apr 2017 06:03:52 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0330F124234; Fri, 21 Apr 2017 06:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3239; q=dns/txt; s=iport; t=1492779832; x=1493989432; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=G93yui+kSoUaQJdBvkRKKFe8fktvuImVy+DgMpWWPCo=; b=j5FU5YXlQeRQcRq7kzDHEE9I82Qrlgj3AXMENc5NK1KTKgZsZg+uFHy0 oIyEQbT1J9Wso9rjeF9poWAhTDtsW9S9+VXIeQ9jA5ptvlhfr4MWKo5J0 wH2+3NiYDvXQAZvrS6HInezp+8ehx4iOy53gEG2Fw962b8RX+f1dtzXYO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AADVAvpY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDWBDI18c5B2lWSCDyELhS5KAoRIGAECAQEBAQEBAWsohRUBAQE?= =?us-ascii?q?BAgEBATY2CxALGC4nMAYKAwYCAQGKEAgOq22LIAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFhlOCCIJugTyJAAWdOYcVi2+Kc4Zii3iIHh84gQYmHQgYFUSEaQwQgWQ?= =?us-ascii?q?/NYkuAQEB?= X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="693875703" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 13:03:50 +0000 Received: from [10.63.23.150] (dhcp-ensft1-uk-vla370-10-63-23-150.cisco.com [10.63.23.150]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3LD3nJ6004352; Fri, 21 Apr 2017 13:03:49 GMT To: Ladislav Lhotka References: <201704181720.v3IHKCJ7045659@idle.juniper.net> Cc: Kent Watsen , Phil Shafer , Andy Bierman , NetMod WG Chairs , NETMOD WG From: Robert Wilton Message-ID: Date: Fri, 21 Apr 2017 14:03:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:03:54 -0000 Hi Lada, On 20/04/2017 13:28, Ladislav Lhotka wrote: > Kent Watsen writes: > >> All, >> >> We're a couple days away from the 2-week window. As of now, the >> majority does not support adopting this draft. Any remaining >> opinions? >> >> >> Lada, >> >> The objections seem to be concern for net readability, and for the >> importance of the problem relative to other activities. For the >> former case, it may help if you posted some examples. For the > A typical lightweight markup language is markdown, and I believe most > people are familiar with it - if not, examples are easy to find. > > The bare minimum of markdown features from which even existing modules > could benefit may be this: > > - multiple paragraphs (separated by one or more blank lines) that can be > re-flowed > > - bulleted and numbered lists, possibly with multiple levels and > multiple paragraphs per list item > > - hyperlinks, such as [RFC 7950](https://tools.ietf.org/html/rfc7950) > > and perhaps also > > - *emphasis* and **strong emphasis** > > - code blocks for showing example snippets where line breaks need to be retained. For what it is worth, this is effective what I was recommending goes in the draft. I.e. you say that default markdown language is markdown, but implementations are expected to at least support xxx, where xxx is something like that list above. That way at least implementors can know what they need to support, and authors can know what markdown they can reasonably expect to use. > >> latter case, we may want to keep this draft cooking in the >> background. > I am going to use the above conventions in my modules, and support them > in my tools. That's basically all what I need for the time being. If you have the spare time, perhaps it is worth updating the ID with that list above, at least as a record in case this gets picked up again in future. Thanks, Rob > > Lada > >> >> Kent // as co-chair and potential shepherd >> >> >> >> Phil Shafer writes: >> >>> Andy Bierman writes: >>>> IMO it is more robust not to assume people never see the real YANG >>>> statements. >>> Exactly. We made YANG readable so that we wouldn't _need_ to view >>> it using tools. This was one of the "insta-death" factors for UML. >> I have to reiterate that the idea is to continue to be able to view YANG >> modules *without* using tools, but provide some aid to tools that can make >> use of certain well-defined lightweight markup conventions. >> >> Everybody with a practical experience of converting YANG automatically >> to something else (not only to HTML, it starts already with YIN) knows >> that transferring descriptions and other similar texts is tricky. >> >> Lada >> >>> Thanks, >>> Phil >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> From nobody Fri Apr 21 06:19:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474B1127866; Fri, 21 Apr 2017 06:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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=nic.cz 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 csPhrVcMBDCQ; Fri, 21 Apr 2017 06:19:53 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F54312762F; Fri, 21 Apr 2017 06:19:52 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:dd5:f7a0:97cf:1a50] (unknown [IPv6:2001:718:1a02:1:dd5:f7a0:97cf:1a50]) by mail.nic.cz (Postfix) with ESMTPSA id 9BC7C60187; Fri, 21 Apr 2017 15:19:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492780790; bh=8rJpOPrAvjo/vij4Vzut9F8d1ibwVdTt9mug3Fb3piQ=; h=From:Date:To; b=Frn1pLsgGhxBDy0H0yKd7yw8RjCYOXJHUryD6rj+0ssOHO9dxGhKACBPjMhbdIyXH i6NaSSojYcL35m1hiMzJ9KULCsUMxG+0UvStwg/HSWAQfqZD4VLT+vhG2geJOg2buY p2hsdGM07HfrRnnXqYdHEZmRQ2/GPjhwo+VQ47i0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 21 Apr 2017 15:19:50 +0200 Cc: Kent Watsen , Phil Shafer , Andy Bierman , NetMod WG Chairs , NETMOD WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <201704181720.v3IHKCJ7045659@idle.juniper.net> To: Robert Wilton X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:19:55 -0000 > On 21 Apr 2017, at 15:03, Robert Wilton wrote: >=20 > Hi Lada, >=20 >=20 > On 20/04/2017 13:28, Ladislav Lhotka wrote: >> Kent Watsen writes: >>=20 >>> All, >>>=20 >>> We're a couple days away from the 2-week window. As of now, the >>> majority does not support adopting this draft. Any remaining >>> opinions? >>>=20 >>>=20 >>> Lada, >>>=20 >>> The objections seem to be concern for net readability, and for the >>> importance of the problem relative to other activities. For the >>> former case, it may help if you posted some examples. For the >> A typical lightweight markup language is markdown, and I believe most >> people are familiar with it - if not, examples are easy to find. >>=20 >> The bare minimum of markdown features from which even existing = modules >> could benefit may be this: >>=20 >> - multiple paragraphs (separated by one or more blank lines) that can = be >> re-flowed >>=20 >> - bulleted and numbered lists, possibly with multiple levels and >> multiple paragraphs per list item >>=20 >> - hyperlinks, such as [RFC 7950](https://tools.ietf.org/html/rfc7950) >>=20 >> and perhaps also >>=20 >> - *emphasis* and **strong emphasis** >>=20 >> - code blocks for showing example snippets where line breaks need to = be retained. > For what it is worth, this is effective what I was recommending goes = in the draft. >=20 > I.e. you say that default markdown language is markdown, but = implementations are expected to at least support xxx, where xxx is = something like that list above. >=20 > That way at least implementors can know what they need to support, and = authors can know what markdown they can reasonably expect to use. Yes, this is the essential minimum that would immediately help = implementors of some tools and that also means no extra burden to module = authors and readers. >=20 >>=20 >>> latter case, we may want to keep this draft cooking in the >>> background. >> I am going to use the above conventions in my modules, and support = them >> in my tools. That's basically all what I need for the time being. > If you have the spare time, perhaps it is worth updating the ID with = that list above, at least as a record in case this gets picked up again = in future. OK, I will do that. Thanks, Lada >=20 > Thanks, > Rob >=20 >>=20 >> Lada >>=20 >>>=20 >>> Kent // as co-chair and potential shepherd >>>=20 >>>=20 >>>=20 >>> Phil Shafer writes: >>>=20 >>>> Andy Bierman writes: >>>>> IMO it is more robust not to assume people never see the real YANG >>>>> statements. >>>> Exactly. We made YANG readable so that we wouldn't _need_ to view >>>> it using tools. This was one of the "insta-death" factors for UML. >>> I have to reiterate that the idea is to continue to be able to view = YANG >>> modules *without* using tools, but provide some aid to tools that = can make >>> use of certain well-defined lightweight markup conventions. >>>=20 >>> Everybody with a practical experience of converting YANG = automatically >>> to something else (not only to HTML, it starts already with YIN) = knows >>> that transferring descriptions and other similar texts is tricky. >>>=20 >>> Lada >>>=20 >>>> Thanks, >>>> Phil >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> --=20 >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Apr 21 09:30:44 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CA129A92; Fri, 21 Apr 2017 09:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 unJaIZWSNY33; Fri, 21 Apr 2017 09:30:41 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6B8129B55; Fri, 21 Apr 2017 09:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10220; q=dns/txt; s=iport; t=1492792240; x=1494001840; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=0eNQ8WphOWCmD9v6QsNLhw1F1iYoviF+8QmQlrxuUlE=; b=J/lOIxqcyhhgGove0ukykEDjY7gW5fOx8m4pXKb2RFoSUnSxXe38tD98 5eeE5ygi6xNWRcEdYF0LVuvw/MTUxbfMfr8Qy95oKdLKHdHsnN3CuEb5D ClvB1tzCE25eP2SbeOHlH3+fXNw4L5wBEqEpivZgm5215jtaHH6DgkX+u 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAAD3MvpY/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgymBDIEMjXxzkHWQL4U1gg8hAQyFLEoChEoYAQIBAQEBAQEBayi?= =?us-ascii?q?FFgEBAQMBAWwbCw4EBi4nIg4GAQkDBgIBAReKAQ6reSuKdwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEaBYZTgV0rgm6KPAWdQYcXi2+CAIh1I4Y/i3iIIR84gQYmHQgYFUS?= =?us-ascii?q?EaRyBZT41iTYBAQE?= X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208,217";a="651316151" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 16:30:37 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3LGUaHk015264; Fri, 21 Apr 2017 16:30:36 GMT To: Alia Atlas , Kent Watsen , "netmod@ietf.org" , "sec-ads@ietf.org" References: <7de29e11-f045-b0a1-808f-38044f6f7352@cisco.com> <8E887FD1-9849-4A05-A43F-CF675056A7B5@juniper.net> <1fdc07f6-0434-a490-024d-af039877ae33@cisco.com> <20170316072757.GD59114@elstar.local> <0138111b-6c95-0edc-23c4-2797312bb51a@cisco.com> <20170316075657.GF59114@elstar.local> <7FB88E83-589D-4F3B-BC55-C7D0B2F858A8@juniper.net> <20170316135145.GB23450@elstar.local> <20170316143803.GB23686@elstar.local> <328c7b27-389a-3c58-4efd-dc5a86fedfbc@cisco.com> From: Benoit Claise Message-ID: <1a4c9e0b-b83c-6a32-d9c1-41e6718d6fb7@cisco.com> Date: Fri, 21 Apr 2017 18:30:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <328c7b27-389a-3c58-4efd-dc5a86fedfbc@cisco.com> Content-Type: multipart/alternative; boundary="------------C135394DC11A263613D89277" Archived-At: Subject: Re: [netmod] security considerations boilerplate updates to cover RESTCONF X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 16:30:43 -0000 This is a multi-part message in MIME format. --------------C135394DC11A263613D89277 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, The new YANG module security guidelines have been posted, in agreement with our SEC AD Kathleen. See https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Regards, Benoit > Dear all, > > As discussed during the IESG telechat today, we should only focus on > the addition of the RESTCONF bits, and not attempt to include the I2RS > future protocol now. > Hence this minimum change proposal: > > The YANG module defined in this document is designed to be > accessed via network management protocols such as NETCONF > [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the > secure transport layer, and the mandatory-to-implement secure > transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF > layer is HTTPS, and the mandatory-to-implement secure > transport is > TLS [RFC5246]. > > The NETCONF access control model [RFC6536] provides the means to > restrict access for particular NETCONF or RESTCONF users to a > pre-configured subset of all available NETCONF or RESTCONF > protocol operations and content. > > Regards, Benoit >> On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote: >>>> Keep in mind that I2RS believes in a requirement for cleartext >>>> transport protocols. Perhaps this never makes it through the IESG but >>>> so far it was not possible to stop this... >>>> >>> This is solely for notifications that can be sent, just as IPFIX >>> information may >>> be sent unencrypted. Those requirements are in >>> draft-ietf-i2rs-protocol-security-requirements-17 >>> , >>> which is in the RFC Editor queue. >>> >> The new features are priority, an opaque secondary identifier, and an >> insecure protocol for read-only data constrained to specific standard >> usages. >> >> The optional insecure transport can only be used >> restricted set of publically data available (events or information) >> or a select set of legacy data. Data passed over the insecure >> transport channel MUST NOT contain any data which identifies a >> person. >> >> I think your statement that it is only for notifications is wrong. >> The fact that some data ships in a notification does not mean the data >> is not sensitive. Furthermore, I think we all meanwhile know that >> IPFIX data is highly sensitive if you have the right context >> information (so the analogy is flawed). And what the heck is a 'select >> set of legacy data'? >> >> SEC-REQ-06: An I2RS agent receiving an I2RS message over an >> insecure transport MUST confirm that the content is suitable for >> transfer over such a transport. >> >> An agent can't decide this. It is the context information that often >> decides whether a piece of information is sensitive or not. So the >> only decision an agent can do is to only allow messages with empty >> content over an insecure transport. >> >> The I2RS architecture defines three scopes: read, write, and >> notification scope. Insecure data can only be used for read scope >> and notification scope of "non-confidential data". >> >> I understand that the IESG approved the security requirements. I do >> not know why the security ADs did let this pass - perhaps since the >> document is just about requirements and they will look closer at a >> solution and then ask questions what 'non-confidentail' data' is, what >> a 'select set of legacy data' is, or how an agent confirms that the >> content of messages is suitable for an insecure transport. >> >> Anyway, this does not belong here, the point I wanted to make is >> simply that Kent's assumption that a protocol transporting YANG >> defined data is always protecting the data is not true from the >> viewpoint of the I2RS proponents. Thanks for confirming this. >> >> /js >> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------C135394DC11A263613D89277 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear all,

The new YANG module security guidelines have been posted, in agreement with our SEC AD Kathleen.
See https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

Regards, Benoit
Dear all,

As discussed during the IESG telechat today, we should only focus on the addition of the RESTCONF bits, and not attempt to include the I2RS future protocol now.
Hence this minimum change proposal:
     The YANG module defined in this document is designed to be
     accessed via network management protocols such as NETCONF
     [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the
     secure transport layer, and the mandatory-to-implement secure
     transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF
     layer is HTTPS, and the mandatory-to-implement secure transport is
     TLS [RFC5246].

     The NETCONF access control model [RFC6536] provides the means to
     restrict access for particular NETCONF or RESTCONF users to a
     pre-configured subset of all available NETCONF or RESTCONF
     protocol operations and content.
Regards, Benoit
On Thu, Mar 16, 2017 at 10:13:18AM -0400, Alia Atlas wrote:

Keep in mind that I2RS believes in a requirement for cleartext
transport protocols. Perhaps this never makes it through the IESG but
so far it was not possible to stop this...


This is solely for notifications that can be sent, just as IPFIX
information may
be sent unencrypted.  Those requirements are in
draft-ietf-i2rs-protocol-security-requirements-17
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/>,
which is in the RFC Editor queue.


   The new features are priority, an opaque secondary identifier, and an
   insecure protocol for read-only data constrained to specific standard
   usages.

   The optional insecure transport can only be used
   restricted set of publically data available (events or information)
   or a select set of legacy data.  Data passed over the insecure
   transport channel MUST NOT contain any data which identifies a
   person.

I think your statement that it is only for notifications is wrong.
The fact that some data ships in a notification does not mean the data
is not sensitive. Furthermore, I think we all meanwhile know that
IPFIX data is highly sensitive if you have the right context
information (so the analogy is flawed). And what the heck is a 'select
set of legacy data'?

      SEC-REQ-06: An I2RS agent receiving an I2RS message over an
      insecure transport MUST confirm that the content is suitable for
      transfer over such a transport.

An agent can't decide this. It is the context information that often
decides whether a piece of information is sensitive or not. So the
only decision an agent can do is to only allow messages with empty
content over an insecure transport.

   The I2RS architecture defines three scopes: read, write, and
   notification scope.  Insecure data can only be used for read scope
   and notification scope of "non-confidential data".

I understand that the IESG approved the security requirements. I do
not know why the security ADs did let this pass - perhaps since the
document is just about requirements and they will look closer at a
solution and then ask questions what 'non-confidentail' data' is, what
a 'select set of legacy data' is, or how an agent confirms that the
content of messages is suitable for an insecure transport.

Anyway, this does not belong here, the point I wanted to make is
simply that Kent's assumption that a protocol transporting YANG
defined data is always protecting the data is not true from the
viewpoint of the I2RS proponents. Thanks for confirming this.

/js





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

--------------C135394DC11A263613D89277-- From nobody Fri Apr 21 10:17:33 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82B129AB5 for ; Fri, 21 Apr 2017 10:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZG3VoEmbEhh for ; Fri, 21 Apr 2017 10:17:29 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696E3129AB3 for ; Fri, 21 Apr 2017 10:17:29 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id w50so35275393wrc.0 for ; Fri, 21 Apr 2017 10:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f3VUu4rtg+3h0a7T1qe2b8YDqNQ6Kvdat+MM0+D0MHE=; b=FZJ6k19ad0Z8RAqa73H8zgPVzQfGtbvGRMLU8IEd4IZ3lsHqSPMtEawNWJLvrW6wzu PxIQDjqn5H/JLkbKmY0RXiKTEsz2dyfKEGz3F6yR9a+ybiQGT3WqIPbVl7vNS3yLK5bD RAty484U5w3VM18FihTMOwqrsB3agWVzDWOhEQjFKMttD7B0NPOWPkTLpgyVjqunJCSR VuD0S7WyCCxAGP4SEw/S01woVIVEfG6dWWj4lsputhM/SK2d6huTXkbeT2aqFEdXUJwB N8bBdtvDLu9TzbcklFGnHFS2HV11txQrnQYpevabaklqxNKrqVpJ0IvtPc2xhuZFo4O4 Favw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f3VUu4rtg+3h0a7T1qe2b8YDqNQ6Kvdat+MM0+D0MHE=; b=nQe0Yqbz0AKrL3pA6G/AJVtoHAK7ZLC4QTemmjm8Wi2Z54b8uPBVxphukMIsh0Dwov yLqwP9GHlaw/9m5wIJPOe38t7d9xi1JbGXMSoePZsv7e0lLeNNi5vB0wV7cKwwuP6H+e s3MwgKfbS+kD8C+42+DVgskcTPKtp/RHcZ4O8LbaRxZqdY1JSskBqSeKdT2sUKX8+CI7 jXmPvj/jGFx99SvreJGfPeof/7D/BaYNQbi0uY1QwV3YlkHdo5BqOHBaGjuLv+u3DUJt Nz2FSEHrxAxhKKDZF0/NBdB79mO1eOnOo6iheu5fNbtc1VnMSvWes/KGTOngv+1T1UC/ 6IUg== X-Gm-Message-State: AN3rC/7wFTqwLRO5Pe45/KbO90r9Lb+J7KVXnxvLOun9QsMJodQCzpnI 6ou8zhM509Ckx8lGZxHAMW3eWEukYg== X-Received: by 10.223.178.68 with SMTP id y4mr14839490wra.88.1492795047158; Fri, 21 Apr 2017 10:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Fri, 21 Apr 2017 10:17:26 -0700 (PDT) In-Reply-To: References: <201704181720.v3IHKCJ7045659@idle.juniper.net> From: Andy Bierman Date: Fri, 21 Apr 2017 10:17:26 -0700 Message-ID: To: Robert Wilton Cc: Ladislav Lhotka , Kent Watsen , Phil Shafer , NetMod WG Chairs , NETMOD WG Content-Type: multipart/alternative; boundary=f403045f1a468259ec054db06e16 Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:17:32 -0000 --f403045f1a468259ec054db06e16 Content-Type: text/plain; charset=UTF-8 Hi, You can put whatever text you want in a draft, and see it gets approved for the RFC version. You can put whatever text you want in non-IETF modules. But consider the impact carefully of turning a plain text string into source code. There is no agreement on the markdown that is "lightweight" and needs to be supported. This seems like a significant amount of work to resolve. The NETMOD WG already has a full plate of high-priority work. We should not slow that work down for anything. Tools that expect the description-stmt to be plain text may break if markdown is added. The ability to translate the description to other languages is lost (for example). Andy On Fri, Apr 21, 2017 at 6:03 AM, Robert Wilton wrote: > Hi Lada, > > > On 20/04/2017 13:28, Ladislav Lhotka wrote: > >> Kent Watsen writes: >> >> All, >>> >>> We're a couple days away from the 2-week window. As of now, the >>> majority does not support adopting this draft. Any remaining >>> opinions? >>> >>> >>> Lada, >>> >>> The objections seem to be concern for net readability, and for the >>> importance of the problem relative to other activities. For the >>> former case, it may help if you posted some examples. For the >>> >> A typical lightweight markup language is markdown, and I believe most >> people are familiar with it - if not, examples are easy to find. >> >> The bare minimum of markdown features from which even existing modules >> could benefit may be this: >> >> - multiple paragraphs (separated by one or more blank lines) that can be >> re-flowed >> >> - bulleted and numbered lists, possibly with multiple levels and >> multiple paragraphs per list item >> >> - hyperlinks, such as [RFC 7950](https://tools.ietf.org/html/rfc7950) >> >> and perhaps also >> >> - *emphasis* and **strong emphasis** >> >> - code blocks for showing example snippets where line breaks need to be >> retained. >> > For what it is worth, this is effective what I was recommending goes in > the draft. > > I.e. you say that default markdown language is markdown, but > implementations are expected to at least support xxx, where xxx is > something like that list above. > > That way at least implementors can know what they need to support, and > authors can know what markdown they can reasonably expect to use. > > >> latter case, we may want to keep this draft cooking in the >>> background. >>> >> I am going to use the above conventions in my modules, and support them >> in my tools. That's basically all what I need for the time being. >> > If you have the spare time, perhaps it is worth updating the ID with that > list above, at least as a record in case this gets picked up again in > future. > > Thanks, > Rob > > >> Lada >> >> >>> Kent // as co-chair and potential shepherd >>> >>> >>> >>> Phil Shafer writes: >>> >>> Andy Bierman writes: >>>> >>>>> IMO it is more robust not to assume people never see the real YANG >>>>> statements. >>>>> >>>> Exactly. We made YANG readable so that we wouldn't _need_ to view >>>> it using tools. This was one of the "insta-death" factors for UML. >>>> >>> I have to reiterate that the idea is to continue to be able to view YANG >>> modules *without* using tools, but provide some aid to tools that can >>> make >>> use of certain well-defined lightweight markup conventions. >>> >>> Everybody with a practical experience of converting YANG automatically >>> to something else (not only to HTML, it starts already with YIN) knows >>> that transferring descriptions and other similar texts is tricky. >>> >>> Lada >>> >>> Thanks, >>>> Phil >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >>> >>> > --f403045f1a468259ec054db06e16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

You can put whatever text you want = in a draft, and see it gets approved
for the RFC version. You can= put whatever text you want in non-IETF modules.
But consider the= impact carefully of turning a plain text string into source code.

There is no agreement on the markdown that is "lightw= eight" and needs to be supported.
This seems like a signific= ant amount of work to resolve.=C2=A0 The NETMOD WG already has a full plate=
of high-priority work.=C2=A0 We should not slow that work down f= or anything.

Tools that expect the description-stm= t to be plain text may break if markdown is added.
The ability to= translate the description to other languages is lost (for example).
<= div>

Andy


On Fri, Apr 21, 2017 at 6:0= 3 AM, Robert Wilton <rwilton@cisco.com> wrote:
Hi Lada,


On 20/04/2017 13:28, Ladislav Lhotka wrote:
Kent Watsen <kw= atsen@juniper.net> writes:

All,

We're a couple days away from the 2-week window.=C2=A0 As of now, the majority does not support adopting this draft.=C2=A0 Any remaining
opinions?


Lada,

The objections seem to be concern for net readability, and for the
importance of the problem relative to other activities.=C2=A0 For the
former case, it may help if you posted some examples.=C2=A0 For the
A typical lightweight markup language is markdown, and I believe most
people are familiar with it - if not, examples are easy to find.

The bare minimum of markdown features from which even existing modules
could benefit may be this:

- multiple paragraphs (separated by one or more blank lines) that can be =C2=A0 =C2=A0re-flowed

- bulleted and numbered lists, possibly with multiple levels and
=C2=A0 =C2=A0multiple paragraphs per list item

- hyperlinks, such as [RFC 7950](https://tools.ietf.org/html= /rfc7950)

and perhaps also

- *emphasis* and **strong emphasis**

- code blocks for showing example snippets where line breaks need to be ret= ained.
For what it is worth, this is effective what I was recommending goes in the= draft.

I.e. you say that default markdown language is markdown, but implementation= s are expected to at least support xxx, where xxx is something like that li= st above.

That way at least implementors can know what they need to support, and auth= ors can know what markdown they can reasonably expect to use.


latter case, we may want to keep this draft cooking in the
background.
I am going to use the above conventions in my modules, and support them
in my tools. That's basically all what I need for the time being.
If you have the spare time, perhaps it is worth updating the ID with that l= ist above, at least as a record in case this gets picked up again in future= .

Thanks,
Rob


Lada


Kent // as co-chair and potential shepherd



Phil Shafer <phil@= juniper.net> writes:

Andy Bierman writes:
IMO it is more robust not to assume people never see the real YANG
statements.
Exactly.=C2=A0 We made YANG readable so that we wouldn't _need_ to view=
it using tools.=C2=A0 This was one of the "insta-death" factors f= or UML.
I have to reiterate that the idea is to continue to be able to view YANG modules *without* using tools, but provide some aid to tools that can make<= br> use of certain well-defined lightweight markup conventions.

Everybody with a practical experience of converting YANG automatically
to something else (not only to HTML, it starts already with YIN) knows
that transferring descriptions and other similar texts is tricky.

Lada

Thanks,
=C2=A0 Phil

_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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



--f403045f1a468259ec054db06e16-- From nobody Fri Apr 21 23:55:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6418F1293E3; Fri, 21 Apr 2017 23:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 UDreAUtXVohH; Fri, 21 Apr 2017 23:55:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5805E128BB7; Fri, 21 Apr 2017 23:55:31 -0700 (PDT) Received: from [IPv6:2a01:5e0:29:ffff:493:7c90:3d9f:ff24] (unknown [IPv6:2a01:5e0:29:ffff:493:7c90:3d9f:ff24]) by mail.nic.cz (Postfix) with ESMTPSA id B192560168; Sat, 22 Apr 2017 08:55:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1492844129; bh=eKf1UZz6x+PBb1kTDc4lCv/+LX3ePb6B7Uakb3k2ISQ=; h=From:Date:To; b=nnKtKSMbqIYBHtp5oXLGtOssXzt9xNhCMvxvUa6Q/lRqLBBn0Uinibci9HeLaN5yu wtrWPx4ww/SvZIsxi/6fOAM8WjiSxQ26HoKpnI5rPXVfgY8Z9xkSAiJLqLrFo/iLxR ILN11dk6jG89gyrj2ehEbw227j5S4w0Iofa9AJyw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 22 Apr 2017 08:55:28 +0200 Cc: Robert Wilton , Kent Watsen , Phil Shafer , NetMod WG Chairs , NETMOD WG Content-Transfer-Encoding: quoted-printable Message-Id: <866BA920-25E1-4A05-8154-F898948F4105@nic.cz> References: <201704181720.v3IHKCJ7045659@idle.juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.3273) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] WG adoption poll draft-lhotka-netmod-yang-markup-00 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 06:55:33 -0000 > On 21 Apr 2017, at 19:17, Andy Bierman wrote: >=20 > Hi, >=20 > You can put whatever text you want in a draft, and see it gets = approved > for the RFC version. You can put whatever text you want in non-IETF = modules. > But consider the impact carefully of turning a plain text string into = source code. >=20 > There is no agreement on the markdown that is "lightweight" and needs = to be supported. By the same token, there is no agreement on what plain text is. = Moreover, descriptions in the existing modules do use some unwritten = formatting conventions and elementary markup (e.g. enclosing YANG names = in quotes or email addresses in chevrons). The main purpose of my I-D is = to help module authors adhere to certain *written* rules. > This seems like a significant amount of work to resolve. The NETMOD = WG already has a full plate > of high-priority work. We should not slow that work down for = anything. I've heard similar dismissive statements in the past against some of my = previous work, such as the JSON encoding. Fortunately, this is voluntary = work and I am just scratching my own itches. Ultimately, it is running = code that counts. >=20 > Tools that expect the description-stmt to be plain text may break if = markdown is added. How this could be if the strings follow YANG rules? My only explaination = is that such tools already rely on those unwritten rules. As Rob pointed = out, your tools also sometimes produce suboptimal results on = descriptions in existing YANG modules. > The ability to translate the description to other languages is lost = (for example). >=20 Why? Wikipedia articles use lightweight markup and they are being = routinely translated to many languages. With a decent markup, the = translation can actualy be easier and more robust: for example, the = translator can recognize YANG identifiers in the text and avoid = translating them. Lada >=20 > Andy >=20 >=20 > On Fri, Apr 21, 2017 at 6:03 AM, Robert Wilton = wrote: > Hi Lada, >=20 >=20 > On 20/04/2017 13:28, Ladislav Lhotka wrote: > Kent Watsen writes: >=20 > All, >=20 > We're a couple days away from the 2-week window. As of now, the > majority does not support adopting this draft. Any remaining > opinions? >=20 >=20 > Lada, >=20 > The objections seem to be concern for net readability, and for the > importance of the problem relative to other activities. For the > former case, it may help if you posted some examples. For the > A typical lightweight markup language is markdown, and I believe most > people are familiar with it - if not, examples are easy to find. >=20 > The bare minimum of markdown features from which even existing modules > could benefit may be this: >=20 > - multiple paragraphs (separated by one or more blank lines) that can = be > re-flowed >=20 > - bulleted and numbered lists, possibly with multiple levels and > multiple paragraphs per list item >=20 > - hyperlinks, such as [RFC 7950](https://tools.ietf.org/html/rfc7950) >=20 > and perhaps also >=20 > - *emphasis* and **strong emphasis** >=20 > - code blocks for showing example snippets where line breaks need to = be retained. > For what it is worth, this is effective what I was recommending goes = in the draft. >=20 > I.e. you say that default markdown language is markdown, but = implementations are expected to at least support xxx, where xxx is = something like that list above. >=20 > That way at least implementors can know what they need to support, and = authors can know what markdown they can reasonably expect to use. >=20 >=20 > latter case, we may want to keep this draft cooking in the > background. > I am going to use the above conventions in my modules, and support = them > in my tools. That's basically all what I need for the time being. > If you have the spare time, perhaps it is worth updating the ID with = that list above, at least as a record in case this gets picked up again = in future. >=20 > Thanks, > Rob >=20 >=20 > Lada >=20 >=20 > Kent // as co-chair and potential shepherd >=20 >=20 >=20 > Phil Shafer writes: >=20 > Andy Bierman writes: > IMO it is more robust not to assume people never see the real YANG > statements. > Exactly. We made YANG readable so that we wouldn't _need_ to view > it using tools. This was one of the "insta-death" factors for UML. > I have to reiterate that the idea is to continue to be able to view = YANG > modules *without* using tools, but provide some aid to tools that can = make > use of certain well-defined lightweight markup conventions. >=20 > Everybody with a practical experience of converting YANG automatically > to something else (not only to HTML, it starts already with YIN) knows > that transferring descriptions and other similar texts is tricky. >=20 > Lada >=20 > Thanks, > Phil >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --=20 > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Sun Apr 23 13:55:16 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69E31294E2 for ; Sun, 23 Apr 2017 13:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OByrymI0sDTI for ; Sun, 23 Apr 2017 13:55:13 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DE9127076 for ; Sun, 23 Apr 2017 13:55:13 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id m123so52555090wma.0 for ; Sun, 23 Apr 2017 13:55:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=45hUET9Qa9qyVf4ANTh2fLwVU14TbTisAeylFi023Aw=; b=QVKLMqI+Qp5y/0xfXz1LNqDCd/0NdUwSg1BJtYFji9jWTYGlOu3n6tAA9GaD7k2zdP RmRQx+NaTyMiu0KaVreLmoS37dzQRM7/Busx4+Ao0QfRSFUZ97zQWL8zFLgUwkmyGhuC H2kXrn7GJ20IlOMYhKKywj7Y/qRBmprHfZKHHAelQFTZEyPR00FBy6MOw+fsOb7zy+uP omFyql34b9nwtT4S4H6aGKnSGxy+PhIcIL7/NWYIQE+N/If3D9doflOc/0Q0A5H1ADLM nIquWhc91fqdqqR/6SfjBmvJd1/S4OHxsjitz6J5urDM39+QYeaiqi9HBtluQ+7l9uky ZDiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=45hUET9Qa9qyVf4ANTh2fLwVU14TbTisAeylFi023Aw=; b=k7ofYFRMCWv6C3tqGIRDhlX03VLLXLzy8eEbpNmWkAHlvhjtxD38Pm0sBx1FvYJ06V C+vksYFPo/y3GC+TvG4LJew0ncPAKq124Vm3TMdXmbk2Yw4+C+xBmF0EUblt0VdfnbsC 315TNxRVcwMDAIO4OlWM9d2oxSjygPYj8UlNRm4s8+1HZoSwKP4BYVOSrJHli3QQo0cY 4VbxuC7kUWKVVqU2OICw3p1zit5KRbp2NBXF3oP+2vRoCW766/puQ/nBMmNVwIfsNLUs UXSDeD/vdTICbSKitAyTl7Qge88+4++L8oppOj594j53T52A7BQ4H8KMLsSWu6It5ykw Vzzw== X-Gm-Message-State: AN3rC/6XNwSVHnM6bdpPxZyoEMlPdCdaU1f8hemaoAS/Wq05yX1+tC2e mKGRQDIsoMEQuS7ZZGyiODx5A8mPbzxd X-Received: by 10.28.133.70 with SMTP id h67mr6715686wmd.136.1492980911606; Sun, 23 Apr 2017 13:55:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.23 with HTTP; Sun, 23 Apr 2017 13:55:10 -0700 (PDT) From: Andy Bierman Date: Sun, 23 Apr 2017 13:55:10 -0700 Message-ID: To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a114431f8e4ab59054ddbb497 Archived-At: Subject: [netmod] comments on tree diagrams draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 20:55:16 -0000 --001a114431f8e4ab59054ddbb497 Content-Type: text/plain; charset=UTF-8 Hi, https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00 The introduction in this draft does not really reflect the goals that need to be addressed. Perhaps: sec 1, para 1: OLD: This document provides the syntax used in YANG Tree Diagrams. It is expected that this document will be updated or replaced as changes to the YANG language, see [RFC7950 ], necessitate. NEW: This document provides the syntax used in YANG Tree Diagrams for version 1.1 of the YANG data modeling language [RFC7950 ]. It is expected that this document will be updated or replaced for future versions of YANG. It should be possible for multiple independent tools to generate the same YANG tree diagrams, using this specification. Sec. 2: The vertical bar (|) and indentation is not defined. The tab alignment is not defined The general recursive algorithm is not defined. The mandatory vs. optional parts of the diagram are not defined. (e.g., groupings, notifications, rpcs) Examples of all field types should be provided (e.g if-features) An ABNF for the grammar should be provided. Andy --001a114431f8e4ab59054ddbb497 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


<= /div>

The introduction in this draft does not really ref= lect the goals that need to
be addressed. Perhaps:

=
sec 1, para 1:
OLD:
   This document
   provides the syntax used in YANG Tree Diagrams.  It is expected that
   this document will be updated or replaced as changes to the YANG
   language, see [RFC7950], necessitate.=

NEW:

   This document provides the syntax used in YANG Tree=
 Diagrams
   for version 1.1 of the =
YANG data modeling language [RFC7950].
   It is expected that this document will be updated or =
replaced
   for future versions of Y=
ANG. It should be possible for
   mu=
ltiple independent tools to generate the same YANG tree diagrams,
using this specification.

<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">Sec. 2:
The vertical bar (|) and indentation is not defined.
The tab alignment is not defined
The general recursive algorithm is not defined.
<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">The mandatory vs. optional parts of the di=
agram are not defined.
(e.g., groupi=
ngs, notifications, rpcs)
Examples o=
f all field types should be provided (e.g if-features)
An ABNF for the grammar should be provided.


=

Andy



--001a114431f8e4ab59054ddbb497--


From nobody Mon Apr 24 07:00:22 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E196126DEE; Mon, 24 Apr 2017 07:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level: 
X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 0t9KfbXY5W5a; Mon, 24 Apr 2017 07:00:11 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E2FA129461; Mon, 24 Apr 2017 07:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1950; q=dns/txt; s=iport; t=1493042411; x=1494252011; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=1g1cnLbZrT5ZcQbv780x/wi+0I4RSlXq+rB0mNYaR3I=; b=F+rQKAuXziEt4XYiIMpa5x25sjEjKMFO8fXtSoWCfjekR9propHFeubh ISWtHImuvTSrDcTcErehm0kNh8WtLu7/7z6hShtj6Uc0bhV5SS+4Y+5zL HwDPX2dDSALpsT8OM9972eSo9N6isoeFG7yDw4tGLqPGYh0RNAmgM6XHl c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAQBLBP5Y/xbLJq1bGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgymBDIRzihVzkFQhaJR9gg8shXgChEsYAQIBAQEBAQEBayiFFgEEASM?= =?us-ascii?q?VQRALDgwCJgICVwYBDAgBAYoQCA6rIoImixwBAQEBAQEBAQEBAQEBAQEBAQEBG?= =?us-ascii?q?gWBC4VIgggLgmOCPYFsEQGDIoJfAQSJOpQHhxeLb4IAhTODQiOGP4t4iCEfOH4?= =?us-ascii?q?IJh0IGBWHLj6HPYIuAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,244,1488844800"; d="scan'208";a="693939112"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2017 14:00:09 +0000
Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3OE08jY032227; Mon, 24 Apr 2017 14:00:08 GMT
To: Alia Atlas , The IESG 
References: <149206236459.15682.10714540431640759841.idtracker@ietfa.amsl.com>
Cc: netmod-chairs@ietf.org, netmod@ietf.org
From: Benoit Claise 
Message-ID: 
Date: Mon, 24 Apr 2017 16:00:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <149206236459.15682.10714540431640759841.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Alia Atlas' Yes on charter-ietf-netmod-08-05: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 14:00:13 -0000

Hi Alia,

Now that you are back from vacation...
> Alia Atlas has entered the following ballot position for
> charter-ietf-netmod-08-05: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-netmod/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I do think that it would be helpful for this charter to discuss some of
> the
> needed WG interactions.  In particular, where encodings of YANG are
> defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there should be
> coordination of the impact of changes to the YANG language.
We could debate whether draft-ietf-core-yang-cbor should have been in 
core or netmod.
I propose to treat this doc. as the exception, and to keep the guideline 
that mappings should be done in NETMOD.

>   
>
> Another question is where do you see the discussion of device profiles
> or sets of YANG modules needed to meet a particular purpose going? To
> me, this doesn't read as in scope for this charter and yet I don't think
> that
> we've thought through the right place for them.  I'm ok with continued
> discussion for routing-related ones in RTGWG - but not all device
> profiles
> (i.e. a profile of modules needed for a firewall) belong anywhere near
> Routing.
Good point for the profiles.
For the top of the rack switch profile, RTGWG is the best place.
I propose to add a sentence that will leave the door open for NETMOD
The NETMOD WG may include work on YANG modules device profiles that do 
not otherwise fall under the charter of any other IETF working group.

Regards, Benoit


From nobody Mon Apr 24 07:19:20 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D55129496; Mon, 24 Apr 2017 07:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp2p4iVmWl0W; Mon, 24 Apr 2017 07:19:10 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E248D1294CD; Mon, 24 Apr 2017 07:19:09 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id w50so69294290wrc.0; Mon, 24 Apr 2017 07:19:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jc6EgXDwr+ZEkgPveuI8Ysc+lFI3JfzjwGPEyGKsRa4=; b=g1HLUD9NTiIvB+ZAz9AYD+esUZ00VAu5ypuBH6JtYRXtRGVzvMobMaNBv/CYJGPA2T pNAzDBjLCRK6DWORcOPe/yzhPm6GqcI5C5kdslDXe0izZNTyNQUHFKbyOKpT7utSphIr BgCCxJuc2PWbL0osx3P5g0EhfbOyDxquP4jA4dqDZb+LZgruZ/Y6OHjRCy65GFIS6aPf LpDvYJi9Dj3qZGWYZ4wiLtgwKM7z4+Ze9rCTO+rbgu+ztVncsdz3C/CXvM9UNPF/ryQj 8RI/oW1OSa2KXmPVJXr1Twf7x62Nm5p8DYosJH6A0Ztj/L8vJdnMdRIbnmyVyEKZxLpG bw7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jc6EgXDwr+ZEkgPveuI8Ysc+lFI3JfzjwGPEyGKsRa4=; b=bsx0gH0TQxdbCuTZYHjMRKcIEyYM746Z4IFryd1hh4c7YMiT5SMIRjewnrtFkxusgX o71V9oVMeDbM1BzdSCmYwNrf6LgwhIl2JWlDcQQdAnt+mu6ZY1+sy8iNvIO4oWKDTEOH VblqInU/b6GMgoAn93IEOycgfhYCUrxbKSaQ4RwoMwk357eZM95KmweugM9LSPPQjerC GeszZrHd5BBKbQd48M9BqE76Jh1f2UISso8m4iZH/Ig6mRJBGUhNnSHxMxgZiTO9tRr8 uuxkpJ8vo5FQSD/ZOnWKPLB7De0bQN/AZeCCbRUJw0RmbJqBg2WSx7jWvnuoEH7pwb8D LSjQ==
X-Gm-Message-State: AN3rC/7z/lbpgYc02FeerFbwlyBalw8YeD1LhZYolIuzHOyKxXUhEaM9 SGVDQ+R/7Rqb6GsWqHdO73XLkCgOeA==
X-Received: by 10.223.170.194 with SMTP id i2mr6198558wrc.44.1493043548110; Mon, 24 Apr 2017 07:19:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.135.120 with HTTP; Mon, 24 Apr 2017 07:19:07 -0700 (PDT)
In-Reply-To: 
References: <149206236459.15682.10714540431640759841.idtracker@ietfa.amsl.com> 
From: Alia Atlas 
Date: Mon, 24 Apr 2017 10:19:07 -0400
Message-ID: 
To: Benoit Claise 
Cc: The IESG , netmod-chairs@ietf.org,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c1cb82451c343054dea4a3c
Archived-At: 
Subject: Re: [netmod] Alia Atlas' Yes on charter-ietf-netmod-08-05: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 14:19:12 -0000

--94eb2c1cb82451c343054dea4a3c
Content-Type: text/plain; charset=UTF-8

Hi Benoit,

On Mon, Apr 24, 2017 at 10:00 AM, Benoit Claise  wrote:

> Hi Alia,
>
> Now that you are back from vacation...
>
>> Alia Atlas has entered the following ballot position for
>> charter-ietf-netmod-08-05: Yes
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/charter-ietf-netmod/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I do think that it would be helpful for this charter to discuss some of
>> the
>> needed WG interactions.  In particular, where encodings of YANG are
>> defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there should be
>> coordination of the impact of changes to the YANG language.
>>
> We could debate whether draft-ietf-core-yang-cbor should have been in core
> or netmod.
> I propose to treat this doc. as the exception, and to keep the guideline
> that mappings should be done in NETMOD.


Sure - but having an indication of other WGs to coordinate with would be
useful.


>   Another question is where do you see the discussion of device profiles
>> or sets of YANG modules needed to meet a particular purpose going? To
>> me, this doesn't read as in scope for this charter and yet I don't think
>> that
>> we've thought through the right place for them.  I'm ok with continued
>> discussion for routing-related ones in RTGWG - but not all device
>> profiles
>> (i.e. a profile of modules needed for a firewall) belong anywhere near
>> Routing.
>>
> Good point for the profiles.
> For the top of the rack switch profile, RTGWG is the best place.
> I propose to add a sentence that will leave the door open for NETMOD
> The NETMOD WG may include work on YANG modules device profiles that do not
> otherwise fall under the charter of any other IETF working group.
>

That sounds good to me; I'm a bit concerned that NETMOD isn't the right
place for the profiles, but we don't have
a flood of them or a better place right now.

Regards,
Alia



> Regards, Benoit
>
>

--94eb2c1cb82451c343054dea4a3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Benoit,

On Mon, Apr 24, 2017 at 10:00 AM, Benoit Claise <bclaise@cis=
co.com> wrote:
Hi Alia,



Now that you are back from vacation...



Alia Atlas has entered the following ballot position for

charter-ietf-netmod-08-05: Yes



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)







The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/charter-i=
etf-netmod/







-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



I do think that it would be helpful for this charter to discuss some of

the

needed WG interactions.=C2=A0 In particular, where encodings of YANG are
defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there should be

coordination of the impact of changes to the YANG language.



We could debate whether draft-ietf-core-yang-cbor should have been in core =
or netmod.

I propose to treat this doc. as the exception, and to keep the guideline th=
at mappings should be done in NETMOD.

Sure =
- but having an indication of other WGs to coordinate with would be useful.=
=C2=A0
=C2=A0



=C2=A0 Another question is where do you see the discussion of device profil=
es

or sets of YANG modules needed to meet a particular purpose going? To

me, this doesn't read as in scope for this charter and yet I don't =
think

that

we've thought through the right place for them.=C2=A0 I'm ok with c=
ontinued

discussion for routing-related ones in RTGWG - but not all device

profiles

(i.e. a profile of modules needed for a firewall) belong anywhere near

Routing.



Good point for the profiles.

For the top of the rack switch profile, RTGWG is the best place.

I propose to add a sentence that will leave the door open for NETMOD

The NETMOD WG may include work on YANG modules device profiles that do not =
otherwise fall under the charter of any other IETF working group.

That sounds good to me; I'm a bit concerned =
that NETMOD isn't the right place for the profiles, but we don't ha=
ve
a flood of them or a better place right now.

Regards,
Alia=C2=A0

=C2=A0
=


Regards, Benoit







--94eb2c1cb82451c343054dea4a3c--


From nobody Mon Apr 24 07:44:17 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A68131593; Mon, 24 Apr 2017 07:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 HQWxcYDsi97j; Mon, 24 Apr 2017 07:44:12 -0700 (PDT)
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 0D1B213158F; Mon, 24 Apr 2017 07:44:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10465; q=dns/txt; s=iport; t=1493045052; x=1494254652; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=T16sjYYin0rkIlne6IHpAlIxzf5V0E1hO4z/kdvREWM=; b=Oj2cKJZFh1Mo0NfIrNt/bwEdnwAeTXXj1dudeqCmgGL2bOBaUmlNCyWG iCb/i2KRAiSwXHztifmXbEc45iKQpErXW1c11PfQ48haO9DRHCYxZDA3v dXnVvQMV4Oswppscjrk65eEasjG5T6OzZ1RMEBoAgVsNt/YfGic69o9MM M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAQDZDf5Y/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgymBDIEMg2eKFXOQdpAwhTWCDyyFeAKETRgBAgEBAQEBAQFrKIU?= =?us-ascii?q?VAQEBAQIBI1YFCwsOCicDAgJGEQYNBgIBAYoQCA6rKIImK4pyAQEBAQEBAQECA?= =?us-ascii?q?QEBAQEBAQEbBYZTggiBZIEKgj2BbBEBgyKCXwWJOoxghyeHF4tvggCFM4NCI4Y?= =?us-ascii?q?/i3iIIR84fggmHQgYFUSEMII6PjWHCIIuAQEB?=
X-IronPort-AV: E=Sophos;i="5.37,244,1488844800";  d="scan'208,217";a="654218423"
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; 24 Apr 2017 14:44:09 +0000
Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v3OEi9Kt000324; Mon, 24 Apr 2017 14:44:09 GMT
To: Alia Atlas 
References: <149206236459.15682.10714540431640759841.idtracker@ietfa.amsl.com>  
Cc: The IESG , netmod-chairs@ietf.org, "netmod@ietf.org" 
From: Benoit Claise 
Message-ID: <159a18f2-2e3a-da3e-062b-710dfc3c27f1@cisco.com>
Date: Mon, 24 Apr 2017 16:44:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------75ACA2CE58C274FB9E688641"
Archived-At: 
Subject: Re: [netmod] Alia Atlas' Yes on charter-ietf-netmod-08-05: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 14:44:15 -0000

This is a multi-part message in MIME format.
--------------75ACA2CE58C274FB9E688641
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Alia,
> Hi Benoit,
>
> On Mon, Apr 24, 2017 at 10:00 AM, Benoit Claise  > wrote:
>
>     Hi Alia,
>
>     Now that you are back from vacation...
>
>         Alia Atlas has entered the following ballot position for
>         charter-ietf-netmod-08-05: Yes
>
>         When responding, please keep the subject line intact and reply
>         to all
>         email addresses included in the To and CC lines. (Feel free to
>         cut this
>         introductory paragraph, however.)
>
>
>
>         The document, along with other ballot positions, can be found
>         here:
>         https://datatracker.ietf.org/doc/charter-ietf-netmod/
>         
>
>
>
>         ----------------------------------------------------------------------
>         COMMENT:
>         ----------------------------------------------------------------------
>
>         I do think that it would be helpful for this charter to
>         discuss some of
>         the
>         needed WG interactions.  In particular, where encodings of
>         YANG are
>         defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there
>         should be
>         coordination of the impact of changes to the YANG language.
>
>     We could debate whether draft-ietf-core-yang-cbor should have been
>     in core or netmod.
>     I propose to treat this doc. as the exception, and to keep the
>     guideline that mappings should be done in NETMOD.
>
>
> Sure - but having an indication of other WGs to coordinate with would 
> be useful.
I'm hesitant to provide a long list of WGs for NETMOD to coordinate 
with, while actually it should be the reverse: WGs dealing with YANG 
should coordinate with NETMOD.
I'm not too concerned about draft-ietf-core-yang-cbor, because we have a 
couple of key NETMOD players looking at this.

>           Another question is where do you see the discussion of
>         device profiles
>         or sets of YANG modules needed to meet a particular purpose
>         going? To
>         me, this doesn't read as in scope for this charter and yet I
>         don't think
>         that
>         we've thought through the right place for them.  I'm ok with
>         continued
>         discussion for routing-related ones in RTGWG - but not all device
>         profiles
>         (i.e. a profile of modules needed for a firewall) belong
>         anywhere near
>         Routing.
>
>     Good point for the profiles.
>     For the top of the rack switch profile, RTGWG is the best place.
>     I propose to add a sentence that will leave the door open for NETMOD
>     The NETMOD WG may include work on YANG modules device profiles
>     that do not otherwise fall under the charter of any other IETF
>     working group.
>
>
> That sounds good to me; I'm a bit concerned that NETMOD isn't the 
> right place for the profiles, but we don't have
> a flood of them or a better place right now.
Great.
Charter updated: https://datatracker.ietf.org/doc/charter-ietf-netmod/

Are we good to go?

Regards, Benoit
>
> Regards,
> Alia
>
>     Regards, Benoit
>
>


--------------75ACA2CE58C274FB9E688641
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Alia,

    

    

      
      
Hi Benoit,

        


          
On Mon, Apr 24, 2017 at 10:00 AM,
            Benoit Claise <bclaise@cisco.com>
            wrote:

            
Hi Alia,

              

              Now that you are back from vacation...

                

                  Alia Atlas has entered the following ballot position
                  for

                  charter-ietf-netmod-08-05: Yes

                  

                  When responding, please keep the subject line intact
                  and reply to all

                  email addresses included in the To and CC lines. (Feel
                  free to cut this

                  introductory paragraph, however.)

                  

                  

                  

                  The document, along with other ballot positions, can
                  be found here:

                  https://datatracker.ietf.org/doc/charter-ietf-netmod/

                  

                  

                  

                  ----------------------------------------------------------------------

                  COMMENT:

                  ----------------------------------------------------------------------

                  

                  I do think that it would be helpful for this charter
                  to discuss some of

                  the

                  needed WG interactions.  In particular, where
                  encodings of YANG are

                  defined elsewhere (i.e. draft-ietf-core-yang-cbor-04),
                  there should be

                  coordination of the impact of changes to the YANG
                  language.

                

              
              We could debate whether draft-ietf-core-yang-cbor should
              have been in core or netmod.

              I propose to treat this doc. as the exception, and to keep
              the guideline that mappings should be done in NETMOD.

            


            

            
Sure - but having an indication of other WGs to
              coordinate with would be useful. 

            

          

        

      

    

    I'm hesitant to provide a long list of WGs for NETMOD to coordinate
    with, while actually it should be the reverse: WGs dealing with YANG
    should coordinate with NETMOD.

    I'm not too concerned about draft-ietf-core-yang-cbor, because we
    have a couple of key NETMOD players looking at this.

    

    

      

        

          

            
 

            

                

                    Another question is where do you see the discussion
                  of device profiles

                  or sets of YANG modules needed to meet a particular
                  purpose going? To

                  me, this doesn't read as in scope for this charter and
                  yet I don't think

                  that

                  we've thought through the right place for them.  I'm
                  ok with continued

                  discussion for routing-related ones in RTGWG - but not
                  all device

                  profiles

                  (i.e. a profile of modules needed for a firewall)
                  belong anywhere near

                  Routing.

                

              
              Good point for the profiles.

              For the top of the rack switch profile, RTGWG is the best
              place.

              I propose to add a sentence that will leave the door open
              for NETMOD

              The NETMOD WG may include work on YANG modules device
              profiles that do not otherwise fall under the charter of
              any other IETF working group.

            

            


            

            
That sounds good to me; I'm a bit concerned that NETMOD
              isn't the right place for the profiles, but we don't have

            
a flood of them or a better place right now.

          

        

      

    

    Great.

    Charter updated:
    https://datatracker.ietf.org/doc/charter-ietf-netmod/

    

    Are we good to go?

    

    Regards, Benoit

    

      

        

          

            


            

            
Regards,

            
Alia 

            


            

            
 

            

              Regards, Benoit

              

            

          

          

        

      

    

    

  


--------------75ACA2CE58C274FB9E688641--


From nobody Mon Apr 24 08:25:36 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AE31316A8 for ; Mon, 24 Apr 2017 08:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71a2UeUShens for ; Mon, 24 Apr 2017 08:25:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B905713168F for ; Mon, 24 Apr 2017 08:25:28 -0700 (PDT)
Received: from localhost (h-13-92.a165.priv.bahnhof.se [155.4.13.92]) by mail.tail-f.com (Postfix) with ESMTPSA id A25201AE0290; Mon, 24 Apr 2017 17:25:27 +0200 (CEST)
Date: Mon, 24 Apr 2017 17:25:27 +0200 (CEST)
Message-Id: <20170424.172527.1653077953152434171.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] comments on tree diagrams draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 15:25:35 -0000

Hi,

Andy Bierman  wrote:
> Hi,
> 
> https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00
> 
> 
> The introduction in this draft does not really reflect the goals that need
> to
> be addressed. Perhaps:
> 
> sec 1, para 1:
> OLD:
> 
>    This document
>    provides the syntax used in YANG Tree Diagrams.  It is expected that
>    this document will be updated or replaced as changes to the YANG
>    language, see [RFC7950 ], necessitate.
> 
> 
> NEW:
> 
>    This document provides the syntax used in YANG Tree Diagrams
> 
>    for version 1.1 of the YANG data modeling language [RFC7950
> ].
> 
>    It is expected that this document will be updated or replaced
> 
>    for future versions of YANG. It should be possible for
> 
>    multiple independent tools to generate the same YANG tree diagrams,
> 
>    using this specification.

Ok.

> Sec. 2:
> 
> The vertical bar (|) and indentation is not defined.

Ok.

> The tab alignment is not defined

Isn't this covered by indentation above?

> The general recursive algorithm is not defined.

Yes, on the TODO list.

> The mandatory vs. optional parts of the diagram are not defined.

Nothing is mandatory; this will be an Informational document.

> (e.g., groupings, notifications, rpcs)

Yes, on the TODO list.

> Examples of all field types should be provided (e.g if-features)

Ok.

> An ABNF for the grammar should be provided.

I don't understand what you refer to?


/martin


From nobody Mon Apr 24 09:16:51 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20261317E5 for ; Mon, 24 Apr 2017 09:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv7GswdQOoF6 for ; Mon, 24 Apr 2017 09:16:44 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3A611317D2 for ; Mon, 24 Apr 2017 09:16:40 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id r190so72831428wme.1 for ; Mon, 24 Apr 2017 09:16:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QUcD8CrJnyYsX1fJRHyVgsZk0U0/YtNZXL1dbEq8Kf8=; b=pvF9HSeVYuU0mf9RNKt0vLOp2rRLBIEClSBNx+PyS2aata/NweUFKF4zmzM4Tp9PNa lY4RgvSBDAPOZZugr2urogtdA1ou54GpLh0tiyHRQ6BjWfmmow8XeF9L68XB4ZbpP2Nr mQODh93oTWVmiKQzP7PQPsnkZ8UZC1vf75XuLueluiX4Yai9Y12NERYqxdKB4t0mPUDD CUSjoCxHzoeCPPpwPlHVq2DQ02+7RA4eWKnD+tvPdf68JN0dDVkhJBo41ofh5zii5HDe wYpP5pE0IP9ZlUHU9+l1a+oxGesRJ3uZMEtvMiIcTl4pla3iJOOEF7wqQj2Y3LuNUHHf 9Jog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QUcD8CrJnyYsX1fJRHyVgsZk0U0/YtNZXL1dbEq8Kf8=; b=YNZkOCwOPX3r1VotAewJQLBaWpEjfNgp6VqLmZrhGUvcmUIk0/gRGoGK5nXfe4ONCL gxjR2cbuMXrOkKqhxXixoHmisZetsLv8s3x+nzk+oXGvUaGHVOvCR4SNc9znc1vk/gNT oBrrML1vk6NHVLuoSuvmht88AvV71eAg0a7knBQMp4AkMN1Hah8b2ngMQblnDKsbXkgl lyrHle6YcXw0taEggiRGZKAUtuXhREeUNGCY6wjWIlsHOruO1QHFSQ7snX/KvvT02DKh 2+4yVwq0h2yBjZKF9d+rkQHl4AesSPhEakz6Aya1/eDH/Kym4UkPDo7PnkJ+nW6dVe6u Ffng==
X-Gm-Message-State: AN3rC/7bbZo8mevnuy9l6f9wAVgvTg+AaCxSzfL1HcXvMB66I4lnkKmJ 9EULGYNj0vhcC0CAF0FuvO9lKq6D4wpt
X-Received: by 10.28.93.13 with SMTP id r13mr9773918wmb.136.1493050599297; Mon, 24 Apr 2017 09:16:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.139.23 with HTTP; Mon, 24 Apr 2017 09:16:38 -0700 (PDT)
In-Reply-To: <20170424.172527.1653077953152434171.mbj@tail-f.com>
References:  <20170424.172527.1653077953152434171.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 24 Apr 2017 09:16:38 -0700
Message-ID: 
To: Martin Bjorklund 
Cc: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a1145b5a89a7a53054debee07
Archived-At: 
Subject: Re: [netmod] comments on tree diagrams draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 24 Apr 2017 16:16:48 -0000

--001a1145b5a89a7a53054debee07
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 24, 2017 at 8:25 AM, Martin Bjorklund  wrote:

> Hi,
>
> Andy Bierman  wrote:
> > Hi,
> >
> > https://tools.ietf.org/html/draft-bjorklund-netmod-yang-tree-diagrams-00
> >
> >
> > The introduction in this draft does not really reflect the goals that
> need
> > to
> > be addressed. Perhaps:
> >
> > sec 1, para 1:
> > OLD:
> >
> >    This document
> >    provides the syntax used in YANG Tree Diagrams.  It is expected that
> >    this document will be updated or replaced as changes to the YANG
> >    language, see [RFC7950 ],
> necessitate.
> >
> >
> > NEW:
> >
> >    This document provides the syntax used in YANG Tree Diagrams
> >
> >    for version 1.1 of the YANG data modeling language [RFC7950
> > ].
> >
> >    It is expected that this document will be updated or replaced
> >
> >    for future versions of YANG. It should be possible for
> >
> >    multiple independent tools to generate the same YANG tree diagrams,
> >
> >    using this specification.
>
> Ok.
>
> > Sec. 2:
> >
> > The vertical bar (|) and indentation is not defined.
>
> Ok.
>
> > The tab alignment is not defined
>
> Isn't this covered by indentation above?
>

no -- the type names are not printed a fixed distance from the last field
but
rather they align with some column (not sure the rule for picking the
column)


>
> > The general recursive algorithm is not defined.
>
> Yes, on the TODO list.
>
> > The mandatory vs. optional parts of the diagram are not defined.
>
> Nothing is mandatory; this will be an Informational document.
>
>

So 6087bis is expected to define guidelines on what IETF documents should
contain?
OK I guess, but it would be better if the guidelines were for all diagrams
(in the same draft).




> > (e.g., groupings, notifications, rpcs)
>
> Yes, on the TODO list.


> > Examples of all field types should be provided (e.g if-features)
>
> Ok.


> > An ABNF for the grammar should be provided.
>
> I don't understand what you refer to?
>
>
Perhaps a grammar (in ABNF) that matches the recursive algorithm, but maybe
this is not possible.

More issues:

 - node order.  Document order needs to be defined.  Need to construct
subtrees from submodules
    in "include-stmt" order.

- can a tree diagram ever include augmenting nodes from external modules?
  If so there is no real document order for multiple imported modules.
  Also no syntax to support it.  (I would say no, this is out of scope)

 - is the module name line part of the diagram?




>
> /martin
>


Andy

--001a1145b5a89a7a53054debee07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Apr 24, 2017 at 8:25 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Hi,



Andy Bierman <andy@yumaworks.com> wrote:

> Hi,

>

> https://tools.ietf.org/=
html/draft-bjorklund-netmod-yang-tree-diagrams-00

>

>

> The introduction in this draft does not really reflect the goals that =
need

> to

> be addressed. Perhaps:

>

> sec 1, para 1:

> OLD:

>

>=C2=A0 =C2=A0 This document

>=C2=A0 =C2=A0 provides the syntax used in YANG Tree Diagrams.=C2=A0 It =
is expected that

>=C2=A0 =C2=A0 this document will be updated or replaced as changes to t=
he YANG

>=C2=A0 =C2=A0 language, see [RFC7950 <https://tools.ietf.o=
rg/html/rfc7950>], necessitate.

>

>

> NEW:

>

>=C2=A0 =C2=A0 This document provides the syntax used in YANG Tree Diagr=
ams

>

>=C2=A0 =C2=A0 for version 1.1 of the YANG data modeling language [RFC79=
50

> <https://tools.ietf.org/html/rfc7950>].

>

>=C2=A0 =C2=A0 It is expected that this document will be updated or repl=
aced

>

>=C2=A0 =C2=A0 for future versions of YANG. It should be possible for
>

>=C2=A0 =C2=A0 multiple independent tools to generate the same YANG tree=
 diagrams,

>

>=C2=A0 =C2=A0 using this specification.



Ok.



> Sec. 2:

>

> The vertical bar (|) and indentation is not defined.



Ok.



> The tab alignment is not defined



Isn't this covered by indentation above?

no -- the type names are not printed a fixed distance from the last f=
ield but
rather they align with some column (not sure the rule fo=
r picking the column)
=C2=A0



> The general recursive algorithm is not defined.



Yes, on the TODO list.



> The mandatory vs. optional parts of the diagram are not defined.



Nothing is mandatory; this will be an Informational document.




So 6087bis is expected =
to define guidelines on what IETF documents should contain?
OK I =
guess, but it would be better if the guidelines were for all diagrams (in t=
he same draft).


=C2=A0

> (e.g., groupings, notifications, rpcs)



Yes, on the TODO list.


> Examples of all field types should be provided (e.g if-features)



Ok.



> An ABNF for the grammar should be provided.



I don't understand what you refer to?



Perhaps a grammar (in ABNF) that matches the r=
ecursive algorithm, but maybe
this is not possible.=C2=A0

More issues:

=C2=A0- node order.=
=C2=A0 Document order needs to be defined.=C2=A0 Need to construct subtrees=
 from submodules
=C2=A0 =C2=A0 in "include-stmt" or=
der.

- can a tree diagram ever include augmenting =
nodes from external modules?
=C2=A0 If so there is no real docume=
nt order for multiple imported modules.
=C2=A0 Also no syntax to =
support it. =C2=A0(I would say no, this is out of scope)

=C2=A0- is the module name line part of the diagram?
<=
br>
=C2=A0
=C2=A0



/martin




<=
/div>
Andy



--001a1145b5a89a7a53054debee07--


From nobody Tue Apr 25 00:40:10 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED21128B90 for ; Tue, 25 Apr 2017 00:40:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 U2LTRAe7Cw1H for ; Tue, 25 Apr 2017 00:40:07 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91568128B38 for ; Tue, 25 Apr 2017 00:40:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=738; q=dns/txt; s=iport; t=1493106006; x=1494315606; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=kuCIDIHETPHrmX+ZL8TFyJ9Ndt16mrunJwnPK9lnld8=; b=WCe4aDeeOCSWvWlYO7XFjXaIi6ocbXfxAVthxaIp1J5HjGHRZm8CxKwR HZhdyyCVm+ydw/SEKMqpt4l685OclVtajUyKaRGpCFvpTI+nmVgOc1/oH nfPcUQNhyhZ0vsL9hV5tgQH+HX5MW3KEGW+Lzu0DL/sy1eok6Ny2SISj/ c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKBABF/P5Y/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDWBDINniwiQWJgVLIpXFQECAQEBAQEBAWsohT8VdgImAl8NCAE?= =?us-ascii?q?BihgOm0qQCYImix4BAQgCJoELhUiCCAuEH4Yhgl8BBJ1BkwaCAIUzg0KFJYE9i?= =?us-ascii?q?3iIITUigQYmHQgYFYU5gXU+NQGJNQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.37,248,1488844800"; d="scan'208";a="693954261"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2017 07:40:04 +0000
Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3P7e4v2031086 for ; Tue, 25 Apr 2017 07:40:04 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: <90f3efff-9892-60a2-462e-daddab62385e@cisco.com>
Date: Tue, 25 Apr 2017 09:40:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] YumaPro 16.10-7 and yanglint 0.12.161 installed in the toolchain
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Apr 2017 07:40:08 -0000

Dear all,

YumaPro 16.10-7 solves this problem (and certainly others):
     Error: Mandatory object 'xxx' not allowed in external augment statement
     .yang:y.z: error(335): mandatory object not allowed
The impacted YANG drafts were:
     draft-ietf-netconf-yang-push
     draft-ietf-netmod-sub-intf-vlan-model

Yanglint 0.12.161 solves this problem (and certainly others):
     err : Invalid value "1" of "min-elements".
     err : "min-elements" is bigger than "max-elements".
At least one impacted YANG drafts (maybe more):
     draft-ietf-netconf-subscribed-notifications

Please check the latest errors/warnings for your YANG module at 
http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit


From nobody Wed Apr 26 06:44:03 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42570129BBF for ; Wed, 26 Apr 2017 06:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2eoSofgkUgt for ; Wed, 26 Apr 2017 06:43:58 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45030129BCA for ; Wed, 26 Apr 2017 06:43:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B1A851C68C6; Wed, 26 Apr 2017 06:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2lxff4rU1F6Z; Wed, 26 Apr 2017 06:43:46 -0700 (PDT)
Received: from [192.168.1.127] (host81-132-49-127.range81-132.btcentralplus.com [81.132.49.127]) by c8a.amsl.com (Postfix) with ESMTPSA id 29E9F1C2DAB; Wed, 26 Apr 2017 06:43:46 -0700 (PDT)
From: William Lupton 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 26 Apr 2017 14:43:55 +0100
To: netmod@ietf.org
Message-Id: <4873921A-9782-4943-A076-C8D9E79E3991@broadband-forum.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [netmod] draft-vallin-netmod-alarm-module status and plans
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 13:44:00 -0000

All,

I heard from Kent that =
https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving =
to CCAMP but I don=E2=80=99t see any mention of it at =
https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as =
a dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any =
more info available please?

Thanks,
William=


From nobody Wed Apr 26 09:35:32 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED381314C6 for ; Wed, 26 Apr 2017 09:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMZGFbSUIpsR for ; Wed, 26 Apr 2017 09:35:29 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0115.outbound.protection.outlook.com [104.47.42.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C291314E3 for ; Wed, 26 Apr 2017 09:35:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dJ1205qFxVQ17Hiy5XyNxy1lJE3MangnHyMLg2imgTU=; b=If3saA+xFIKd3nrosA+DgtCPhRD33gP1d+wbHu0vKqiu1LawsEgmfKp35H3IexNH+j0ZuVuFpd5vAD9SAQMh7qYMrxeY+TYGaMzjM9g08veULT+rndpj6nIHdR27TQrSAIjL2jZf5U66Q4AbnPv4OWqWOcxKcIpiLPTFpItfCM8=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Wed, 26 Apr 2017 16:35:27 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1061.013; Wed, 26 Apr 2017 16:35:27 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] draft minutes posted
Thread-Index: AQHSvqscfSuGMWdXJkizrTAcRn3rpg==
Date: Wed, 26 Apr 2017 16:35:27 +0000
Message-ID: <505880B0-CDE8-40C2-B67D-A1CC64D17623@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:RkqFXCi1mLwUhjRyyCW4W9DGVW7mDyMjTlxMYEac/rlKlheDP0CYAuexF0DKlloRsGDC6kspTcSF6vbvsO89VYouNCzpLKDdgUb2nfvkzv0MEqb3zntclTHg715MTU+L1gu4VZii2+HEHXJA0GHh7yBx63REvyKRCVik17Y7kbxHqujFtqqke5JFMFkSx4uxrwnKbepoGNtdy2tfFeGNlUWL/4OqHBZaL/mrz3461IySEHd+a8GUMYxPsFFUwokC3GAfMIMvlfFth+U7lR4p4BWjdPZg+wNxJNeg1zdrc5C3r1eujOHxQtypD+0jL/mjlB3mjEvPAsVlT7rsXGcMZw==
x-ms-office365-filtering-correlation-id: ed7fc932-88ef-4379-52d3-08d48cc23f06
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BN3PR0501MB1441; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 0289B6431E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39860400002)(39850400002)(39400400002)(39450400003)(279900001)(6306002)(6512007)(5660300001)(99286003)(2351001)(305945005)(3660700001)(3280700002)(6486002)(77096006)(33656002)(8676002)(36756003)(110136004)(38730400002)(19625305001)(6246003)(189998001)(966004)(53936002)(81166006)(86362001)(229853002)(1730700003)(6916009)(6506006)(3846002)(6116002)(102836003)(7736002)(2501003)(82746002)(83506001)(5640700003)(2900100001)(8936002)(4001350100001)(6436002)(2906002)(66066001)(25786009)(54356999)(50986999)(122556002)(83716003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <88D31A6C5A225049ADC36C9C56CB0972@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2017 16:35:27.2523 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Subject: Re: [netmod] draft minutes posted
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 16:35:31 -0000

VGhlIG1pbnV0ZXMgaGF2ZSBiZWVuIHBvc3RlZDoNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv
Y2VlZGluZ3MvOTgvbWludXRlcy9taW51dGVzLTk4LW5ldG1vZC0wMA0KDQpLZW50DQoNCg0KLS0t
LS0tT1JJR0lOQUwgTUVTU0FHRS0tLS0tLQ0KDQpBbGwsIChlc3BlY2lhbGx5IHByZXNlbnRlcnMh
KSwNCg0KUGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSBtZWV0aW5nIG1pbnV0ZXMgaGVyZToNCg0K
ICBodHRwOi8vZXRoZXJwYWQudG9vbHMuaWV0Zi5vcmc6OTAwMC9wL25vdGVzLWlldGYtOTgtbmV0
bW9kDQoNCk1pY2hhZWwsIExvdSwgYW5kIEkgaGF2ZSB1cGRhdGVkIHRoZSBldGhlcnBhZCBzaW5j
ZSB0aGUgbWVldGluZw0KdG8gZmlsbCBpbiBtaXNzaW5nIG9yIGltY29tcGxldGUgY29tbWVudHMs
IGFzIHdlbGwgYXMgdG8gZml4DQp0eXBvcyBhbmQgZmlsbCBpbiBjb21wbGV0ZSBuYW1lcy4gIFN0
aWxsLCB0aGVyZSBpcyBhIGNoYW5jZSB0aGF0DQpzb21ldGhpbmcgd2FzIG1pc3NlZC4NCg0KVGhh
bmtzLA0KS2VudCAoYW5kIExvdSkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg==


From nobody Wed Apr 26 10:47:14 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6420B13154F; Wed, 26 Apr 2017 10:46:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149322881840.2877.7135909152059763984.idtracker@ietfa.amsl.com>
Date: Wed, 26 Apr 2017 10:46:58 -0700
Archived-At: 
Subject: [netmod] WG Action: Rechartered NETCONF Data Modeling Language (netmod)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Apr 2017 17:46:58 -0000

The NETCONF Data Modeling Language (netmod) WG in the Operations and
Management Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the WG Chairs.

NETCONF Data Modeling Language (netmod)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Lou Berger 
  Kent Watsen 

Secretaries:
  Zitao Wang 

Assigned Area Director:
  Benoit Claise 

Operations and Management Area Directors:
  Warren Kumari 
  Benoit Claise 
 
Mailing list:
  Address: netmod@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/netmod
  Archive: https://mailarchive.ietf.org/arch/browse/netmod/

Group page: https://datatracker.ietf.org/group/netmod/

Charter: https://datatracker.ietf.org/doc/charter-ietf-netmod/

The Network Modeling (NETMOD) working group is responsible for the YANG 
data modeling language, which can be used to specify network management 
data models that are transported over such protocols as NETCONF and 
RESTCONF, and guidelines for developing YANG models. The NETMOD working 
group addresses general topics related to the use of the YANG language 
and YANG models, for example, the mapping of YANG modeled data into 
various encodings. Finally, the NETMOD working group also defines core 
YANG models used as basic YANG building blocks, and YANG models that do 
not otherwise fall under the charter of any other IETF working group. 
The NETMOD WG may include work on YANG modules device profiles that do 
not otherwise fall under the charter of any other IETF working group.
  
The NETMOD WG is responsible for:

   a) Maintaining the data modeling language YANG. This effort entails
      periodically updating the specification to address new 
      requirements as they arise.

   b) Maintaining the guidelines for developing YANG models. This effort
      is primarily driven by updates made to the YANG specification.

   c) Maintaining a conceptual framework in which YANG models are used.
      This effort entails describing the generic context that in YANG
      exists and how certain YANG statements interact in that context.
      An example of this is YANG's relationship with datastores.

   d) Maintaining encodings for YANG modeled data. This effort entails
      updating encodings already defined by the NETMOD working group 
      (XML and JSON) to accommodate changes to the YANG specification, 
      and defining new YANG encodings that are needed, and yet do not 
      fall under the charter of any other active IETF working group.

   e) Maintaining YANG models used as basic YANG building blocks. This
      effort entails updating existing YANG models (ietf-yang-types and
      ietf-inet-types) as needed, as well as defining additional core 
      YANG data models when necessary.

   f) Defining and maintaining YANG models that do not fall under the
      charter of any other active IETF working group.

   The NETMOD working group consults with the NETCONF working group to
   ensure that new requirements are understood and can be met by the
   protocols (e.g., NETCONF and RESTCONF) developed within that working
   group.

   The NETMOD working group does not serve as a review team for YANG
   modules developed by other working groups. Instead, the YANG doctors,
   [1] as organized by the OPS area director responsible for network
   management, will act as advisors for other working groups and provide
   YANG reviews for the OPS area directors.

[1] http://www.ietf.org/iesg/directorate/yang-doctors.html



Milestones:
  May 2017 - Submit draft-ietf-netmod-yang-model-classification to IESG  
for publication (as Informational)
  May 2017 - Submit draft-ietf-netmod-entity to IESG for publication (as
Standards Track)
  May 2017 - Submit draft-ietf-netmod-syslog-model to IESG for
publication (as Standards Track)
  Jun 2017 - Submit draft-ietf-netmod-acl-model to IESG for publication
(as Standards Track)
  Jul 2017 - Submit draft-ietf-netmod-revised-datastores to IESG for 
publication (as Standards Track)
  Jul 2017 - Submit draft-ietf-netmod-rfc6087bis to IESG for publication
(as Informational)
  Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG for
publication (as Standards Track)
  Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for
publication (as Standards Track)
  Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to IESG for
publication (as Informational)



From nobody Wed Apr 26 17:55:59 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C60129443 for ; Wed, 26 Apr 2017 17:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKBY7J72eeDg for ; Wed, 26 Apr 2017 17:55:57 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E41124281 for ; Wed, 26 Apr 2017 17:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hDqIbL1Vd8FiopqyY6mLGWWhm983Zt9toq2jncFMBBA=; b=iCl9OudDZLvDeD8fkXbmo/Hz/iL+cV96DvR5/zgVyYJUZddHwtaMeyGuRAG7RHKV+//VMFI21qBH4Qw1qt8t/QN6+fFACajAv6EErVYdhbbKnEvUnDqD/1RvT0H+C3OwYLeAxDV4j7Src76Y1XYBUPLeM3vAa1cafINLU9s6KPk=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Thu, 27 Apr 2017 00:55:56 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1061.013; Thu, 27 Apr 2017 00:55:56 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: doodle poll for schema-mount virtual interim
Thread-Index: AQHSvvEH78BMXdEf/k6ycD03/rMdXQ==
Date: Thu, 27 Apr 2017 00:55:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:KTZ1GJKrASfcKd7tS0wIDstysq+ADBhejvIYSliG0MYr7ODiZzRPNX1+ET678PUNvbuzohkBE4bh+I1q4IIjEHiA4p4v5lO2hKuBAFpjjysy24AeDrHuyOkFdNayGlu/IevEwwTXdyP2H3mv5RLehtxnCb6djN368F3F5yBvfzROb4mEmeDRtEFz9HgTri/2Xh14HzUdZdRSOJE86ogynK38MaWc9haLbZAWxFbHrKqdInNJP/ZmeObx+N9iI2mZ3tMDHzDrSfLaSQwI8W9+PPf2E/eAPpoeaMu1iD3wopMTbbTO/utLDAzDqotRR2aJU+mU4jAd6zOL01dJe5DPnQ==
x-ms-office365-filtering-correlation-id: 7eeba2c9-9ff5-47e0-4ab4-08d48d0829d3
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);  SRVR:BN3PR0501MB1442; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(60409825278598);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; 
x-forefront-prvs: 029097202E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39840400002)(39860400002)(39410400002)(4001350100001)(8936002)(6436002)(7736002)(6486002)(6116002)(83506001)(5640700003)(2900100001)(82746002)(83716003)(122556002)(50986999)(54356999)(2501003)(102836003)(66066001)(2906002)(25786009)(38730400002)(110136004)(77096006)(33656002)(6306002)(189998001)(5660300001)(6512007)(36756003)(2351001)(99286003)(3660700001)(305945005)(6506006)(3280700002)(8676002)(6916009)(1730700003)(86362001)(3846002)(53936002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <7DF55EC3DD570440AFB4EA6E3C1DEAB4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2017 00:55:56.5108 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442
Archived-At: 
Subject: [netmod] doodle poll for schema-mount virtual interim
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 00:55:59 -0000

W3BsZWFzZSBmb3J3YXJkIHRvIG90aGVyIGxpc3RzIGFzIG5lZWRlZF0NCg0KQXMgZGlzY3Vzc2Vk
IGluIENoaWNhZ28sIExvdSBhbmQgSSB3YW50IHRvIHNjaGVkdWxlIGEgdmlydHVhbCBpbnRlcmlt
IHRvIA0KZGlzY3VzcyB0aGUgc2NoZW1hLW1vdW50IGRyYWZ0LiAgSGVyZSBpcyBhIGRvb2RsZSBw
b2xsIGZvciBpdDoNCg0KICAgIGh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsLzN2NnEyeXhlczIzc3I3
emsNCg0KVGhlIGRhdGVzIGFuZCB0aW1lcyBoYXZlIGJlZW4gc2VsZWN0ZWQgYnkgdGhlIGRyYWZ0
IGF1dGhvcnMuICBQbGVhc2UgZmlsbA0KaW4geW91ciBhdmFpbGFiaWxpdHkgc28gd2UgY2FuIGhh
dmUgYSBwcm9kdWN0aXZlIG1lZXRpbmcuDQoNCktlbnQgLy8gc2hlcGhlcmQNCg0KDQoNCg==


From nobody Thu Apr 27 02:36:17 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 341591204DA; Thu, 27 Apr 2017 02:36:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149328577616.2873.67188715683156174@ietfa.amsl.com>
Date: Thu, 27 Apr 2017 02:36:16 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 09:36:16 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the NETCONF Data Modeling Language of the IETF.

        Title           : YANG Module Classification
        Authors         : Dean Bogdanovic
                          Benoit Claise
                          Carl Moberg
	Filename        : draft-ietf-netmod-yang-model-classification-06.txt
	Pages           : 11
	Date            : 2017-04-27

Abstract:
   The YANG data modeling language is currently being considered for a
   wide variety of applications throughout the networking industry at
   large.  Many standards-defining organizations (SDOs), open source
   software projects, vendors and users are using YANG to develop and
   publish YANG modules for a wide variety of applications.  At the same
   time, there is currently no well-known terminology to categorize
   various types of YANG modules.

   A consistent terminology would help with the categorization of YANG
   modules, assist in the analysis of the YANG data modeling efforts in
   the IETF and other organizations, and bring clarity to the YANG-
   related discussions between the different groups.

   This document describes a set of concepts and associated terms to
   support consistent classification of YANG modules.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-06
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-model-classification-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Apr 27 02:51:34 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3A212894A for ; Thu, 27 Apr 2017 02:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fseBYf0hgSYt for ; Thu, 27 Apr 2017 02:51:32 -0700 (PDT)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEC11204DA for ; Thu, 27 Apr 2017 02:51:31 -0700 (PDT)
Received: by mail-wr0-x236.google.com with SMTP id l9so13949049wre.1 for ; Thu, 27 Apr 2017 02:51:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=UIYHnGiXaq2AtBZGuiJObSzfOarN4UtwSHdG1Hgx6uA=; b=cgS3M8FcDDkbEOAmfBRj2TIAKedg3s7rnJvRCE5bvbkyGrKmQksnJOc32WjDuc2iVI YI5f1i+YxyriQXKP26hcz8AGXw5n3JF43PPhvWK0VkOg1cZzmS3z1d7iNaws/TZnOku6 nWYtGyZZbrNRLotdBVPyrq/VSFVDZdmLZG8CkRkrqQhLlDv5EU9d7rBT01J3tBHjVoE3 tF72Iu/YKlGgyVSpptzjl5qBgcRNfBKOuZzEDVn5w0tfPEkHBc08u7IDbQsla6lm8ogR v4RbVd8/TPOtNyXLmAqBPtXLKhf6K4sVn4vHvGiXzHYlaBRg7jKuOH9wlDJJxn/be8p6 8/NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=UIYHnGiXaq2AtBZGuiJObSzfOarN4UtwSHdG1Hgx6uA=; b=PxT/3Gfi3lrBLXZJf7PWH231CeCCyRu23frwLc6fj4c161osd18gp+kC4695POoPdr J5oBK9ufZuYpfx97EMd/zb4mp29S3FW5tx+wl/7NBPeO4XBj1/SmLW6dzk2VRfIHWOm9 L5xVMgjJoFXoQ7Fow/SfMfj6K6B3LWb6lWqBvpGtw7dxGBPZZEgsdgAgj9crIww3vG9M o9MLZkP+cb94/OTJ5CHWJ5mNwkwg7TFDl2TTkOfdIaX/pj7r6+zThQx59n46/2mLtjSV kTvR0+wEI0887Mhogoeu+8tIJqJGwXL0TNH+3dilMzkrwrw0sHA5HDog9DEaNNz0pVqM I5hg==
X-Gm-Message-State: AN3rC/4N5lU/INrSHUPSXGUDdIcQ82V3drJZ+Z6Ah/4p7a9YdH4FTZXK /PRnWCaeJgQC7d2P560=
X-Received: by 10.223.161.130 with SMTP id u2mr2835691wru.203.1493286689935; Thu, 27 Apr 2017 02:51:29 -0700 (PDT)
Received: from [192.168.254.132] ([147.83.206.89]) by smtp.gmail.com with ESMTPSA id s81sm7734692wms.6.2017.04.27.02.51.29 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 02:51:29 -0700 (PDT)
From: Dean Bogdanovic 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 27 Apr 2017 11:51:26 +0200
References: <149328577616.2873.67188715683156174@ietfa.amsl.com>
To: NetMod WG 
In-Reply-To: <149328577616.2873.67188715683156174@ietfa.amsl.com>
Message-Id: 
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 09:51:34 -0000

Hi WG

I have updated the draft to 06 based on comments from Adrian. There are =
no outstanding issues with this draft that are known to me.


> On Apr 27, 2017, at 11:36 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the NETCONF Data Modeling Language of the =
IETF.
>=20
>        Title           : YANG Module Classification
>        Authors         : Dean Bogdanovic
>                          Benoit Claise
>                          Carl Moberg
> 	Filename        : =
draft-ietf-netmod-yang-model-classification-06.txt
> 	Pages           : 11
> 	Date            : 2017-04-27
>=20
> Abstract:
>   The YANG data modeling language is currently being considered for a
>   wide variety of applications throughout the networking industry at
>   large.  Many standards-defining organizations (SDOs), open source
>   software projects, vendors and users are using YANG to develop and
>   publish YANG modules for a wide variety of applications.  At the =
same
>   time, there is currently no well-known terminology to categorize
>   various types of YANG modules.
>=20
>   A consistent terminology would help with the categorization of YANG
>   modules, assist in the analysis of the YANG data modeling efforts in
>   the IETF and other organizations, and bring clarity to the YANG-
>   related discussions between the different groups.
>=20
>   This document describes a set of concepts and associated terms to
>   support consistent classification of YANG modules.
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificati=
on/
>=20
> There are also htmlized versions available at:
> =
https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-06=

> =
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-model-classif=
ication-06
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-model-classific=
ation-06
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Apr 27 02:56:13 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6ED612894A for ; Thu, 27 Apr 2017 02:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syWQM_8F0PBe for ; Thu, 27 Apr 2017 02:56:10 -0700 (PDT)
Received: from gproxy9.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 186811275C5 for ; Thu, 27 Apr 2017 02:56:10 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 1BBCA1E08E9 for ; Thu, 27 Apr 2017 03:56:08 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id DMw51v0022SSUrH01Mw8Bw; Thu, 27 Apr 2017 03:56:08 -0600
X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=AzvcPWV-tVgA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=ZYdVmUXvARwKamMAxUkA:9 a=CjuIK1q_8ugA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GOh7zt3hQg/XU+w8XZh0SBBlnjwU79ZPHzkVNdr1ZKE=; b=aKDlz0M4eEZElgrOk4iXy8mh7I waj2y+smdVILdd1Xkf99R4bfB6vmuTdsaEiJ6MjWlX0DwwPWY1w02AWo4+mysCBqOimDaxi6YdM9D lv4wd4SisiWG2jOPnyGvZRTA5;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:50692 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d3g9c-0005fY-Qm; Thu, 27 Apr 2017 03:56:04 -0600
From: Lou Berger 
To: Dean Bogdanovic , NetMod WG 
Date: Thu, 27 Apr 2017 05:56:03 -0400
Message-ID: <15baed6c738.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: 
References: <149328577616.2873.67188715683156174@ietfa.amsl.com> 
User-Agent: AquaMail/1.8.2-216 (build: 100800200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1d3g9c-0005fY-Qm
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:50692
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 09:56:12 -0000

Great! I'll submit the publication request.

Lou


On April 27, 2017 5:52:06 AM Dean Bogdanovic  wrote:

> Hi WG
>
> I have updated the draft to 06 based on comments from Adrian. There are no 
> outstanding issues with this draft that are known to me.
>
>
>> On Apr 27, 2017, at 11:36 AM, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
>>
>>        Title           : YANG Module Classification
>>        Authors         : Dean Bogdanovic
>>                          Benoit Claise
>>                          Carl Moberg
>> 	Filename        : draft-ietf-netmod-yang-model-classification-06.txt
>> 	Pages           : 11
>> 	Date            : 2017-04-27
>>
>> Abstract:
>>   The YANG data modeling language is currently being considered for a
>>   wide variety of applications throughout the networking industry at
>>   large.  Many standards-defining organizations (SDOs), open source
>>   software projects, vendors and users are using YANG to develop and
>>   publish YANG modules for a wide variety of applications.  At the same
>>   time, there is currently no well-known terminology to categorize
>>   various types of YANG modules.
>>
>>   A consistent terminology would help with the categorization of YANG
>>   modules, assist in the analysis of the YANG data modeling efforts in
>>   the IETF and other organizations, and bring clarity to the YANG-
>>   related discussions between the different groups.
>>
>>   This document describes a set of concepts and associated terms to
>>   support consistent classification of YANG modules.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-06
>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-model-classification-06
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-06
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



From nobody Thu Apr 27 03:05:24 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCF71275C5 for ; Thu, 27 Apr 2017 03:05:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 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=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRGQrO5TA4fs for ; Thu, 27 Apr 2017 03:05:21 -0700 (PDT)
Received: from gproxy3.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 BF9931204DA for ; Thu, 27 Apr 2017 03:05:21 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 78A294030A for ; Thu, 27 Apr 2017 04:05:21 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id DN5H1v00l2SSUrH01N5Lpg; Thu, 27 Apr 2017 04:05:21 -0600
X-Authority-Analysis: v=2.2 cv=K+5SJ2eI c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=AzvcPWV-tVgA:10 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=CTxZ7GfsNaCI0U_ExJoA:9 a=CjuIK1q_8ugA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Kve7edaCrYF9TCfaQR+ysPfMbLzxc8jbXujK9xBU2uo=; b=2FARsLUwY0dVkud7Lf6S39JoRj 8bZaL8C3QXNsT5WuS4JtAvRJ72AYtd5vsr9bgNyADwSV/QQFIJxs7mrXZpcrSSEW3lb6fFHEQLVDo caD6iz1RSElUKlVY+37wOM6IE;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53024 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d3gIX-0006kF-LZ; Thu, 27 Apr 2017 04:05:17 -0600
From: Lou Berger 
To: NETMOD Group 
CC: Warren Kumari 
Date: Thu, 27 Apr 2017 06:05:16 -0400
Message-ID: <15baedf3760.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <149328734264.3028.14798786777450651512.idtracker@ietfa.amsl.com>
References: <149328734264.3028.14798786777450651512.idtracker@ietfa.amsl.com>
User-Agent: AquaMail/1.8.2-216 (build: 100800200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1d3gIX-0006kF-LZ
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:53024
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: [netmod] Fwd: Publication has been requested for draft-ietf-netmod-yang-model-classification-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 10:05:23 -0000

Fyi. Note that Warren Kumari is the responsible AD as Benoit is coauthor. 
(Apparently I can't set this in Data Tracker and it defaults to Benoit.)

Lou


--- Forwarded message ---
From: Lou Berger 
Date: April 27, 2017 6:02:52 AM
Subject: Publication has been requested for 
draft-ietf-netmod-yang-model-classification-06
To: bclaise@cisco.com
CC: netmod-chairs@ietf.org, lberger@labn.net, iesg-secretary@ietf.org, Lou 
Berger 

Lou Berger has requested publication of 
draft-ietf-netmod-yang-model-classification-06 as Informational on behalf 
of the NETMOD working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/





From nobody Fri Apr 28 09:31:30 2017
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C3612EADD for ; Fri, 28 Apr 2017 09:31:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.102
X-Spam-Level: 
X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk
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 gyEaOAOIvMhJ for ; Fri, 28 Apr 2017 09:31:27 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F1412EACF for ; Fri, 28 Apr 2017 09:27:03 -0700 (PDT)
Received: from nitebug.localdomain (46.229.239.158.host.vnet.sk [46.229.239.158]) by mail.hq.sk (Postfix) with ESMTPSA id 1F0B224024D; Fri, 28 Apr 2017 18:27:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1493396820; bh=MueI9Y80Wfrya7WO8GKUMipguRN49wD6Cp0K91KJJLE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=dmr6Jzra6+La3Ckx4mr4r2IZdEtFihaY7kkZ/JwwmjKJC6R/Z7TUtjUqUrvJGQEB2 OKmKOvuf6t7HhCa0HIzhUE61fokmD7U4r4bO0dlmJ93vJ1jW7nMR3eV3WQqSF6rSY1 PILpHH1ffm9fmNg1E5e2Jb6hEYMKeDR1RpdBcNmY=
To: Andy Bierman , Dhirendra Trivedi 
Cc: "netmod@ietf.org" 
References:  
From: Robert Varga 
Message-ID: <638dd25c-909e-1d07-78f0-76e1e75549dc@hq.sk>
Date: Fri, 28 Apr 2017 18:26:53 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QWjqsKjJrnAvgANtPVni6HCK34hd4Bj6U"
Archived-At: 
Subject: Re: [netmod] Query on Announcing Conformance Information in the  Message
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 16:31:29 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QWjqsKjJrnAvgANtPVni6HCK34hd4Bj6U
Content-Type: multipart/mixed; boundary="vw5aphFLOnNR8M0cD8qFMIXXfMdi64whx";
 protected-headers="v1"
From: Robert Varga 
To: Andy Bierman ,
 Dhirendra Trivedi 
Cc: "netmod@ietf.org" 
Message-ID: <638dd25c-909e-1d07-78f0-76e1e75549dc@hq.sk>
Subject: Re: [netmod] Query on Announcing Conformance Information in the
  Message
References: 
 
In-Reply-To: 

--vw5aphFLOnNR8M0cD8qFMIXXfMdi64whx
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 20/04/17 18:35, Andy Bierman wrote:
>=20
> Yes -- it looks correct.
> The structure is defined in RFC 6020:
> https://tools.ietf.org/html/rfc6020#section-5.6.4
>=20

Hello Andy,

One thing that is not quite clear in RFC6020 due to not being clear what
'supported module' means.

Should deviations be applied in case a module is advertised, but is not
mentioned in a deviations parameter like this:

   
       
         http://example.com/syslog?module=3Dsyslog
       
       
         http://example.com/my-deviations?module=3Dmy-devs
       
     

If not, does this imply that any deviation statement targeting an
external module, which does not have a matching deviations parameter
should silently be ignored?

Thanks,
Robert


--vw5aphFLOnNR8M0cD8qFMIXXfMdi64whx--

--QWjqsKjJrnAvgANtPVni6HCK34hd4Bj6U
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIoBAEBCgASBQJZA21TCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTSjwP/idB60eR
R1hQxxcDNUxQnIxHHrlN1ueV+5aHPLl+7F6ftFijHpgeDce0mNa6aAUuf3ryOk8K
J9gN+2PfTUB0ouOBQnZhHGyi/uv2YwJj9I4Xd/BAmJ4pHIljxTwOqHfknsstyTY8
053Fx20PShhNiwe3mIhBoA0WSuHT+EoWjOZ3S5a3c4THB8JXQJEccQRZl7vc1ssg
9zwXElTWzXdf/PHJJdrmvN82Aetu1qeqC97Ik2xxpeQtmZ+te2ojvjaZRVGWCUXM
2TVECztMHUOPaCTletMdbriQ8QpUTblInJjDddrlEprKhI9uaqSZpZjs8yg/8MJV
qUn4olRMOP1DAxObuXvjorxemms35jwauIO2NuItXhNcSwsH+Pap5BoM4HX0G+zg
Lcg/UpNegXNfyWmT8qDALTNCiFZlbVBnd5ERTDLoS8LrEOkWIH4KI83rciRuebNc
Qxdrsx+g9r7wqdOVxzT5XYnD6D7boRpAI3uyFhyGUULEJSUga861OL204YYzbq98
3WaaMrfaxYGX74ep//ghIq4ybOQH3Kn9cbcPn/GNKezpvA5efcP5rlnLxFRhbA9y
L1vPEiyXsKgjXMMUBjWQR8PjD5GfVktqPUZRNQsHaGx5hkdH00v/2Dt1IERIu6sF
vaBG8iFcCLCRrbLvThGe1T8NvVsjcB5QLK0N
=oEfe
-----END PGP SIGNATURE-----

--QWjqsKjJrnAvgANtPVni6HCK34hd4Bj6U--


From nobody Sat Apr 29 07:38:53 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D93F127871; Sat, 29 Apr 2017 07:38:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149347673050.2819.5029242822449997123.idtracker@ietfa.amsl.com>
Date: Sat, 29 Apr 2017 07:38:50 -0700
Archived-At: 
Subject: [netmod] The NETMOD WG has placed draft-openconfig-netmod-model-catalog in state "Candidate for WG Adoption"
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Apr 2017 14:38:51 -0000

The NETMOD WG has placed draft-openconfig-netmod-model-catalog in state 
Candidate for WG Adoption (entered by Lou Berger)

The document is available at
https://datatracker.ietf.org/doc/draft-openconfig-netmod-model-catalog/


From nobody Sun Apr 30 19:31:46 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC3D129411; Sun, 30 Apr 2017 19:31:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: netmod-chairs@ietf.org, netmod@ietf.org, draft-ietf-netmod-yang-model-classification@ietf.org, Lou Berger , lberger@labn.net, warren@kumari.net
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149360589744.9906.9498469901914786081.idtracker@ietfa.amsl.com>
Date: Sun, 30 Apr 2017 19:31:37 -0700
Archived-At: 
Subject: [netmod] Last Call:  (YANG Module Classification) to Informational RFC
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 May 2017 02:31:37 -0000

The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'YANG Module Classification'
   as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-05-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The YANG data modeling language is currently being considered for a
   wide variety of applications throughout the networking industry at
   large.  Many standards-defining organizations (SDOs), open source
   software projects, vendors and users are using YANG to develop and
   publish YANG modules for a wide variety of applications.  At the same
   time, there is currently no well-known terminology to categorize
   various types of YANG modules.

   A consistent terminology would help with the categorization of YANG
   modules, assist in the analysis of the YANG data modeling efforts in
   the IETF and other organizations, and bring clarity to the YANG-
   related discussions between the different groups.

   This document describes a set of concepts and associated terms to
   support consistent classification of YANG modules.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ballot/


No IPR declarations have been submitted directly on this I-D.