From sudeepto.roy@gmail.com Thu Feb 2 04:42:42 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BC31293EC for ; Thu, 2 Feb 2017 04:42:42 -0800 (PST) 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, FREEMAIL_FROM=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 9Wv5ipY1odNh for ; Thu, 2 Feb 2017 04:42:41 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 71E011279EB for ; Thu, 2 Feb 2017 04:42:40 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v77so86158894wmv.0 for ; Thu, 02 Feb 2017 04:42:40 -0800 (PST) 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=yFOfh77JqlzNbUA4z43xdrlMsHXJyfoGwRM5kGF72WU=; b=t8nD6FhxXIWQpAi7fe8WMXoAAW5se0pUIm5mAb3nImDMIbqjyLoB6m0M+Um54oBCyt z+75BSM54BU0J5F+mfMUi6inKMT79VQdONrF1TRPOxQgbhbdprKUpRJHRFLCwTEMjExr SYnvcKen0oMRlZpz0EhPjy0VczH2z/h/XF8SeM7sfBI34om49c9YmfqlqewY65uGvmb7 NRtlwu3uCg27a6Q5+Z0Ew57YNXklhM5oZehfW90ZD/CSdknfYo9Tw7y9kSpa1ZgQjikq 7Vw07t1TCiqCHYY7RDB652CnQi3uzQzvRY9GQNg6aD5kb+NwOsVYfvuS4msbaQKfNd5F l0AQ== 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=yFOfh77JqlzNbUA4z43xdrlMsHXJyfoGwRM5kGF72WU=; b=B2aKt+z+nNIVL9klMCQmwbM/FCfDplsx1LMYLegduLZFWGD9SqwHjkc2ThCHrZRZCt eJj54K36PzI8/Clj/+qz8emwRScFXbGfh44wVIQhnftqwNuGQivifhhFmr8p0WaYNR8K EtU9FpBZTXEoRgXxhLmUB7RTZifd956u2DKIC1/ePT70jfcB2Pv+ISIY/9uk93Ituyh8 0S3EUwBk5ZpjaRcjiMDZ22gllzFih/8vNXW7+5yog6Vb1t8TT0dJl8OIU3ICrwZduVGF TFfBn3Da5rzifUNmvBk99+3RbUKeio9QC+D0+HmYScAG0TgvNOPhbFGHDvxmTT5hELzf yNFQ== X-Gm-Message-State: AIkVDXJ0WDA7KemYrvuHiaIV2fYcAZgS+lgJgy2EZNqc11mfGHeDaSnfO2tMOp48H45zN1fD8GBi27qQUTxxfQ== X-Received: by 10.28.27.69 with SMTP id b66mr23123591wmb.50.1486039356763; Thu, 02 Feb 2017 04:42:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.159.98 with HTTP; Thu, 2 Feb 2017 04:42:36 -0800 (PST) From: Sudeepto Roy Date: Thu, 2 Feb 2017 18:12:36 +0530 Message-ID: To: yang-doctors@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Thu, 02 Feb 2017 05:01:03 -0800 Subject: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 12:53:11 -0000 Hi, I am trying to define "max" as a constant so that it can be reused later for other definitions too. I looked at an example from the site but i could not figure out where "max" is defined. can you please help me with this example, as in how to define a constant so that it can be reused later on. http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetconfStateHtml From nobody Thu Feb 2 05:05:42 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D64B1293DA for ; Thu, 2 Feb 2017 05:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 cqLvO77YudJS for ; Thu, 2 Feb 2017 05:05:39 -0800 (PST) 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 638A3126B6D for ; Thu, 2 Feb 2017 05:05:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C6BA16D3; Thu, 2 Feb 2017 14:05:37 +0100 (CET) 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 np3XbTsjdF7E; Thu, 2 Feb 2017 14:05:34 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Feb 2017 14:05:37 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D737200AD; Thu, 2 Feb 2017 14:05:37 +0100 (CET) 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 R51RaGUv-Qjf; Thu, 2 Feb 2017 14:05:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 28E41200AB; Thu, 2 Feb 2017 14:05:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A80F3E6415E; Thu, 2 Feb 2017 14:05:39 +0100 (CET) Date: Thu, 2 Feb 2017 14:05:39 +0100 From: Juergen Schoenwaelder To: Sudeepto Roy Message-ID: <20170202130539.GA84017@elstar.local> Mail-Followup-To: Sudeepto Roy , yang-doctors@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: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:05:41 -0000 Hi, the "max" in your example is not a constant; it is a part of the range statement and always refers to the maximum value of the type being restricted. See section 9.2.4 of RFC 7950. YANG does not have a concept of constants. /js On Thu, Feb 02, 2017 at 06:12:36PM +0530, Sudeepto Roy wrote: > Hi, > > I am trying to define "max" as a constant so that it can be reused > later for other definitions too. > I looked at an example from the site but i could not figure out where > "max" is defined. can you please help me with this example, as in how > to define a constant so that it can be reused later on. > > http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetconfStateHtml > > > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- 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 Feb 2 05:21:17 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFA129444 for ; Thu, 2 Feb 2017 05:21:15 -0800 (PST) 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, FREEMAIL_FROM=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 5dYk08cvAdDu for ; Thu, 2 Feb 2017 05:21:13 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 25B66129442 for ; Thu, 2 Feb 2017 05:21:13 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id c85so90214106wmi.1 for ; Thu, 02 Feb 2017 05:21:13 -0800 (PST) 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; bh=sdJ+beNA3HL1SuBSUnW8WmqAfTjaJG6cyDP9XycH/g0=; b=rpZzSdfYNu3BCubN75T+EBgX7TFypxbisqxBxMgSv/Z8zShEJQFWxMzjZABXwJQkBu 1d3gsX7w/o8N3tVz3DtMhrNnlATS5xFR+5X7TmJHZvJ3S/lyCPrdwxsKL/lTDTZ1ThJI P1pOJFHUKGIJh9rsM8lfoWzabqzcsIC8qXkrNYFkOEHs592NVJhdTaQCUWFwrmdobJvf SG5BbTcuYQHnI2lhPMIYnusr22O5RBVsHVtxpC8XWLnXFqxvUmMGrz8BCVU+f1/MBlie 2E0Yza3+l7WCmBKOzNP0tTAJrB7GB+BTacQICeZoPucssbT5zsSSP3wkS+KBB6a5SECn ec5w== 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=sdJ+beNA3HL1SuBSUnW8WmqAfTjaJG6cyDP9XycH/g0=; b=pVTZqn7hcypRtoXu2Qv1JgpucNcgIxBx1iwQrcaWzK+PrFG3x1P6hat9T2meR1ZPws ClLQ57DdAWgcYPzlOW0jbdUTQLESRxKde0YcAurjyoFC/fTY/+zJlokjW8sk48vy6Bdv zV8iuxlqWezzJg4HRV4hK+PvMPRHqH9p8Jrd7pwuFgk38DBp4BZMCT9H8fVrBjZuiaBr 1otU+n7F7rInhvpyClqX91doWXIjnMndewvFw8ILW1qp1kCJDIL9kBIP4rY7XCjmmkHS Hm0oopZgC62/NMNd50i2C20wgABfpV1yMcBnzslVE4erPmDZ2pnFo67aAQP26YFgEfuJ sb4g== X-Gm-Message-State: AIkVDXKel/0wEBfD9E25UNh04IBFjxzNDiCJdcmnh3Ql/LHDClZwNZDRPUDb2k4hAxeyFF0ig7QAcLzkEBCtXg== X-Received: by 10.28.68.10 with SMTP id r10mr7920715wma.68.1486041671578; Thu, 02 Feb 2017 05:21:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.159.98 with HTTP; Thu, 2 Feb 2017 05:21:10 -0800 (PST) In-Reply-To: <20170202130539.GA84017@elstar.local> References: <20170202130539.GA84017@elstar.local> From: Sudeepto Roy Date: Thu, 2 Feb 2017 18:51:10 +0530 Message-ID: To: Juergen Schoenwaelder , Sudeepto Roy , yang-doctors@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:21:15 -0000 Hi Juergen, Thanks for the quick answer. so my requirement is something like this. >>> #define VARIABLE_MAX_SIZE 256 char variable[VARIABLE_MAX_SIZE +1]; <<< Can you help me with the yang equivalent for this. Regards, Sudeepto Roy On Thu, Feb 2, 2017 at 6:35 PM, Juergen Schoenwaelder wrote: > Hi, > > the "max" in your example is not a constant; it is a part of the range > statement and always refers to the maximum value of the type being > restricted. See section 9.2.4 of RFC 7950. > > YANG does not have a concept of constants. > > /js > > On Thu, Feb 02, 2017 at 06:12:36PM +0530, Sudeepto Roy wrote: >> Hi, >> >> I am trying to define "max" as a constant so that it can be reused >> later for other definitions too. >> I looked at an example from the site but i could not figure out where >> "max" is defined. can you please help me with this example, as in how >> to define a constant so that it can be reused later on. >> >> http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetconfStateHtml >> >> >> >> >> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > > -- > 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 Feb 2 05:39:41 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83793129417 for ; Thu, 2 Feb 2017 05:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] 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 hVXJjGnE48Ll for ; Thu, 2 Feb 2017 05:39:38 -0800 (PST) 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 BFB391293FC for ; Thu, 2 Feb 2017 05:39:38 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:7140:d301:7b14:571a] (unknown [IPv6:2001:718:1a02:1:7140:d301:7b14:571a]) by mail.nic.cz (Postfix) with ESMTPSA id EEA5762351; Thu, 2 Feb 2017 14:39:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486042777; bh=3+TZ2RuebsbUccLa79lTegJWLMk3R/ltnmthEuaU1PY=; h=From:Date:To; b=uxw/b9JAOneEyw/3+AcGkuDL+hHiKuzkTrEX+dJd9pPFC0Zm10bY+mE2CsIlVhqrZ 6vFJ1QFqC/Sjj2O5lyNFOVLTdN+DxAb6hF2YgnVH3V2YZHvK64hDOI2TxmAKBFFEAc Vm6bAg/SWnTT+rhZtGSV8qFrKVgiAmjgthvhCys4= 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: Thu, 2 Feb 2017 14:39:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4AFEDF4B-1E9C-4905-B53A-E164A28F6613@nic.cz> References: <20170202130539.GA84017@elstar.local> To: Sudeepto Roy X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:39:40 -0000 > On 2 Feb 2017, at 14:21, Sudeepto Roy wrote: >=20 > Hi Juergen, >=20 > Thanks for the quick answer. >=20 > so my requirement is something like this. >=20 >>>>=20 > #define VARIABLE_MAX_SIZE 256 > char variable[VARIABLE_MAX_SIZE +1]; > <<< >=20 > Can you help me with the yang equivalent for this. As Juergen wrote, YANG has no support for this. What you can do is to = write the module in YIN syntax and define the constant as an XML entity. Lada >=20 > Regards, > Sudeepto Roy >=20 >=20 >=20 >=20 > On Thu, Feb 2, 2017 at 6:35 PM, Juergen Schoenwaelder > wrote: >> Hi, >>=20 >> the "max" in your example is not a constant; it is a part of the = range >> statement and always refers to the maximum value of the type being >> restricted. See section 9.2.4 of RFC 7950. >>=20 >> YANG does not have a concept of constants. >>=20 >> /js >>=20 >> On Thu, Feb 02, 2017 at 06:12:36PM +0530, Sudeepto Roy wrote: >>> Hi, >>>=20 >>> I am trying to define "max" as a constant so that it can be reused >>> later for other definitions too. >>> I looked at an example from the site but i could not figure out = where >>> "max" is defined. can you please help me with this example, as in = how >>> to define a constant so that it can be reused later on. >>>=20 >>> = http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetconfStateHt= ml >>>=20 >>> >>> >>> >>> >>> >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Feb 2 05:41:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9807712943A for ; Thu, 2 Feb 2017 05:41:10 -0800 (PST) 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 6gPYTsm1-Gfz for ; Thu, 2 Feb 2017 05:41:08 -0800 (PST) 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 3E640129417 for ; Thu, 2 Feb 2017 05:41:08 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c85so91016689wmi.1 for ; Thu, 02 Feb 2017 05:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Puzm+RrOkWQO+1skb5wkv3ImtDdEqIxIVXXQx6eyMGk=; b=brg9+WlBAA20KtjK7MEsb0WXJzsIht/VlPNPUitNI+rvHfm/GmaDHGpxUwNFJSgPKC IzikVW9H+31cx0WHKPD3YbIL9YvpnG0iBU944sJHdEwlBvp7XddENyJmYkardcQt5Btp Jn3TeunJPailLVeerAIFShHv0R/6HkWcfiG6uZbQjDcZQfa84EuqU0oFn5y2wSwckC0f nJHW4n+wzYS0r2D2WIqLONSihAyhjPnjoOMGzMP29UTfe8cYF7YAWH0RRcTBxJSOa+VN GSp3XQlEkFu7sZq7/pKaoqSuul1Ed9v84DUYSUyUZNG938CTaLvL/XeWhUCcjUwVuU77 6xZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Puzm+RrOkWQO+1skb5wkv3ImtDdEqIxIVXXQx6eyMGk=; b=Jkoi3CENwjTil5tvuf0hqyBVxnWt8M/8KEMAAG9hvGGZ7+OSWm3Z2CR4g5H/7ZDq1F QZBofvRxTobEreM4FgADJgYuV0NK4wzL/CCgzCxpre+o2EWg0rGUHm+yyPMDR4DbZmKm 17iFZiVKRCRBIKRflC4hFBMTdM49GE3UT8OA8wFQWPnuE7s9bCiA4wGAYRMJr7mZbBaV fUV0dsEjn0rSdJS6Zi9Qou/DzwtB6i5y5B5En7s4sbQPI4sllzCl2M9bUDEPAhtOMexn oxy2JDx7kgTuFJ2Z4gAVGr/SBL7yBD9CBokho6cCSgwQq2k3iyPhkzA/8xqpvk1Kyw2h RGPA== X-Gm-Message-State: AIkVDXILeZgu16Mh/gKWRHyf+GqZ1hUvfpBXROJYqc//4vjYFGeW0MdpNtRqbIrNJ366p44qxKm+FAC3j3bo/g== X-Received: by 10.28.27.69 with SMTP id b66mr23341118wmb.50.1486042866764; Thu, 02 Feb 2017 05:41:06 -0800 (PST) MIME-Version: 1.0 References: <20170202130539.GA84017@elstar.local> <4AFEDF4B-1E9C-4905-B53A-E164A28F6613@nic.cz> In-Reply-To: <4AFEDF4B-1E9C-4905-B53A-E164A28F6613@nic.cz> From: Sudeepto Roy Date: Thu, 02 Feb 2017 13:40:56 +0000 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114b295031d11f05478c5131 Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:41:10 -0000 --001a114b295031d11f05478c5131 Content-Type: text/plain; charset=UTF-8 Thank you for the clarification. On Thu 2 Feb, 2017, 7:09 PM Ladislav Lhotka, wrote: > > > On 2 Feb 2017, at 14:21, Sudeepto Roy wrote: > > > > Hi Juergen, > > > > Thanks for the quick answer. > > > > so my requirement is something like this. > > > >>>> > > #define VARIABLE_MAX_SIZE 256 > > char variable[VARIABLE_MAX_SIZE +1]; > > <<< > > > > Can you help me with the yang equivalent for this. > > As Juergen wrote, YANG has no support for this. What you can do is to > write the module in YIN syntax and define the constant as an XML entity. > > Lada > > > > > Regards, > > Sudeepto Roy > > > > > > > > > > On Thu, Feb 2, 2017 at 6:35 PM, Juergen Schoenwaelder > > wrote: > >> Hi, > >> > >> the "max" in your example is not a constant; it is a part of the range > >> statement and always refers to the maximum value of the type being > >> restricted. See section 9.2.4 of RFC 7950. > >> > >> YANG does not have a concept of constants. > >> > >> /js > >> > >> On Thu, Feb 02, 2017 at 06:12:36PM +0530, Sudeepto Roy wrote: > >>> Hi, > >>> > >>> I am trying to define "max" as a constant so that it can be reused > >>> later for other definitions too. > >>> I looked at an example from the site but i could not figure out where > >>> "max" is defined. can you please help me with this example, as in how > >>> to define a constant so that it can be reused later on. > >>> > >>> > http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetconfStateHtml > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> yang-doctors mailing list > >>> yang-doctors@ietf.org > >>> https://www.ietf.org/mailman/listinfo/yang-doctors > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > > > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > -- Regards, Sudeepto Kumar Roy sent from a phone --001a114b295031d11f05478c5131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you for the clarification.


On Thu 2 Feb, 2017, 7:09 PM= Ladislav Lhotka, <lhotka@nic.cz>= ; wrote:

> On 2 Feb 2017, at 14:21, Sudeepto Roy <sudeepto.roy@gmail.com<= /a>> wrote:
>
> Hi Juergen,
>
> Thanks for the quick answer.
>
> so my requirement is something like this.
>
>>>>
> #define=C2=A0 =C2=A0VARIABLE_MAX_SIZE=C2=A0 256
> char variable[VARIABLE_MAX_SIZE +1];
> <<<
>
> Can you help me with the yang equivalent for this.

As Juergen wrote, YANG has no support for this. What you can do is to write= the module in YIN syntax and define the constant as an XML entity.

Lada

>
> Regards,
> Sudeepto Roy
>
>
>
>
> On Thu, Feb 2, 2017 at 6:35 PM, Juergen Schoenwaelder
> <j.schoenwaelder@jacobs-university.de> wr= ote:
>> Hi,
>>
>> the "max" in your example is not a constant; it is a par= t of the range
>> statement and always refers to the maximum value of the type being=
>> restricted. See section 9.2.4 of RFC 7950.
>>
>> YANG does not have a concept of constants.
>>
>> /js
>>
>> On Thu, Feb 02, 2017 at 06:12:36PM +0530, Sudeepto Roy wrote:
>>> Hi,
>>>
>>> I am trying to define "max" as a constant so that it= can be reused
>>> later for other definitions too.
>>> I looked at an example from the site but i could not figure ou= t where
>>> "max" is defined. can you please help me with this e= xample, as in how
>>> to define a constant so that it can be reused later on.
>>>
>>> http://www.yang-central.org/twiki/bin/view/Main/YangExamplesNetcon= fStateHtml
>>>
>>> <leaf name=3D"session-id">
>>>=C2=A0 =C2=A0 <type name=3D"uint32">
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <range value=3D"1..max"= ;/>
>>>=C2=A0 =C2=A0 </type>
>>> </leaf>
>>>
>>> _______________________________________________
>>> yang-doctors mailing list
>>> yang-doctors@ietf.org
>>> https://www.ietf.= org/mailman/listinfo/yang-doctors
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 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/><= br class=3D"gmail_msg"> >
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mail= man/listinfo/yang-doctors

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





--

Regards,
Sudeepto Kumar Roy

sent from a phone

--001a114b295031d11f05478c5131-- From nobody Thu Feb 2 06:04:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0263129467 for ; Thu, 2 Feb 2017 06:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 iNlBfWHvyeGv for ; Thu, 2 Feb 2017 06:04:20 -0800 (PST) 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 6FC79129454 for ; Thu, 2 Feb 2017 06:04:20 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 45CE76BC; Thu, 2 Feb 2017 15:04:19 +0100 (CET) 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 PhkrS1-RmUKt; Thu, 2 Feb 2017 15:04:16 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Feb 2017 15:04:19 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EF0BB200B8; Thu, 2 Feb 2017 15:04:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7wmjNRefFV8R; Thu, 2 Feb 2017 15:04:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A6452200BC; Thu, 2 Feb 2017 15:04:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D72D33E6432F; Thu, 2 Feb 2017 15:04:21 +0100 (CET) Date: Thu, 2 Feb 2017 15:04:21 +0100 From: Juergen Schoenwaelder To: Sudeepto Roy Message-ID: <20170202140421.GA84145@elstar.local> Mail-Followup-To: Sudeepto Roy , yang-doctors@ietf.org References: <20170202130539.GA84017@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: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:04:22 -0000 On Thu, Feb 02, 2017 at 06:51:10PM +0530, Sudeepto Roy wrote: > Hi Juergen, > > Thanks for the quick answer. > > so my requirement is something like this. > > >>> > #define VARIABLE_MAX_SIZE 256 > char variable[VARIABLE_MAX_SIZE +1]; > <<< > > Can you help me with the yang equivalent for this. This is likely not what you want, but in principle you can run the C preprocessor (or even m4) to produce a YANG module with expanded constants. That said, there are no many places in YANG where constants really make much sense. If you want to restrict the range of a type or the number of list entries, there are ways to do this in YANG proper. Perhaps it helps if you explain for what purpose you think you need a named constant. /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 Feb 2 06:11:04 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF53129408 for ; Thu, 2 Feb 2017 06:11:03 -0800 (PST) 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, FREEMAIL_FROM=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 Pk9ISBqmELI1 for ; Thu, 2 Feb 2017 06:10:54 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 EAC79129413 for ; Thu, 2 Feb 2017 06:10:49 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id r18so13384205wmd.3 for ; Thu, 02 Feb 2017 06:10:49 -0800 (PST) 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; bh=HaZuHcnwn6eN2ai/f3Z1NgiwjC70IWndgcFQcR4vMNQ=; b=awbpk8/rUy+pImrGd8PXQ4jFQ7GuYJdm9xIWAMvJUQbPrL+IvJ470ZTp2nwP13ROT6 eqQ/mzT51KsdgM7TQ5OgGCKATFS9I7o6Phqe16O2r+0O7X1ER7jbg6waDq/jlkWvwLrg tLwEogR/Rw4YKIm0mon+AjTF7uyY/XUOwAmOWyY6Jf55pP0uOL8nk6Y8X7aTi8RgT/Pd aYed0SrKXhGZKyY0h7K2t9ObUU1UUpz1j5G8C8/75lrFIXm0Gz+1uMvmZmjaPtrYRCTT HuMZpQHjrKK9AEpOZxaeaRwBqW/dBmXpn/qAH3CiDKt5AhairDy9uYggKwtBulDx/1pl nlNQ== 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=HaZuHcnwn6eN2ai/f3Z1NgiwjC70IWndgcFQcR4vMNQ=; b=RDKYU9OeW1fZXgRRo8YHqbqXzCljbx5/ig9j1zYpghpK3tnVc283EijO1+1qESRt9u XFngZFsJKWVYptakUzLKOBneqX/hS9qQ9SBn7Szrkuh38ojudLEJ1iS/AXMEChCKKQ6k qajmlCyH3rUNcESN8utDhymQb4Qn4D3wjqzcv8ReVKdHNZetISvaNbwWnDk2LQFYQYAr mxuwapXzTEqTUSRoNx9AoHHOo3dUZoIxfwpifAw4TQayPRMN6eLx72mzAep2BOf3hHhG crJdq+9LsDdsHyOPtogVrH36tisItShb2G4rozIZB0LN8ztQvpR286JgMuaew/3y8mJN Gn3A== X-Gm-Message-State: AIkVDXKlYbQQq+gyteU+VpluO8JPjSZYIkXrIfd9Jq7enTSPr0s8epVnaeV42NQy2rnb3CFJBYfD+jga+auqSg== X-Received: by 10.28.69.202 with SMTP id l71mr28987378wmi.68.1486044648388; Thu, 02 Feb 2017 06:10:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.159.98 with HTTP; Thu, 2 Feb 2017 06:10:47 -0800 (PST) In-Reply-To: <20170202140421.GA84145@elstar.local> References: <20170202130539.GA84017@elstar.local> <20170202140421.GA84145@elstar.local> From: Sudeepto Roy Date: Thu, 2 Feb 2017 19:40:47 +0530 Message-ID: To: Juergen Schoenwaelder , Sudeepto Roy , Benoit Claise Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:11:03 -0000 Hi, an example can be: #define INTERFACE_NAME_SIZE 256 char if_eth0[INERFACE_NAME_SIZE +1]; char if_eth1[INERFACE_NAME_SIZE +1]; char if_eth3[INERFACE_NAME_SIZE +1]; essentially by changing just the "INERFACE_NAME_SIZE", i can change the size for the arrays used for the interface. right now i would have to exactly know which interface name size needs a change and accordingly i would need to touch each and every variable affected. Regards, Sudeepto Roy On Thu, Feb 2, 2017 at 7:34 PM, Juergen Schoenwaelder wrote: > On Thu, Feb 02, 2017 at 06:51:10PM +0530, Sudeepto Roy wrote: >> Hi Juergen, >> >> Thanks for the quick answer. >> >> so my requirement is something like this. >> >> >>> >> #define VARIABLE_MAX_SIZE 256 >> char variable[VARIABLE_MAX_SIZE +1]; >> <<< >> >> Can you help me with the yang equivalent for this. > > This is likely not what you want, but in principle you can run the C > preprocessor (or even m4) to produce a YANG module with expanded > constants. > > That said, there are no many places in YANG where constants really > make much sense. If you want to restrict the range of a type or the > number of list entries, there are ways to do this in YANG proper. > Perhaps it helps if you explain for what purpose you think you need a > named constant. > > /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 Feb 2 06:23:43 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2748129640 for ; Thu, 2 Feb 2017 06:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] 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 xhEqVOS7KxJT for ; Thu, 2 Feb 2017 06:23:41 -0800 (PST) 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 43242129453 for ; Thu, 2 Feb 2017 06:23:41 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 125A6769; Thu, 2 Feb 2017 15:23:40 +0100 (CET) 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 ws0gNbrAXbBk; Thu, 2 Feb 2017 15:23:36 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Feb 2017 15:23:39 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BF55200BC; Thu, 2 Feb 2017 15:23:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kqXdO-AMnRsA; Thu, 2 Feb 2017 15:23:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F119200AD; Thu, 2 Feb 2017 15:23:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6596B3E643F6; Thu, 2 Feb 2017 15:23:42 +0100 (CET) Date: Thu, 2 Feb 2017 15:23:42 +0100 From: Juergen Schoenwaelder To: Sudeepto Roy Message-ID: <20170202142342.GB84145@elstar.local> Mail-Followup-To: Sudeepto Roy , Benoit Claise References: <20170202130539.GA84017@elstar.local> <20170202140421.GA84145@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: Cc: Benoit Claise Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 14:23:43 -0000 Sudeepto, I understand C coding but this is not what we are doing in YANG. If you want to restrict the size of a string in YANG, you create a new type and then you use this restricted type, for example: typedef ifname { type string { length "0..256"; } } Note that RFC 7223 does not put a restriction on interface names. If your implementation has a restriction, the proper thing would be to write a YANG deviation statement that declares your restriction in YANG. (See RFC 7950 for details.) If you have a decent toolset, then the tools would generate the C definitions that you need out of the YANG definitions. In short, writing YANG is not the same as writing C code. And it is generally a good idea to generate C code out of YANG definitions instead of trying to work the other way round. /js On Thu, Feb 02, 2017 at 07:40:47PM +0530, Sudeepto Roy wrote: > Hi, > > an example can be: > > #define INTERFACE_NAME_SIZE 256 > > char if_eth0[INERFACE_NAME_SIZE +1]; > char if_eth1[INERFACE_NAME_SIZE +1]; > char if_eth3[INERFACE_NAME_SIZE +1]; > > essentially by changing just the "INERFACE_NAME_SIZE", i can change > the size for the arrays used for the interface. > > right now i would have to exactly know which interface name size needs > a change and accordingly i would need to touch each and every variable > affected. > > Regards, > Sudeepto Roy > > > > > On Thu, Feb 2, 2017 at 7:34 PM, Juergen Schoenwaelder > wrote: > > On Thu, Feb 02, 2017 at 06:51:10PM +0530, Sudeepto Roy wrote: > >> Hi Juergen, > >> > >> Thanks for the quick answer. > >> > >> so my requirement is something like this. > >> > >> >>> > >> #define VARIABLE_MAX_SIZE 256 > >> char variable[VARIABLE_MAX_SIZE +1]; > >> <<< > >> > >> Can you help me with the yang equivalent for this. > > > > This is likely not what you want, but in principle you can run the C > > preprocessor (or even m4) to produce a YANG module with expanded > > constants. > > > > That said, there are no many places in YANG where constants really > > make much sense. If you want to restrict the range of a type or the > > number of list entries, there are ways to do this in YANG proper. > > Perhaps it helps if you explain for what purpose you think you need a > > named constant. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 2 07:36:34 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D0129673 for ; Thu, 2 Feb 2017 07:36:33 -0800 (PST) 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, FREEMAIL_FROM=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 gRi_5n6UHsbf for ; Thu, 2 Feb 2017 07:36:29 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::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 C48E412966F for ; Thu, 2 Feb 2017 07:36:28 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id r18so13836470wmd.3 for ; Thu, 02 Feb 2017 07:36:28 -0800 (PST) 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; bh=QH8stnTApfFNnMPk55r1HKU2yqeV3wVBupPtUdTsReY=; b=AjswcE2THn4p0FZD8t8Ks6eB9lpvnF/M7uozsjmi7cgbE13SJIGORZNbGMRJN+Zz2M w5f3xBx/IRX1rOz/zHElQ6mC2j4tegln/FU3Cau1OyKrtdltnTNjdLptf2vYA+7cxv6A Lu2aN0bHZIi0BX6OI5Mv0P67lFl1ShPTY4H0+GVr7xYpKBf/Owicm/qC/rCD3yqAnVtQ 55sKLQFueHoUWLdlL5e8OY6+icAOqE0moLgaR+KuCmSxw72zgnjp3/hqAgN/M+8SisO5 kNW/GojxdUUMBMSMh2WaDTaz+WtpUVmxlzFcqjyBAjspRbT1L9y+Q9IlYLyDNM0cPb44 eG9g== 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=QH8stnTApfFNnMPk55r1HKU2yqeV3wVBupPtUdTsReY=; b=UUmgAH7DhqyZiAVQCSDRx4sr0wTP4O4lgf4Qn+k3Qv4VbP+FfeHc/oZ+1Egalnbumy XVVnEpKanS7v3k/lFZl2GKk0PiLrQLoCIZf2/OHNvhBCg0qJ7YhG6coxiF4PLn7DmT5I tPw95NBzIzkAbm+ftfxxzVzTqaMV9xi/uwRuNZOtamXqlzTsHXMmrRjN1heJX9nHlJDd xbH8zj1riBd/3YaKsedMGo1wIx5T1WzVsgXaU4jvWWAzBz5oJgwZRDscuK/dakvS3m5H U6PS+gCxXorO9B786gyWl1dFMNNpQo/QWgU9ZRUCQ6xQ06g69/SAEPtFfcbj6jCO7Ma8 QzKQ== X-Gm-Message-State: AIkVDXJnLPu4OctJGddHXrmdK9c5gmqZ0BVwQb3/OdnOrP5nfiWK3V9FHYrJrIy0SzUtmMv9ISJMrKJ/jk5pcg== X-Received: by 10.28.69.202 with SMTP id l71mr29346549wmi.68.1486049787235; Thu, 02 Feb 2017 07:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.159.98 with HTTP; Thu, 2 Feb 2017 07:36:26 -0800 (PST) In-Reply-To: <20170202142342.GB84145@elstar.local> References: <20170202130539.GA84017@elstar.local> <20170202140421.GA84145@elstar.local> <20170202142342.GB84145@elstar.local> From: Sudeepto Roy Date: Thu, 2 Feb 2017 21:06:26 +0530 Message-ID: To: Juergen Schoenwaelder , Sudeepto Roy , Benoit Claise Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [yang-doctors] defining constants in yang X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:36:33 -0000 Hi Juergen, Thanks for your clarification and time on this. :) Regards, Sudeepto Roy On Thu, Feb 2, 2017 at 7:53 PM, Juergen Schoenwaelder wrote: > Sudeepto, > > I understand C coding but this is not what we are doing in YANG. If > you want to restrict the size of a string in YANG, you create a new > type and then you use this restricted type, for example: > > typedef ifname { > type string { > length "0..256"; > } > } > > Note that RFC 7223 does not put a restriction on interface names. If > your implementation has a restriction, the proper thing would be to > write a YANG deviation statement that declares your restriction in > YANG. (See RFC 7950 for details.) > > If you have a decent toolset, then the tools would generate the C > definitions that you need out of the YANG definitions. > > In short, writing YANG is not the same as writing C code. And it is > generally a good idea to generate C code out of YANG definitions > instead of trying to work the other way round. > > /js > > On Thu, Feb 02, 2017 at 07:40:47PM +0530, Sudeepto Roy wrote: >> Hi, >> >> an example can be: >> >> #define INTERFACE_NAME_SIZE 256 >> >> char if_eth0[INERFACE_NAME_SIZE +1]; >> char if_eth1[INERFACE_NAME_SIZE +1]; >> char if_eth3[INERFACE_NAME_SIZE +1]; >> >> essentially by changing just the "INERFACE_NAME_SIZE", i can change >> the size for the arrays used for the interface. >> >> right now i would have to exactly know which interface name size needs >> a change and accordingly i would need to touch each and every variable >> affected. >> >> Regards, >> Sudeepto Roy >> >> >> >> >> On Thu, Feb 2, 2017 at 7:34 PM, Juergen Schoenwaelder >> wrote: >> > On Thu, Feb 02, 2017 at 06:51:10PM +0530, Sudeepto Roy wrote: >> >> Hi Juergen, >> >> >> >> Thanks for the quick answer. >> >> >> >> so my requirement is something like this. >> >> >> >> >>> >> >> #define VARIABLE_MAX_SIZE 256 >> >> char variable[VARIABLE_MAX_SIZE +1]; >> >> <<< >> >> >> >> Can you help me with the yang equivalent for this. >> > >> > This is likely not what you want, but in principle you can run the C >> > preprocessor (or even m4) to produce a YANG module with expanded >> > constants. >> > >> > That said, there are no many places in YANG where constants really >> > make much sense. If you want to restrict the range of a type or the >> > number of list entries, there are ways to do this in YANG proper. >> > Perhaps it helps if you explain for what purpose you think you need a >> > named constant. >> > >> > /js >> > >> > -- >> > Juergen Schoenwaelder Jacobs University Bremen gGmbH >> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> > Fax: +49 421 200 3103 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Feb 6 03:50:44 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C93129CE0 for ; Mon, 6 Feb 2017 03:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 QiUMmwuMFtkt for ; Mon, 6 Feb 2017 03:50:41 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 4A821129535 for ; Mon, 6 Feb 2017 03:50:41 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-aa-5898630ff668 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 46.06.24099.F0368985; Mon, 6 Feb 2017 12:50:39 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 12:50:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BKRnyDx0Caf67piSaIFMKofRNIX2JG3jxqEZ3uSlamU=; b=dtLmfPCuqdh+MIonLwbaQXyo8068RXtoO8hBaM5Pw1AaUF1HMd4l08BbO+A2mK9cjQOUXA4BGD/3jno+p8AserxioPXnJl4gjItbWtg5PVBg3Te57cLKORXjKVvtGel9qLDXUIDjYAd3n07lP71DskNdR4H972wa/FxjyyZBaSs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.235] (91.82.100.59) by VI1PR07MB0960.eurprd07.prod.outlook.com (10.161.110.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 11:50:32 +0000 To: YANG Doctors From: Balazs Lengyel Message-ID: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> Date: Mon, 6 Feb 2017 12:50:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: DB5PR0301CA0032.eurprd03.prod.outlook.com (10.167.222.170) To VI1PR07MB0960.eurprd07.prod.outlook.com (10.161.110.152) X-MS-Office365-Filtering-Correlation-Id: c5ab2fb7-1690-480a-d2a4-08d44e865b66 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB0960; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 3:0/QJ9B6POPsR/oAsTxbLFnmSIwtNHxuzvUQntj3Tu988J27Cg1IVV5W7Nbc2NVP2FrRCBzpiHMc3bpb+XnrF9K7xEE8WwCoMHsSSKGEWJeaT4NWRXxHCrMSLlVvv7HXe5xTmuVEQxmTzkCFtr3+3gN+PgPK34TxsVk2Kzp8etVLrVwBa6oWtZ0y/Lg0SExpE7i1ug0ZYWsrsDIXcWBXW2L+qbwMwvwpLIt8he6wD5XaXyHs00jE0pGNLvbS1J3OpkXpb2/HZtml6pKI301GfFQ==; 25:fwwebgJsMcvXtPPPNWDld/7xcQjr9cTUT8dvoFlOQL2c2zjkpO8Xv7FFIfeMsbX4Z261zm8Xk0+HMZK6c1ZaTIcStYRnF2DjRnIn2JTC3uR0ywszmzVBbLz96sV0ry4fKWlFsfpiUqXqPJJrwjFnsm5ATNUICGiq4E2e/iBD1vQAlQlUnkvywZICWvYlLScFhZje3GxfYMdgMK5P/RLlZ6BVidMzTgfMb432KtTDlIccSMOsJTtHglxRSxG2FczWNbHsuY7Gb725DTdJmOGZv0/ZwPIHA7d0dyhTylOqViLcZHhdaPpXGfK+9sEXjIRv43SFRB1AnGDj55jvdPiyfv9zS179pOv7eltU+diBGMXZjDRLKMLYlFsP1/V3z81bcjuWUT1iQrp+KznIPLKZ1rVqGzQwshWAysGj+niFgrAVeOyf+VtbGQm4zP51aODvHpMqnccHBi81Z236gOHX9g== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 31:OUJTl3C0IlkMI7vNpFHjFixK5jYAcc5TIUxOQA00DKrRqbl5HY0BCyaC1Uy2BYjFXjmB3RZaM+2MGQ1MwY/YOiwMqSq+0xLUblXRJEJoueZlRd8qxmByBQwrm/rnJT/TaZLHFACXPPS0tVuV+rseuqIAMfzWxGlcdSJWqZMNCz50TC/FZ5918pghTZj1IAdzl+h3KJXV/F1H/ldttj+qA+tJTPNgtfj90WHowJjBxhMQCQ9K67VYRUVPEAWjS7Q3r1IwCNhpFdtgs1B9Wt2gRg==; 20:ui/pNQBh0VpMnwT16kpsrsWPjLsTyA9SMSJycMhJS5WxUraINsbNtPdGnoFXBll+nLxaAPGWKZYJtGOj2xRmtN3xR822O9qhhfJsoqHy044h+SECB7yDz07ndrCp4eOLbY9AP0Q7SE4RM6Y6VDfDWopL/VZYseVU9U1Ac99qH0oyGC/X3/0iawP2NQzfW15unZN8/1wGEOQSowwvpqB/K/py0M37WyYj6T/MV4jm5zHZYug5vjYjImVK0aAoWQh2RY6jdviakPCHdxgbzIegKe6o7YnCPsSMZq75ukL5NRx2vbjhtqas9XscUcAYOcLQlSMHakhgI7aicx6yROdIH/SUGEqjICuv3rbYWQQLjgtCB4ERGpPteb9O/cvgP72YebUAoPBMmOjBMdhNUs2fNcPuHl/YCPIhILrSqmlk5QWLLoMehaumG+yva8A4PcUxrtaBR6cpzfnDX9Oqsirg8Jqqy/3Rim5L4N5ZWZO21tuD0CMgWcD1QTLbhP3pngnD X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:VI1PR07MB0960; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0960; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 4:dLxxC7ORzkQNlAM+RAhXu7CR9ZbgHPur8bXRRCn/FdxfZxPyMjOvJwbDzaViNl9GyTtY+AYQKis7jex38JA3OL9WXf+pyNlXCm+6KLHbFao/mgG5w/1NbtEe8i1F5emGjZqWbRKyXnqu9sPloITkNNDQz9obTK+3xHW+BbywwXuZ3bvxqB1t2DfL8JHbYn1QK5kZiM1D3nrLYlbmG4NiriF769Cg3yG+yFMPqKJO6qBV/lgAk7v3+W2zFvoGMzAlHLHeYGJhlRFG518FVPVDEjHMtoW4LhQ0KYY83lASch772KcZsDO9k04ietnMyp5Ab3mU0+IMYPJ1cRmvDD85f+IY9l+q11Xb8z19nN8D1BItltRUsAULVG8qABzUzeXu7byjch00pLBb2sU1paaFcqyrwjODYSBZTJ7pKdyBbQkMoaDe/uQj94Tj8DhNgXyV1NYUQj8GWm+PbmDPRLpxsJ/slIGbP2EQEh+w97tzGnVjygWw8YzxVLGNEuDBDnuddqLikOwkplRfkjDbPxWajyK9tNhtLT32mBePGzBZBLUfvTGuKdQAHhm/1GsyVLoMls2xJD7lzWKuCdjDqr2qgvY6xR0g1FU+HFX+rj+dJV110naSI894GKRGlfIio1fOzVKZKIFukJATWZAImoF/e2eHcNmp6yGVfG0wYeqybux4u+Fl1TI+Wceluq+YGHVxC0Jg+7ItekV1a0xe+0Vw8g== X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(189002)(199003)(252514010)(6916009)(47776003)(65956001)(65806001)(6666003)(66066001)(50466002)(64126003)(92566002)(36756003)(68736007)(5660300001)(53936002)(83506001)(42186005)(107886002)(230700001)(86362001)(6486002)(65826007)(4001350100001)(110136003)(8676002)(105586002)(38730400001)(54356999)(25786008)(3846002)(7736002)(23676002)(189998001)(2906002)(6116002)(305945005)(31686004)(33646002)(450100001)(101416001)(31696002)(97736004)(81156014)(90366009)(81166006)(50986999)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0960; H:[159.107.197.235]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIwOTYwOzIzOlVtRFQxZWdzYi95cGJ0aVB2RldMK05JSGhs?= =?utf-8?B?TmNUZ0FQNWZWOTlrV3YxMGdjWk9hbUl5RHErbXArYUZPVE9IdFBFeHlHS1FL?= =?utf-8?B?SHFYNGRLTlN0ZW9FYUJkUldtV3MxaE9oYjNpdkdEeS96VTYyRmNaY2V2a3dR?= =?utf-8?B?Y3BHVzdSZTBuNEpoRW9yU0s1a0x0L3ZzY054NFcvTDR3b0g0d3JqUXA1NU1D?= =?utf-8?B?RFp6L0RRRWdPN0FZRnZnWEtNNEVLbWcvV1pPOG5TVjBSdHZUQjdyVmRTbE1B?= =?utf-8?B?aU4yU2IzMFVGVXdxbHVBbkt5NmVBWHZRMjVCek5DNTNPbVFPZ3dVSGhQQ0Js?= =?utf-8?B?U2VUOVhPU2NZa0tDaW9VLzFteWFtbkU2dXQ1MUpuVmxFTXJYVWorcFdLQklw?= =?utf-8?B?dUd2eTJOUjdUcjQyUDUxeXdCK3hma2k0dzF1aVBtemlKUEk0WU5CSkYwWi9O?= =?utf-8?B?dDhScDZRZE1GTWh0WFI3NUpVWnJSL3J1aGtHaFNIK2IwTU9JOERXYXZnWU1t?= =?utf-8?B?SXZadUhTVzhpQUVnRkJXNmMvcGFsc0ZzQVFuT0lRVkcyV3NhUjdzQmU3UENx?= =?utf-8?B?d29mOE5xTHRTVUM5V3RHL0E0MjFhYnIxZjNIbUZib3dCY012VUp0QU5wcGRX?= =?utf-8?B?YXVTbDhrOW52U3lwT1MySkxrWFZVdGEzQlJNYkRLUnZPdUpQN1MwTHp5L29R?= =?utf-8?B?N3MzaVNHRjFjaTNSbWhJMGZ1VnE5ZFp3ZzdkOFZzOEFJVE5reEtmWHEySHlr?= =?utf-8?B?UFA1ZWxCbnZ4ZklFd0xmWFkzMGxRcGZGTE4yY0tpNHdCM0s5MnlWc1VvMjRl?= =?utf-8?B?UXJqRkhUY2UyOXlZV1FRNk5yWFEyRGcyWThjR0FLaWM1ek4ybFFXTEtleW9W?= =?utf-8?B?TEMwbjR6b0J1RXAxUUp0L2UwZkVHbGtwQnJ2R0d5RWlDcThsK29KcWI4MDdO?= =?utf-8?B?TlI5ajM3SGIrVkkwRWM0SFRERU84dW5QNm5iNUhzbHJsNy8rUG5PRmpXbHFE?= =?utf-8?B?OEc4MFZ0UXNGSDlCdWRiR0kwcDR5MTNVLzYyK0NPRGZ6VElwZVVtckdNVmxU?= =?utf-8?B?UnovSjVJNGRoSkZWbEh3ci91ekZkcVRWZVFQaEQzZHA5U01VcGJITkJ1VGli?= =?utf-8?B?bXlSTGRKaisxWTRTaHZFcFU1OFBrR1dRanhSdGQvYlFGMTR0Qm1Yb05xQ1NJ?= =?utf-8?B?M2l2blAyelVuVG8wdTdyU0dOcFBuOWxIZnJicW15RHdXZ3NGb0NQVEgvOXdU?= =?utf-8?B?ZUovdGUySmhIWXhHeldwK21qS3VMcUhGM0FUci9wN05TSjIzY0Jlbm9TUkpx?= =?utf-8?B?K0J5SDdubWdEaklaT1ltTmdZVGNOSUxpS25FanJhbGNkTGZyT0MrL0hhdjBM?= =?utf-8?B?RnljelNFb0ZLeUYrdC9PT1pHZlhFZDhGNnVaMnk4UFZ2ek1tRE9YeUVRSjNq?= =?utf-8?B?VWdWNGNzei9yOS9nMzJxZ21oeXM1VVdNZ3JCaE82QUxXdjZaUVBzR3YyUFRh?= =?utf-8?B?aHV6QTNWb1JIckk3MndpNlZnVEp0bThLMjdyNTRrUUlVSTdpbyttSjB2b3k5?= =?utf-8?B?YVd2RUhhUmlkcWkzZHdqMW5MazRTNEw0eVpobjA1bXhpQnRLYUVsWndBRzlZ?= =?utf-8?B?TGhQVmZWS04wdHFQdnA5cC93RUY5ZERXRmNZRHJwZWxUanZZNG1QRGFlR0l4?= =?utf-8?Q?VkgC9yjgSbOTbolnd+SJW2Z23SMUO+u8FveaByQ?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 6:u3ij+/tvd8Y+rGogCfG0P4aRJK8KoIWx5+XyvIf6ga/7eujU06B3EiBl9LAO+FNk7R5Z5XLto88td6Ul5T48UXRgrN5mUbbcO2aJFHr/ql7AU7TkJVswLLAuzIryZqpES1HC7au0l9vleZIRsHXcP+u30vh+ZSsjqpQiMFLEMOoTdcj1HFsR19KF/6fGB7NwJYMBboQUaS1Ie0HQxvshLcNS80VoystO0c0zw9tGGmLpQ/gDQHtKcF8zkMYLnN6LG60jEW24wcz8Rthg31+yqzb4JuwW8cSpNQSSIfQAlmhvvKnvJYZsCeAkF37JHX0ACPdRoegrOQ6tmaiSI7IUbXJHV3zxnQX7b0Zr1cKaVxxuJ+rq+nxAkJ1Y2/12nA8bGBArAgaYPVsRpd17eO57uA==; 5:FlfIeVCci8ln214+PxZvH6/o9Wcv6lQk1V+WB8OqdAqC8jQ1ShMpOeUYMlvFhlGxhYB6fcUasxmwNfjlfejECy8LokyHuyKt116RhOnn0xhXkSApDV2mrMdJWwSC+GaE7GIqS+4PXsOLaTZStr8dLA==; 24:urUIAI2NHJliBBq4rvgul+B3k0Y2+4TAuBZhBzGDD6u2dJKCiwYZowfbvE+HyrA8oMnnAIBioCcegX34C4Px+njvc0MzTyLEAQOzBuqy/vI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 7:fl1X/TYBBWWa7vzdF3VMxSGkE8Ipx9sgF/SstirP05e50M4WoECEg+V7a7CDsjasWaQ/MuPgsNqDvRvoyMVxKPhHo6+EZHtjWhnEEgQcPOMMzl79vST65Xp1/Im7wIDCihE0Xpsy5wRxvf2hyS/w4XnwmNbLNqHbX1iC7RCVNvZF8m43qHvF1B+DL+epU0QXMYkcPFEfdk/Xw1DonJe9MHvH1upj88Bu/rWZvZLIqlg76aruTss2iYrodT0UJuCRzpmfPBCE5iL2jJYxtCPSrxbbc5yPFVLK5fWCtr0cR4ll/qP08yySVItq6qnWs9A8U0i2YKbhswoCPEqJicLShyvJaI4Y4apANCBxFhY2ukLzpsGjEk460rj1VLPuCrBkfbUJidQWAs+wrP91fxhZ06S9UoCC99WBiUwrCu7ixqtjfIUA1wrmE/Hm0Yn1wRLBWCOc9bm5qX4tpu00Umz7WzqVWfoV/xJrZ3IcCm9KAkxlAZMWzVjQ5cJqQf0F00dXZaHFk5F+tszUpyyPWAqwrA== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 11:50:32.8969 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0960 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUyM2K7li5/8owIg773WhZ9uw4wOjB6LFny kymAMYrLJiU1J7MstUjfLoErY3ffK9aCH+wV7deXszQw3mTtYuTkkBAwkfh/ahNbFyMXh5DA OkaJc9+/s0I4xxkl/uw4COawCPQyS0y7tIwFpIVRIE5i55qFUFX/GCUOTl3PBJIQEdCQmPXx KNhcNgEjian954EaODiEBdQl/nQqgYR5Bewl2o/PYAOxWQRUJHb+uQtWLioQI/FyzyoWiBpB iZMzn4DZzAIWEjPnn2eEsOUltr+dwwxxtoLE9c3XWUBukBDoZpRo7bzMDpIQArrh4YW/UL/5 Slzad58Jxp5zdjkrRMMKNomWHyehnItsEk+XzWOEqMqW+N27lAXC9pZofwYyFaRoOZPEnT2H 2SCcHjaJA4vOQR0iI/FkxXpmiMQBVokrzTOYIA5JldhyowWqo1NQYkLfUqhzr7NKHNw3H6xK WEBK4v2Ok4wTGNVmIXl9FpLXZyF5fQEj8ypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwLRw cMtvqx2MB587HmIU4GBU4uH9YDs9Qog1say4MvcQowQHs5II75u4GRFCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MCovD9L5FrHH6bJDvMDtZdvigkrX L+h9Z/y3py1txfanL13uW2hk5tjbtX+x+au1JGhysE++dUR4zrbvagfFeGI2y+meuFB3TlHe c4HlqY97Jh5bv05RpNAhuvuE8TSbj9zV/lvKv5s/6ZRoC4jYKjt7qfzJ1XG6DUcTeCx/Ll9n devFmwcP1ZRYijMSDbWYi4oTAYWgTmgHAwAA Archived-At: Subject: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 11:50:43 -0000 Hello, I have two modules: module modA{ prefix modA; leaf leafA {} } module modB { import modA; feature modA-support{} leaf refToA { if-feature modA-support; type leafref { path /modA:leafA ; } } } What I would like to achieve is that IF my YANG server supports module modA then modB should have a strongly typed reference to a specific node in modA. If modA is not supported as indicated by a feature, then I don't want that reference. The if-feature on the leaf works fine, however I can not put an if-feature on the import, so even if my YANG-server does not support modA it must use it during checking and possibly SW build. What is the reason that import can not have an if-feature substatement? Is there another way to achieve this effect? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Feb 6 03:55:12 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A7129CEA for ; Mon, 6 Feb 2017 03:55:10 -0800 (PST) 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, 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 h9xs0tIb164q for ; Mon, 6 Feb 2017 03:55:05 -0800 (PST) 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 76753129CE0 for ; Mon, 6 Feb 2017 03:55:05 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id AC0E4761; Mon, 6 Feb 2017 12:55:03 +0100 (CET) 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 9LouQg-YeCsN; Mon, 6 Feb 2017 12:55:02 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Feb 2017 12:55:03 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67538200C1; Mon, 6 Feb 2017 12:55:03 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dC2L0O3vcmUE; Mon, 6 Feb 2017 12:55:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC612200BD; Mon, 6 Feb 2017 12:55:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E17563E68751; Mon, 6 Feb 2017 12:55:05 +0100 (CET) Date: Mon, 6 Feb 2017 12:55:05 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20170206115505.GA92486@elstar.local> Mail-Followup-To: Balazs Lengyel , YANG Doctors References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: YANG Doctors Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 11:55:10 -0000 On Mon, Feb 06, 2017 at 12:50:24PM +0100, Balazs Lengyel wrote: > Hello, > I have two modules: > > module modA{ > prefix modA; > leaf leafA {} > } > > module modB { > import modA; > > feature modA-support{} > > leaf refToA { > if-feature modA-support; > type leafref { path /modA:leafA ; } > } } > > What I would like to achieve is that IF my YANG server supports module modA > then modB should have a strongly typed reference to a specific node in modA. > If modA is not supported as indicated by a feature, then I don't want that > reference. The if-feature on the leaf works fine, however I can not put an > if-feature on the import, so even if my YANG-server does not support modA it > must use it during checking and possibly SW build. > Is this not a tooling issue? A tool could determine that the import is not used if feature modA-support is not enabled since there is nothing left referencing modA. /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 Mon Feb 6 05:18:35 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1C7129D71 for ; Mon, 6 Feb 2017 05:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5_rDScQA7MCo for ; Mon, 6 Feb 2017 05:18:32 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CB202129D6F for ; Mon, 6 Feb 2017 05:18:30 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 5AC261821394; Mon, 6 Feb 2017 14:17:41 +0100 (CET) From: Ladislav Lhotka To: Balazs Lengyel , YANG Doctors In-Reply-To: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> Date: Mon, 06 Feb 2017 14:18:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:18:33 -0000 Balazs Lengyel writes: > Hello, > I have two modules: > > module modA{ > prefix modA; > > leaf leafA {} > } > > module modB { > import modA; > > feature modA-support{} > > leaf refToA { > if-feature modA-support; > type leafref { path /modA:leafA ; } > } } > > What I would like to achieve is that IF my YANG server supports module > modA then modB should have a strongly typed reference to a specific node > in modA. If modA is not supported as indicated by a feature, then I > don't want that reference. The if-feature on the leaf works fine, > however I can not put an if-feature on the import, so even if my > YANG-server does not support modA it must use it during checking and > possibly SW build. > > What is the reason that import can not have an if-feature substatement? > > Is there another way to achieve this effect? I'd say the server should in this case include modA in YANG library with conformance-type "import" - the import in modB should then work and modA needn't be implemented. Lada > > regards Balazs > > > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 6 05:45:57 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26692129D7C for ; Mon, 6 Feb 2017 05:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 rFPktL2SzzCc for ; Mon, 6 Feb 2017 05:45:54 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 50146129D20 for ; Mon, 6 Feb 2017 05:45:54 -0800 (PST) X-AuditID: c1b4fb2d-fb9fc980000059d1-58-58987e1077af Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id C2.52.22993.01E78985; Mon, 6 Feb 2017 14:45:52 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 14:44:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UE+3pbmqC+s6hGRqkFzYRA0nKqp5qSlv3OUDVNmqgyI=; b=V85bzyrG03rgkZRBSG3/GNfkU/Q48V0mV5jLid3NfaUQDe8m6uImw4Hi2eyBrAag4n38Xf68rhcVNwlL8ahO5LZODYimG7nhWpQpDx6cUvPmOZqSW1+id65lT1piguXw4nvawi4p794Eb4YWc59q9F9mU3RFb5mKT2vVAx5evck= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.235] (91.82.100.59) by DB5PR07MB0951.eurprd07.prod.outlook.com (10.161.200.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 13:44:53 +0000 To: Ladislav Lhotka , YANG Doctors References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> From: Balazs Lengyel Message-ID: Date: Mon, 6 Feb 2017 14:44:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1PR0701CA0045.eurprd07.prod.outlook.com (10.168.191.13) To DB5PR07MB0951.eurprd07.prod.outlook.com (10.161.200.146) X-MS-Office365-Filtering-Correlation-Id: 564d6d8b-a035-45c3-36db-08d44e965489 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR07MB0951; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0951; 3:9+8l/QzOnA/uu+F/nOEY3gh0liNK4f8S3AAju97FLetUZldtDK06RqakHPjWPtVz5si8nEBeUATOPvFuJ/xLE/0wZ9zbmKEYncjIy2kymvlWnWA8vdhCiacbsRtdGtiKUCVai30CmXdV5oK1NvjAo3qojKEbTZgUIbqGlyfn+elZWoj66G93lZrb5OlkS5oP/FUbKr8ysHSc6YHhPpw+muPx2WiO/LzVcgoDg3g7UAVh60iXD5Lrjx9/X1tttKa5nTd8gGsudZKXoHx/gtXzpA==; 25:WHI2ThFy7dq8td8vSmZQ8arvV3I7dSmg86Ozf5h+J5tnlFeLITVtsaVO4GsVMscouN4VHahNNY9+MnwNoz/WezMaqI6HAlPuNuCnb5ExZNVz9f2FrL/hMGbdhxOsz98DT3GO7t/VVD4ja2pL2NgNRSOlBmRzXBn7KzaZXVtbjUmELZeqhXzGgUHPVvDAYGblGuEXCoUvXI2pdCqllyCOb0Xh3XgvwHW0BrF8Cm8lKPZpNNwTm5ssmeXWNh69qBNWuHhaUxIbz8e9kPojjxWYBMMOO4eOMw1ETTu+U6/10SQQFQEDEjNJBtl0srSHAql6fsAPrq+S3NzoW0KqpAOvl5OJ6gbm5zUmmrzIgq9+EIMJ9xPFGThaCGBo01BdpsACvCZ6SnxMRwoNkXg05PSsKxoS7J2FeuECQfS8OzE1JdyZT5NDsBM8jCDHS4kw6th3y3y+AK9yPPa1SWafBQT0CQ== X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0951; 31:ZhfoZ4EJICA0OeGg+E5wQWQg68yZCqyLRm1YM+L71VNEmZYrKVFs6/+nETwBlj2na2k/nCfgZ7SnP+T91Jj2/GCfmM0CRmMadtx9gjV16bXtdF5H16JBS4WgAumkL68Sn2yv162N0/tf3VDeixPHcHXm73jCPWVpyT5JI0UQNveanat6/OziBB43cCWn2fI7JpGw3zsat8wEyGiih2rEJPneqaZpkK0pH6jxxQXbXGDIJ/TSQtpAcp/rlF/bXJnqJuolZJiG5cTPI5Q9KkGQR7Jmh7jwuSdEIkbK4nTCbvY=; 20:mXN0Y53Gwl4jf11eii7U9DjetDVuHu5yxL4JsEjPWIOzFlmtNVBZSmXjR7FM+KRJ1eCdI04T4JOHNNzk26wJ6aC15UPkMKbuok3g7TCLt6HQX142dIu+MmVi/KR6EnHXjZBLpm46qMhD4VPHssyLRMYU5GRjZku+8P2Vd9zHmsTSwpuQIGItEj58sHXOuR7Fgoi1bEvGtg1ORHyBV6UaGObtj6SKVyc9DDUbGu2Ta4sJh8cdO2hMl7SqQNSEEzTnhpCflInG92w6GrP71076GrYcTuD1pCxGOcew+P38eLdpR/yHEw+vqqujcVGfNJ3p8HMAEvEAyF0cEQDK9eRfY1x9bx5oJ5BIXHOhCa88lhCoBBfOmtmU4AjinWmkMoXvG4wJ5MM749gw78qXWShMwRCk1mrPRnsf+srdX2V06V1Nf9/nd8ZVMEeL8PEmU3gwSnOhMqNVPcFQ+gulBh64fBjBLL2HzmkJP70Z1ULR5ZgHMkdtVjY3OnNuPs/cHl4w X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(20170203043)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:DB5PR07MB0951; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB0951; X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0951; 4:StfJs3fOBI4QLRMPqLVbqFbuxpbugedNZgtKYX1fp8Ux7OE/o4tP8KF9ejCOh0buA1rBCPaECpfwIYae6eIE6MsHlKI5y9atHE/rSlkRgPTwsBrfwF7mJjJEQQswx7aDab8W5pCNMIs+COXjCkJO39xrzP/NNhgwHHWHhYrQ54G6im/DHWwndMIXT5yzhLEY+ls50nTPvS4pGi36LVuTRg/GBGh2g5Bs2B2j+5Wi6a9HGRSZH5MHEluZk2QJzTX5fHTdlOyZExvpoiv2u+CS3N+mMd0KWlC1S2/mmU+R/twRuOuuInhpknJldRedjsfqX2T3PSSfMkaaZxJWB6a5gJXy5n0wn3EbbUCILypztaFcPJhApMEvWreHRPX/oaIxGHGYlY/siJwdd5uPA440quTmyKpx/VLQtPuLW5ItaGqAXXcybKKI9n/UoF6sfJ3h6w1hjdSQ/ZtdDFZ/8if0yKw82QCqMC4NJteL5YfdRUbjV1tjg7bKE5LvPe/IjJwMpU1S2hqGYpW8xi+VCACz6CZO6wh7qtkVw9Al3zBD0tekErPouTR7BxnDUukFocrSRGNuD3hyutauAfQkp18PCPhgaUZMnvJlfMskso8eoDyIuDHRVM/lCB+63lC382/vSGgUzAHpoeDOfz4DX1+Op1EOsbM4Iz8kKF7jf9t+abet3OeB902OwLuxlh+Dk2GWpOwoXMoCUlbIrsQ2y8K9YQ== X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(199003)(189002)(252514010)(377424004)(24454002)(76176999)(54356999)(23746002)(50986999)(65806001)(66066001)(305945005)(47776003)(7736002)(53936002)(65956001)(2906002)(4001350100001)(68736007)(6246003)(97736004)(53546003)(5001770100001)(101416001)(6116002)(3846002)(83506001)(50466002)(65826007)(33646002)(86362001)(6486002)(38730400001)(31686004)(64126003)(42186005)(106356001)(105586002)(81166006)(107886002)(90366009)(31696002)(81156014)(92566002)(25786008)(6666003)(2950100002)(189998001)(229853002)(36756003)(5660300001)(6306002)(8676002)(230700001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR07MB0951; H:[159.107.197.235]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; DB5PR07MB0951; 23:1+tgdZ6H/TfWHDXMEFNcCVVIh2oZ5erCl6izo?= =?Windows-1252?Q?4jDTOshA7AY+fN+CI/t1UKJuVd6T0uCaqrkg3MJ3lk4tAtJoHZtjJAry?= =?Windows-1252?Q?Ta6ruvzixmPaFxs1teaocHADez2JDYmT90twrtGX0X6OYCgjEp8RNDki?= =?Windows-1252?Q?6OnYRJmGHNn/ccGEFvcHRWowhgGe+OAPOH6d08mFe4TDxgLsI6x0hdDA?= =?Windows-1252?Q?gZsQpotB2TGtQ8q2/AXFHQjsIRdZ/BV9dt7hyqQIK/EmDKOAqozZardf?= =?Windows-1252?Q?oSUwjIk7o1vZY5ghN+EJqlmfognFC3Ht/2y0WpY2BsO+yXuXEa2GqG3/?= =?Windows-1252?Q?0qWVLY8rkn7PdkeeWaDKVXYTuTaSLG76IgnlY9l5E9fHr3CvwMt0zGrJ?= =?Windows-1252?Q?6/r6vh6N894D3kq/PFnWZjJcB8P9w4bLPTNxbISluCnp30E/ZeBSrq0U?= =?Windows-1252?Q?w7W/akf43CCFzCSTUkePtZAlmV910kaTffhxeLI/eorE6NjOmZccnJg1?= =?Windows-1252?Q?r7qTZLGhEuoetw0MfGpAmcmcnQb6fQQD1ydEl1QMkI6R7yKMeJ5TAIKh?= =?Windows-1252?Q?0AfCZnd30YlpSVl+o+5BX+pxqLoeS7xyN5Wrg8lPcpaDE/C1s531ZcvU?= =?Windows-1252?Q?XEVtPzAOXJ2uFLVgqsu5BTmrC8e3HBMBXfhmxKSV/8Aia/IsL9kAMX+L?= =?Windows-1252?Q?Pc8xQRAZ1SuSTtCVNQKVZGOvhtfUMRzbIY/a1qSOgFzIk5ge8+IGV8W9?= =?Windows-1252?Q?S/6IHd+o+FihW/SJAxSBKgaTOqMVU/ZSRDs4H9deOKYkZK5HG+iBieFS?= =?Windows-1252?Q?oi9Q2BbOYLTgrG0RiqxCx8CpYvJCydxBUj2EkEi40tXWFOp7CZ39jCro?= =?Windows-1252?Q?IqMX16ikGXIO3UFrYX3Dp000bWHyRhrQvtN9hc6uAOBCIQyL+Ub8+0a8?= =?Windows-1252?Q?h2NDxhtPhSzqYmx/kxOoJw5gYComabl0e6dTz2aQPRWo6OT3nW2AYEIc?= =?Windows-1252?Q?isRmS/ZlI5ftPM18AaiZr5yZx5Sye3w3Onk39sSpBqDNMj2Gr9dlhsPe?= =?Windows-1252?Q?kacOEGH2tI6q7W5EJFH+YZH6JQFh9hB2xjY02LoNN7eXg26UlZqVCiOE?= =?Windows-1252?Q?3jNt6FWNVtP5+ERMhT8Y20noc+SeghuhXXJpH90YrAN6PjAYq0Amruwq?= =?Windows-1252?Q?oHTImPeGOx+4BAWJ+SGrDKDk8euLSdGMWJJbWymc2Z95JgJjUkrw10ln?= =?Windows-1252?Q?KGOFgD8w2sfZYRWZA5m4KFpaJiGFGVGZnpixyBJMlQfMcKb3r2XkycJC?= =?Windows-1252?Q?x4pflrmv1KjwUQyoU5q/RbtU2mhbt00GU6+gDd47WVc2bdbeiNeIAsuV?= =?Windows-1252?Q?hsZmrvPkbFE83kG66hbopJUDAMzqySs0sjffgWoOZX4e9im0/tJbqKps?= =?Windows-1252?Q?P1LT31lVv0H+m38VBKUnizfL35PdegNCBpOryoHmmiJxwq5J8cdEC6di?= =?Windows-1252?Q?/4PrnGIOmVwC2HeBEQiR+QXtLfqQXgcx6pj2adcgymdRqcHoQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0951; 6:quv2U+rYAaQtTYQgrJGz+2G2auVyScarFzMs8zLfS5SitcR2ODGfFgULAbBOV5hqQhViGutX2thlBeQrVtENeizbyuEUS9XZBoHWNKGRE12771ISSBXtti0dLEj5MaamppQ5pvF2M3OjeRHFggoFEwMBNxXeqGFkc/eRME2NhOlIoEfGqvlfcEGG9wkcU0SKClSP4+wiskllFba03FogxjY01th+suVsr9W+rPUOscqNoyaznb8eOsH+Dk2pMtYg9EPmeCWCOfk3gktRQod/sG+cBRzZiTZRRGxkpyJ3Cm6OwHGayYskTDpfnbO7IA3YJfJhusuHkcOAJ0MBvyMrRg5AmaZ/2UFEJH3D23tF9aZVGIdxSpafgkBGFrzhRyLMTMqPWWhGyLA+JZ4hPm26Cw==; 5:MH3JpaPsGTjxqXqX2HQMEXWTRv8LeyB2hlCVxBciMfhmnGuWUyg5RogGzmh5kYYSM2Wn/Ck0mn9chcxJzfilP5/FYOTCkz7ncgtLGmacZv4nkT3kN0JjpSibl5+XIgeXHVhp6+Ao53t5ZIIaRw+k/B1N0kwlohWZuN9lYCmoVQU=; 24:r6xPRarT6x9tkt11ybvov72gSVjmAxtApghwXHC/vxISe8+YSzLki7IYqxRjMaHAQyiYlsUny5rOuvpDIJpP5/24BRA4oBla/eGCADeqD2c= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5PR07MB0951; 7:pdnDHJZeTmn5bR4OvH+bVA1GkfPyAtqCoZgOG78ONF1p4kD153w9vl8K46us9B47+Gw7538WV25R1qWQa8fBxPSu3L6LLm7IqHTH+Q+UgQVV6ovNTr5LceJHKETrmwr3egrKI1ApnhtjRBcWeDi7nPWm1bt/niIdXsBqwCgTv98RYOh4PCo4efJVGFpLmK9a7ixtWadwh19bujCHdew7gqfQezb/k14SFtnlFWTQic39JkZSfr5mvGgqB0FzSfq+GDRuxrVeFvWanIvnkM7U0CiJGHfim0q1TYnxGju6RUP9zNJ3SftzzkyofN7GUMAxfIfG/oFwUWIwBaswe4eYRuU4ORFD61KqCNW3628JPIaInD3oZrrorBh8j1KbkC7Rh6xy5D3D7P5tEsBkaWzpzCKlQ23oLcURv5sjYKD+y2U379Rv+QLySGe18g7l8Ppa61DzzIdB6vrtuWJn3/cCddQyls9sgWacNyCkr8CP+2zPvOVCnKt4XTfOW84qyahlnmiv9QAwve/BCGPhcvCJsw== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 13:44:53.1422 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0951 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUyM2K7q65A3YwIg5kbDCwurJrLZtG36wCj A5PHkiU/mTw2Xb7DGMAUxWWTkpqTWZZapG+XwJUxd+YJpoJLAhWTtmxka2Dcz9PFyMkhIWAi 0TDvDmMXIxeHkMA6Rolll89DOccZJT692cEOUsUi0Mss8eSlBYjNKBAnsXPNQlaIon+MErtb 9zKBJIQFrCR+LWxnBbFFBDwlnq1eDBYXEkiV2NjbARZnEzCSmNp/ngXE5hWwl7jzqp8JYoGK xNkHTWwgtqhAjMTLPaugagQlTs58AmZzChhILNjdDGRzcDAD9T7YWgYSZhaQl9j+dg4zxDcK Etc3X2cBuU1CoItRon/1UWaIGzQkHl74ywpR5Ctxpms1O4zdvn4pG0TDCjaJF7PXM0E4T9kk 7q65zwhRlS2x+tF8qBXeEu3PLrNDFC1nkmg6dh2qvYdN4uq2NiaIKhmJJyvWQ3U0sUkcv1QI C4stN1rYIOJdAhKbV3hOYNSYheTVWQjvzULy3gJG5lWMosWpxcW56UbGeqlFmcnFxfl5enmp JZsYgQni4JbfujsYV792PMQowMGoxMP7wXZ6hBBrYllxZe4hRgkOZiURXoHqGRFCvCmJlVWp RfnxRaU5qcWHGKU5WJTEec1W3g8XEkhPLEnNTk0tSC2CyTJxcEo1MHbxdrUrJ8WtV2tc2hiZ of2F+VXrCiOP6OUf/X+p718m1XXza27ilc8VjrmnJ11z7515Z9Vy28bSCf65GZ8qtxpJ3WuZ mfzvAKOmnukzz1l6btzP5qjov5f/8+tt6wTbJKWZt7jtQ9+9yPl1+2jahhl+adK/vZn//v3/ aVaHr/AVYYU5s0r0g5VYijMSDbWYi4oTAdziQjIMAwAA Archived-At: Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:45:56 -0000 Sorry, but adding a module to a product that we explicitly do not support it is misleading, even if it is for import only. People will start asking questions: if you don't support it why is it there? People responsible for product packaging in my company already rejected that. You can do hacks like creating a dummy modA, but they are hacks. regards Balazs On 2017-02-06 14:18, Ladislav Lhotka wrote: > Balazs Lengyel writes: > >> Hello, >> I have two modules: >> >> module modA{ >> prefix modA; >> >> leaf leafA {} >> } >> >> module modB { >> import modA; >> >> feature modA-support{} >> >> leaf refToA { >> if-feature modA-support; >> type leafref { path /modA:leafA ; } >> } } >> >> What I would like to achieve is that IF my YANG server supports module >> modA then modB should have a strongly typed reference to a specific node >> in modA. If modA is not supported as indicated by a feature, then I >> don't want that reference. The if-feature on the leaf works fine, >> however I can not put an if-feature on the import, so even if my >> YANG-server does not support modA it must use it during checking and >> possibly SW build. >> >> What is the reason that import can not have an if-feature substatement? >> >> Is there another way to achieve this effect? > I'd say the server should in this case include modA in YANG library with > conformance-type "import" - the import in modB should then work and modA > needn't be implemented. > > Lada > >> regards Balazs >> >> >> >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Feb 6 06:16:53 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2914D129DA4 for ; Mon, 6 Feb 2017 06:16:52 -0800 (PST) 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 qdis3Cq2JTk4 for ; Mon, 6 Feb 2017 06:16:50 -0800 (PST) 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 330F4129DA3 for ; Mon, 6 Feb 2017 06:16:50 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id E067B60101; Mon, 6 Feb 2017 15:16:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486390608; bh=GgvZgLolt2wFLcKUNjLIv5CEHRwMtUNbCKCHHZ/Iasc=; h=From:Date:To; b=Y5PTdaQxfcRZPtss53dyx9sqfDBAWvB/PCON6ScbGiHB1e013Uof8drhCewul+Qpj 2/xrtv7BfzyyAF3q4gEe76duecPDKaR44kAb0ee7UZM72Teax3Qx2oEcEOZh0EMJU+ ha1mI6qE6T12ON26AZF2gMyGjG477vKnqNFouobY= 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: Mon, 6 Feb 2017 15:16:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:16:52 -0000 > On 6 Feb 2017, at 14:44, Balazs Lengyel = wrote: >=20 > Sorry, but adding a module to a product that we explicitly do not = support it is misleading, even if it is for import only. People will = start asking questions: if you don't support it why is it there? People = responsible for product packaging in my company already rejected that. It is somewhat unfortunate that the "import" is overloaded with several = different functions. What is needed here is just a mapping of a = namespace prefix to a module name - no import is involved. Leafref paths = could have been defined to use module names instead of prefixes and then = no import would be needed. Clever tools could probably figure this out, as Juergen suggests, = although RFC 7950 says in sec. 6.4: The XPath expressions MUST be syntactically correct, and all prefixes = used MUST be present in the XPath context. Lada >=20 > You can do hacks like creating a dummy modA, but they are hacks. >=20 > regards Balazs >=20 >=20 > On 2017-02-06 14:18, Ladislav Lhotka wrote: >> Balazs Lengyel writes: >>=20 >>> Hello, >>> I have two modules: >>>=20 >>> module modA{ >>> prefix modA; >>> leaf leafA {} >>> } >>>=20 >>> module modB { >>> import modA; >>>=20 >>> feature modA-support{} >>>=20 >>> leaf refToA { >>> if-feature modA-support; >>> type leafref { path /modA:leafA ; } >>> } } >>>=20 >>> What I would like to achieve is that IF my YANG server supports = module >>> modA then modB should have a strongly typed reference to a specific = node >>> in modA. If modA is not supported as indicated by a feature, then I >>> don't want that reference. The if-feature on the leaf works fine, >>> however I can not put an if-feature on the import, so even if my >>> YANG-server does not support modA it must use it during checking and >>> possibly SW build. >>>=20 >>> What is the reason that import can not have an if-feature = substatement? >>>=20 >>> Is there another way to achieve this effect? >> I'd say the server should in this case include modA in YANG library = with >> conformance-type "import" - the import in modB should then work and = modA >> needn't be implemented. >>=20 >> Lada >>=20 >>> regards Balazs >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 6 07:36:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B78129E7C for ; Mon, 6 Feb 2017 07:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4EmSQJM0RjLG for ; Mon, 6 Feb 2017 07:36:27 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 6D72C129E7E for ; Mon, 6 Feb 2017 07:36:26 -0800 (PST) X-AuditID: c1b4fb3a-bb7cb98000005e23-39-589897f88c27 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id 5C.99.24099.8F798985; Mon, 6 Feb 2017 16:36:24 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 16:36:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UOvMEHhwkom1+qQVFK3ueMUH5/g7JXufuVimqBJWaS4=; b=ji1JuGPsvf1RAkO2f3wCJ/oqhuRHmAE5oToDif5r8A5bCWC08AT8RGH8Jaj3Q5EhRIO1SGnVVY/a4NWypusw+1eXUUo8hVbtAFxjnpXuBtxSYi2f3Q8aOeDpPzpweKchDplfIONHCWCf7BufF43QRFPJ73DE6xSLs59DUFUf8lg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.235] (91.82.100.59) by VI1PR07MB0959.eurprd07.prod.outlook.com (10.161.110.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 15:36:22 +0000 To: Ladislav Lhotka References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> From: Balazs Lengyel Message-ID: <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> Date: Mon, 6 Feb 2017 16:36:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: DB6P195CA0014.EURP195.PROD.OUTLOOK.COM (10.171.120.152) To VI1PR07MB0959.eurprd07.prod.outlook.com (10.161.110.151) X-MS-Office365-Filtering-Correlation-Id: f76dbbc7-00e4-489e-43db-08d44ea5e7a0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB0959; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 3:3RBIIRjA9nfw32O7eRBGdZFJ4IHkoliWrnkdzJQryWEN8bSTiFVhndxh79CxaIaM81FoiaeWafUtzv98PEK1OxGwEy4QG9sY260YKPc8VnCjgjm9qsuNqgCPykXu9MB8vxDeaiXBofho/nKbeoIArP08zUGymj79ydPLT3cFaDMO2txBLJPl1I4ekRgTEX+gYAP6ZWjFBYInf9T86Oh4SOKLlsSK0j2Tk6BHzWiIHauYa+COxZWJQYg5WvGl9ACRPCMcLMIO2cnUsTGqFqcwXw==; 25:JzOxzMxcKNLtxJmahoETEpQf6fE4WlfZzhJ/F2ejqegMUnt4TskwQ+UAhwLYWAMPD3GqQjqoRp5dLQI8fyZYXPbkdH70NGDsG3BP4oMFFeFdxkUJ6/xsEKEmf93zg7xRzE9OnxE3WNcX/NlLOFLuAdcUmGK5nLKDA0NX0LSj2eb/3eGbrBwG6oNeb9HQyLDCBAp+JvnC6B4NVqi2hSK7THMUAUlY+3eX6EtO7CNE2zEmaHkVmVy+Z9Q0InhaKWgnnyuVZan3JC9RCAg6Cz6g0zZT+H/ytE8KRLrGYl+Zbd54bC2ov1JBTsdmMKNmgK90OAC/0zJZimfmCug+4v5HDiIG5cUa43skQl0khWbw1LoMK78Zc9NrH/zfac9ojTGntPzUsQuWsZdoZ6zoGQwzyeA4kqr6LljOZNskTnAm77Z8we/XGrPMHPwuWqWtc6IWkO2y82k/Oxd+ZNctc3cvUg== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 31:/wlhlG1Xl/KSGsehMsB2snq9O8EOHARBG+CrOaZIVGQiRZ9hhimqwfOivCSuHYqftKZSDdFYb29ZloJWXKabAWlcaiNwV/gZ2BpdijONJN3o1b/K+17P+9lFw9NRvY6vkE4dR3EDw+6qworuMWfw9fnb8omtSkO002NIutLlTz9Bnnd7gAlh8GEZKzu5d7x3ndGjWGlGZaslIyNk69QwxmK/5czf1Ud/Mw4622vqVjzssh3CtMq21/wL6kvmmeCPfBO/XfJonZKWUIYskVO94w==; 20:lnYF6pJpG9Q7WvI3Pe5+ZKiqquqFj6+Oc+N+y5sOW4/bOL6kKaohqYMR/8c7sHWIjA9OJAMaNKpSnqPCDb8sgPg4dlzXpBobGMm36XuxV7kBFNrDFC2Pf/YdiZe/r23WPBpSFQJTGRuItbDrBeAwprHyn8w8xBhEvcBpPT5CCU9ERotj3y6JwZJ/oeDljHT2gfsFwcYFFu9NNEODZwIahEJLNZdJ4cPycYkULymamdFx4vR0XFv/zit4jzfTgClfW5lrH7aHu5ysVGqrV10Cxq6gw6N4dDsmZlB/OHHz5DeGrKy3AnD+HDMqWW8SevM3VpV90BpNs6PG5jGiqjnQHnyx7qqz89IEF6V1DQ1OQ00aaWLYgLY+xyU8wTKBUc+gSBlkbOKf9H6sZFKhS/H8A1UXFvJAs7PERDbsu9H7RYqphCgjyYEVOi8KhsFtjAmgujfOvm/U5Ya8JxaNRfElQHvIDQu73h+FyU9cY7JgL3icJ+qMnXEXz/9611xVoeRh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:VI1PR07MB0959; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0959; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 4:kjPh+byeZva4nOiVsi+SYC7GsIn0J3xQp6e7LDXB/yHUYzWKmt+tqHhJ/Rcyu2kKExv5zd1wZpkCy9wNMKCclgC1+pbYYF0t+sAH5Msd9p+/oK7TNWqyKAuYBScRMR0Zy4dWc7Tb6X+LGp9E8ma4Z2ULWVCB/nDxdbktr9ChN1go5hyjQeOTDulOjMbMNHwNCLb0eAm60UL2Aganj1WkrGPuU8FFQ4M+Jp9C2yanArb07gXCCW4SHf3/lQqIppUqYytJMnwIsboNDyqfTgoL6US0Wt8kpINQyGsZZDsyks5NPf/XL/4g7Ri7rxho+Da841gEmuX6XlNTAYruu5aAiB0OXPgtZoWP+3J+YjQUJ6AErwZ6VdRifINjLTP2CFN/mDJZkgiJr+OHAsOB3efJILnVfeO7OIiDNBSeL4mviCcXLAY6K8g3EI1pCd+D+RewjEXUIw3hWdssI3rHu5ixnEsJA0X4Wvkc35cxVEb+IbGxboTnOqOMorC3/SXbNV7+9H17CjubTK4t2ViOAOVrHvyMAWLbs3mipJ4IyvlViQT59W1EPhUhL/2AIunGpEW05cUqIJAifKfcOHZ3QMC83+OOyxbnKp8DXqlsp2FtxxC1Oez7ct0AP+l4/exvNgXheeFRUXFpcHQ1jeO0tz2eQmIaccDTLsj4+qJaxFuy71gNpZRb4rGkGSS9Cku1+b1Jbq8liuZnoKjqi2c+ITTBXg== X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(377424004)(24454002)(199003)(189002)(252514010)(31686004)(6486002)(230700001)(50466002)(42186005)(4001350100001)(53936002)(50986999)(31696002)(76176999)(54356999)(101416001)(90366009)(229853002)(38730400001)(86362001)(105586002)(68736007)(106356001)(65956001)(65806001)(66066001)(64126003)(110136003)(6116002)(83506001)(92566002)(33646002)(3846002)(65826007)(5660300001)(47776003)(6246003)(7736002)(53546003)(2950100002)(36756003)(6666003)(6916009)(81166006)(93886004)(2906002)(305945005)(97736004)(8676002)(189998001)(81156014)(4326007)(23746002)(25786008)(6306002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0959; H:[159.107.197.235]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR07MB0959; 23:gp/96GJzS1W5BcjjX4i8WfBtSd9Vk+tzRBAkW?= =?Windows-1252?Q?qQmcfK79M11TScxXlf+fY7PqMrbPosceloiEmS3sxKP7gdesFtZJ+e+S?= =?Windows-1252?Q?wRtsrJaGTNccvBTSsfH2f69Gqjig41rVgjscYb5fUGOHN6XD9IrCvuIR?= =?Windows-1252?Q?n+URFVNTv0XgpXW+O3m//ff/ADoXN++n9vpKzgZw32xIo9ZGwjpkikqJ?= =?Windows-1252?Q?PTWD/CkRqmGbDSqAR53mjpu0YEr89ANRzWMnu3Oj1oefTCGWnTNq8IyJ?= =?Windows-1252?Q?+/kK+dCxTww3Ge8hnvD3I23OMJd2rXgyCXwbP3KN8Nh3LrK1nLy49vwd?= =?Windows-1252?Q?y/oKej42p+hDIdhz/ju1rAns4UHM7+ki6/x9ERVH98WZBe5tySsiSoIF?= =?Windows-1252?Q?3nc5wWF2RHpcnkOV0bTPfQyMXOkMykACQuXWDGrNDGUUktKnfV6orpdI?= =?Windows-1252?Q?pC8r7fXT4vSqvWz8RfOYWugc0UTkDZultzAgUVdw+3vgpon79KjQ0A95?= =?Windows-1252?Q?cS8m0H2BU8/2inhynt2nbo8dMc2QDDVFgBJ4uhHs/HC9XkHE2UPULm18?= =?Windows-1252?Q?aPhczKyN4LR9mREG2fzrc3+y99A30GMYTs2bStjQO8CJHlz/7eV6X7F9?= =?Windows-1252?Q?edceNdg2JhXbU+PQWjRXesME70sVpVrzCwG8RvGl+anutVOm1KIObMU9?= =?Windows-1252?Q?mEVyl9tWwRmOMN6YO1udfgWoCekkc3kjATF0u1QIDVvo+KjPzoov5Ucu?= =?Windows-1252?Q?AcMcNZxODsF12VfstpxGcyRxQP4opj3pd7KzeKzShmdqBMJH5+0heuT9?= =?Windows-1252?Q?Cwr6RytiRxbXLskRcua8xrKoyOdLOTF/xg1qToVDNtndmA+qXcFqjCIP?= =?Windows-1252?Q?T7Ddvyfg3Gj4/IBQLNQEk5bqQtR+vDxA+YkSPUXQJ4epvYb67ltb1EF2?= =?Windows-1252?Q?SqdouJYLCjF/YpQwxF8cdDwgfiuDaCXTxDsoieSNM2J71jrG3c1M86CI?= =?Windows-1252?Q?SBT8eC3BLeA4E9QcKSGPTHD0rAmURO8sT5MmPSTzbIZnLLcQT9zjedLa?= =?Windows-1252?Q?hIAgBoqMphYvj4tAQ/6tjJN9RY6cAdWuLK1Nnn+SrdniYIhH8wdr3bxw?= =?Windows-1252?Q?GnEBIJqvMDu5LPGp4TG702KM0gT50dLeHovKoEvFhKmLjIzxci/8hUsv?= =?Windows-1252?Q?bvApdzuUI4UfYnP366lybWXcBpzfVGps7Ipkx9KRcLh6Bi/eQmwGaJzd?= =?Windows-1252?Q?zJv1eJJbl34e/kZ4nrY/ZwOi/cYt00+xJOvfODUV8W4ZLPlLw8Pu/vDa?= =?Windows-1252?Q?nMsqi6wCQ/mkiIye4dLWAWd6GIqwBWOqmjI2dBxV3OfO6tX7QK3jX+13?= =?Windows-1252?Q?BECVarzUpMSF4LmGv2Q86yg5yfU+4gY7xyU/yvgASzWol7mNkU6dHRar?= =?Windows-1252?Q?eeTcXbqQjbSXypXktnaZdA6ZzL6I5aLRjiK91YGqciezYmSl0xOlOJfl?= =?Windows-1252?Q?hccCbulVHwBcVCaBfCuaRX7pz/pX0osVCncARFBPg9wVNt3HHgvo5fVt?= =?Windows-1252?Q?RFHGd6vMqocY/va2VVYBt1l0Mq3CL9eR2Kn?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 6:a7pUqmQsTR9oVW+akPnzZSpi6d+AWeh4DYs9te25sUxnq1xA4FD+EtbcSJHr6Eq5nIVPJkjPEC42W+Txau0k3if20Z/pUp9eO6NyfCRyufkJzb+jiahU0zwS/c8mE0JLGnXlF6ClNThL05OJBAyYZqeVCfTw6WR9aU8seh/FQMMlWKd64DxO5xM24WkcgeW6yaXnPONUz2yqlggfSpvLURm+dtmMW+1BkNz8lqhViTqgi3BAsBfadmZtgs45wmgAnz8QEOYcWQS4WAc4diN0SHrjjNjQSSQKYn+scgh6p5jAQZ0EqYNyTlNDA2T6Ij/ShMzuauTEhKDnjsGQ8XNhXA+bo9V8/xb1nOYgA1RVtpWhEqXkA26o0ncTEnzwInHB2J5a0oyHHEhK8xlZD4rJiA==; 5:JotjSA2H4ngxd7rob5v9RRVU6KuEms9gHuyQfeQbiH7dgtzF5U86s+9ynT6O3Vb8cZUi5s9iVmco803JALYpn7ZYb2J4JH2CEhtxTQHhJwTuzvlA1o9VyXloHYes7N45m9pmNnSt1GJWOBC7AF0kWA==; 24:SFhZ10wUtx49owX1jlc/qqpijbEIE89eXCBUbcsFeOS4rLPwTdqoz88+VqFsiHwWqg7W3YuaKelySh/zSYZjb4B3SQUd+YmnIQmDmrVLggk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 7:RaWulwiup5z8R09wZ06rN/5uTfOpVHZXILLeRDXoRLeiHoyMgRl7tVPwVehNXuRiJTmGODTDi/vlEG0xO+7Ui/7d4LPp6MDeQE0/ZpP71KZIE0F2SDDnvQ9Th+GSpeBPQrYI19MaOOHW/3KPHNLdcgQjNLk+LdlfJTP/UNgzmVGyF5Dz2ryOWNMYi/Tl4xm4kva21WH/yBExP0aYhYy9prW5aPBIiZwmwZYmF0cNXJ4SvMZld581e9cCIA+aWLn73fNEEQ/hkjurw26HTdJz1GfeVysyYLDZFAEnD7MdahATCkW/sX8JyleiY0zpujC+w1g1Gy4LeR8zPTDvSsaGSa1CjomAtLGE5tnRLH1I/rNJukCD1CYu2GbYbNbjWUNIiiee6NXH5EYMO8Lq8WFJ0aJNTBkZAsye1SzkVay3ElXDUa/Kn+62uK0DvDJlPJm5KxnudPfWBzhLHzbuuWlQTbf1kcfG6viBYA9ifb1xwcTPDiyj0xZAsH7jJb6ofHn7ttjDJOknQ/0OIjepkX8JcQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 15:36:22.4942 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0959 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUyM2K7pe6P6TMiDFauM7a4sGoum0XfrgOM DkweS5b8ZPLYdPkOYwBTFJdNSmpOZllqkb5dAlfGodniBYelKk5OO87SwLhDpIuRk0NCwERi 069NrF2MXBxCAusYJXo3drKCJIQEjjNKdD3hAEmwCPQySzz/OY0dJMEoECexc81CqI5/jBJ/ riwESwgLWEn8WtgO1i0ioCxxccJPFoii04wSR2b+YgZJMAtoSlx9ug2sgU3ASGJq/3kWEJtX wF5iwt5nYDaLgIpE+6JGJhBbVCBG4uWeVVA1ghInZz4BszmBln3oPcHWxcgBNNNe4sHWMojx 8hLb385hhnhNQeL65ussEHYHo8TNZ/4Qn2lIPLzwlxUi7ivxqXMTG4x9aeNiJpCbJQRWsEn8 XTgJyrnIJjHvZCMjyDIJgWyJw4+zIBq8JdqfXWaHqFnOJLGz8z0rhNPDJtHddAZqrIzEkxXr mSESM9kkPrYchoZwqsSWGy1sExg1ZyH5bhbCR7OQfLSAkXkVo2hxanFxbrqRkV5qUWZycXF+ nl5easkmRmB6OLjlt9UOxoPPHQ8xCnAwKvHwFvTPiBBiTSwrrsw9xCjBwawkwrtwElCINyWx siq1KD++qDQntfgQozQHi5I4r9nK++FCAumJJanZqakFqUUwWSYOTqkGRuEw1jmzL6rtlbI8 wHx1nn/k/jvBogeOljrNtLcsSSrmE/67+9DTWl/Hu4vybzv88u0VcU4/+NTR+oGC4f/JUUtW /lGNrgr9lf22aumVLfZRHIEdwZqn9K5U/f+ct8Bo/tv/y4Q+Pmnj+lrL5V8i86Bt3oOQbUsP 7W5Ru/3p7twVDetc55xsnaHEUpyRaKjFXFScCAAFBCcJCwMAAA== Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:36:29 -0000 I agree that clever tools could and SHOULD ignore unused imports, but will they? Will you ever modify PYANG ? Will my unnamed SW provider modify xxx? (Was that a rethorical question, maybe) regards Balazs On 2017-02-06 15:16, Ladislav Lhotka wrote: >> On 6 Feb 2017, at 14:44, Balazs Lengyel wrote: >> >> Sorry, but adding a module to a product that we explicitly do not support it is misleading, even if it is for import only. People will start asking questions: if you don't support it why is it there? People responsible for product packaging in my company already rejected that. > It is somewhat unfortunate that the "import" is overloaded with several different functions. What is needed here is just a mapping of a namespace prefix to a module name - no import is involved. Leafref paths could have been defined to use module names instead of prefixes and then no import would be needed. > > Clever tools could probably figure this out, as Juergen suggests, although RFC 7950 says in sec. 6.4: > > The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context. > > Lada > >> You can do hacks like creating a dummy modA, but they are hacks. >> >> regards Balazs >> >> >> On 2017-02-06 14:18, Ladislav Lhotka wrote: >>> Balazs Lengyel writes: >>> >>>> Hello, >>>> I have two modules: >>>> >>>> module modA{ >>>> prefix modA; >>>> leaf leafA {} >>>> } >>>> >>>> module modB { >>>> import modA; >>>> >>>> feature modA-support{} >>>> >>>> leaf refToA { >>>> if-feature modA-support; >>>> type leafref { path /modA:leafA ; } >>>> } } >>>> >>>> What I would like to achieve is that IF my YANG server supports module >>>> modA then modB should have a strongly typed reference to a specific node >>>> in modA. If modA is not supported as indicated by a feature, then I >>>> don't want that reference. The if-feature on the leaf works fine, >>>> however I can not put an if-feature on the import, so even if my >>>> YANG-server does not support modA it must use it during checking and >>>> possibly SW build. >>>> >>>> What is the reason that import can not have an if-feature substatement? >>>> >>>> Is there another way to achieve this effect? >>> I'd say the server should in this case include modA in YANG library with >>> conformance-type "import" - the import in modB should then work and modA >>> needn't be implemented. >>> >>> Lada >>> >>>> regards Balazs >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Balazs Lengyel Ericsson Hungary Ltd. >>>> Senior Specialist >>>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>>> >>>> _______________________________________________ >>>> yang-doctors mailing list >>>> yang-doctors@ietf.org >>>> https://www.ietf.org/mailman/listinfo/yang-doctors >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Feb 6 07:50:18 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BDD129E84 for ; Mon, 6 Feb 2017 07:50:16 -0800 (PST) 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 IPd5HEbagXUw for ; Mon, 6 Feb 2017 07:50:11 -0800 (PST) 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 66D09129E6B for ; Mon, 6 Feb 2017 07:50:11 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id 19FFD600C2; Mon, 6 Feb 2017 16:50:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486396210; bh=5LEiMwzQOQQpDePOANLGaOtDeYf/OvD6g6SEYgqJLxw=; h=From:Date:To; b=dFjo6kk70GfkX5u6dalYyoW4IrQx2N7khBhYSZsXSUXSMVk+J9/7UjWIiD9YqUttQ Wiqd6otfRoBAwg/lAg5MzjCMPES3WIAHYd7DbjskFPER+8nxcuNM/A/57VKzyUeu95 sZEpJIEs2dEdIbjsLQQJDvMHjU0zL8jF410fRfSM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> Date: Mon, 6 Feb 2017 16:50:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:50:16 -0000 > On 6 Feb 2017, at 16:36, Balazs Lengyel = wrote: >=20 > I agree that clever tools could and SHOULD ignore unused imports, but = will they? Will you ever modify PYANG ? Will my unnamed SW provider = modify xxx? (Was that a rethorical question, maybe) >=20 I share your concern, in fact the import *is* used in modB. There is no = indication in 7950 that contents of statements that happen to be = disabled via "if-feature" can be syntactically incorrect. Lada > regards Balazs >=20 >=20 > On 2017-02-06 15:16, Ladislav Lhotka wrote: >>> On 6 Feb 2017, at 14:44, Balazs Lengyel = wrote: >>>=20 >>> Sorry, but adding a module to a product that we explicitly do not = support it is misleading, even if it is for import only. People will = start asking questions: if you don't support it why is it there? People = responsible for product packaging in my company already rejected that. >> It is somewhat unfortunate that the "import" is overloaded with = several different functions. What is needed here is just a mapping of a = namespace prefix to a module name - no import is involved. Leafref paths = could have been defined to use module names instead of prefixes and then = no import would be needed. >>=20 >> Clever tools could probably figure this out, as Juergen suggests, = although RFC 7950 says in sec. 6.4: >>=20 >> The XPath expressions MUST be syntactically correct, and all prefixes = used MUST be present in the XPath context. >>=20 >> Lada >>=20 >>> You can do hacks like creating a dummy modA, but they are hacks. >>>=20 >>> regards Balazs >>>=20 >>>=20 >>> On 2017-02-06 14:18, Ladislav Lhotka wrote: >>>> Balazs Lengyel writes: >>>>=20 >>>>> Hello, >>>>> I have two modules: >>>>>=20 >>>>> module modA{ >>>>> prefix modA; >>>>> leaf leafA {} >>>>> } >>>>>=20 >>>>> module modB { >>>>> import modA; >>>>>=20 >>>>> feature modA-support{} >>>>>=20 >>>>> leaf refToA { >>>>> if-feature modA-support; >>>>> type leafref { path /modA:leafA ; } >>>>> } } >>>>>=20 >>>>> What I would like to achieve is that IF my YANG server supports = module >>>>> modA then modB should have a strongly typed reference to a = specific node >>>>> in modA. If modA is not supported as indicated by a feature, then = I >>>>> don't want that reference. The if-feature on the leaf works fine, >>>>> however I can not put an if-feature on the import, so even if my >>>>> YANG-server does not support modA it must use it during checking = and >>>>> possibly SW build. >>>>>=20 >>>>> What is the reason that import can not have an if-feature = substatement? >>>>>=20 >>>>> Is there another way to achieve this effect? >>>> I'd say the server should in this case include modA in YANG = library with >>>> conformance-type "import" - the import in modB should then work = and modA >>>> needn't be implemented. >>>>=20 >>>> Lada >>>>=20 >>>>> regards Balazs >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Balazs Lengyel Ericsson Hungary Ltd. >>>>> Senior Specialist >>>>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >>>>>=20 >>>>> _______________________________________________ >>>>> yang-doctors mailing list >>>>> yang-doctors@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> --=20 >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 6 08:19:03 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2526129EFB for ; Mon, 6 Feb 2017 08:19:01 -0800 (PST) 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, 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 9Lj3Xg3O6yj9 for ; Mon, 6 Feb 2017 08:19:00 -0800 (PST) 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 AACA4129EFC for ; Mon, 6 Feb 2017 08:18:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 840DE6AD; Mon, 6 Feb 2017 17:18:58 +0100 (CET) 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 EDAaicgjKRXX; Mon, 6 Feb 2017 17:18:57 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Feb 2017 17:18:58 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 338F6200BD; Mon, 6 Feb 2017 17:18:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iSI8XZa5nrLo; Mon, 6 Feb 2017 17:18:57 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39B03200BC; Mon, 6 Feb 2017 17:18:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6A15F3E6917C; Mon, 6 Feb 2017 17:19:00 +0100 (CET) Date: Mon, 6 Feb 2017 17:19:00 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170206161900.GA93308@elstar.local> Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , Benoit Claise References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.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: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:19:02 -0000 On Mon, Feb 06, 2017 at 04:50:09PM +0100, Ladislav Lhotka wrote: > > > On 6 Feb 2017, at 16:36, Balazs Lengyel wrote: > > > > I agree that clever tools could and SHOULD ignore unused imports, but will they? Will you ever modify PYANG ? Will my unnamed SW provider modify xxx? (Was that a rethorical question, maybe) > > > > I share your concern, in fact the import *is* used in modB. There is no indication in 7950 that contents of statements that happen to be disabled via "if-feature" can be syntactically incorrect. > Perhaps there is confusion between _parsing_ and _implementing_: - To _parse_ modB, you need to be able to resolve import modA since there is YANG syntax that only makes sense if information from modA is available. It should not matter to a generic parser whether certain features are enabled or not. - To _implement_ modB without the features that require modA, you are fine to do so without implementing modA. (In this case, the import of modA starts to look like an unused import.) What exactly is the problem with this? /js PS: If we allow if-feature on import statements, someone would have to code YANG parsers to enable them to validate conditional imports for any possible combination of features to ensure that the imports work out in all possible cases. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Feb 6 08:43:47 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A112958E for ; Mon, 6 Feb 2017 08:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 zbJEBHrRWDky for ; Mon, 6 Feb 2017 08:43:44 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3F3A8129585 for ; Mon, 6 Feb 2017 08:43:44 -0800 (PST) X-AuditID: c1b4fb2d-bcbff700000059d1-c2-5898a7bd30cd Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 8E.05.22993.DB7A8985; Mon, 6 Feb 2017 17:43:42 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 17:43:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1xUFOfqZ9hZzQbkdUwENuJZxjthX3Tlz0Ma+cj7ncWo=; b=L+IquSiG5Yv44liDOk4MZSg/REJoiRkw+Bx7aLU31O/cGoYE5kve0bUCw3SYyyuwgaV22996FPfXVfgKbEAcgsfaIkDEvPDq7R35cHxwNzzISgaPiFdCMTR/2OwupysDHmECmvjv36p/TgDpbpVd+bfU+58bfchTiF9fWaBpvhQ= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.235] (91.82.100.59) by VI1PR07MB0960.eurprd07.prod.outlook.com (10.161.110.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 16:43:39 +0000 To: Ladislav Lhotka , Benoit Claise References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> <20170206161900.GA93308@elstar.local> From: Balazs Lengyel Message-ID: Date: Mon, 6 Feb 2017 17:43:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170206161900.GA93308@elstar.local> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: DB5PR0101CA0006.eurprd01.prod.exchangelabs.com (10.165.200.144) To VI1PR07MB0960.eurprd07.prod.outlook.com (10.161.110.152) X-MS-Office365-Filtering-Correlation-Id: eaf84c0d-75a5-4c9f-65cf-08d44eaf4e16 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB0960; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 3:bRAA/jY+b7XGeG82OH+ZoveGHxJxovhGxJuzzJ4epNJTxzTzrhwKXL7hiuffxc0BZSkznezEWRMrlGkCPj6jQURtZAjxeJfniO4dPSl1qtzIYynP1eiq0EXqvIHLEw4YxX9VTAW/4ryd/m/SC5aCqP5hW9LKTaFV7WSn74dsL1vvv4Q2vnDGwjQ+PQAFKSmCmoYOdOuMdsnm+GHHDLRA7oQeL6tO6nyjC07rVaOZXwp00WKS17F1Y7bXafe1qTTKpl/HWnPGhTMfZs7NXKDhDw==; 25:uoYzTaGR9dzNqSp1mvlPZgHtzUFGEDUPl6SESvdKwhr/cv7dT2iMleBdLwfc7xaa+4d4m2rJp7qOVxHiTiPrwDfflKN44cBJD2ZyX3b8RZntQ45tNPCwp+0d8QuCAYFllHp8gnvE18G3WkbR1ywlJ9NkIicoAgN2zrN1LAe0gNqkPQzXBAjSPVnh/1Kt4VeXDT2yxLB718ltgsBDfIwAEmlod63zJr3YcQB67JZzcvjVfj4HpRqUa1GoQiJfmkdf9NrzfaeWQ4F40jvVRGPbIgf887bTEZV4+6yxzHR1u0gZ1EB9fu+RB3DXvFrWN9dLei+HtBXS+s/vFVHUX2a+SgZZCNwidM61bHyi/QGqfGGCEOHyVdDww5JSWYhlc5EOVh3GUYdMVPAIBeeVtn4yFj6fuTgV2qpXixRHMGUA5XxpksjXwtBl4sQDTUrhX5w/fxGPiSmZQdVhALwEzPYTAw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 31:al9BcYrllEmP+qTRn6mV9U9zrTKsHkTEYdtsGhq9STv4y9TiTe6+1ARiD21dchaQcS4aiYPn3P4qYfar0ygpa6nU5S9VZBQxf1diLhgHbBAjpPGCPJ249CaplFBYN+HVUz0Sos9MkWu+9on9TbgFLmYliWDadKE9gbyzlyXD87iqQjHyHYP2103ziKKSJU92pQMDRYQd+qWprwB8UILqOn2QLgZGTWQMYbsSc8J1b17Fkw2ojhJXfL2gxbQvqeV+0F/lqE5b4Ymm+jeX+adYWQ==; 20:0SSMRqxXKsRrXuL08eTaoHw/FrZAiYcYcNhVfHalVfTKYhrUTCr2bT+brdrUWnCB7dZbRtuL+8H/aVJrzeJTmZ1rxn2HTjgYiXInhNuw+I7Y1foKe2DoKQ91DquNuBgkVAcMBKyXzHQlBThdHhE1WN6k2LpP0ybltcymavVfw6l1rk01BGq/EA8qADxjHi2K+NK3R19kixPrwwXoJARMkaUOhPtn48mlLlaf/BQ3teME3LeiawNgXYRoRXWg55D+jOJMYkabMOQv3mjkZE/0MipVzHECpb/k98RYDb9vIxPlYTmTURh6mbYM80RzV4L02lbL9WwweZTcH9z1z4UGuwyErD/VowJ7pJFpJDECeuiIfjns671J1lBr58g48ZLlAwegQazHE2dyp0Cl4ghiecEPf7a7WGwNac8s8Cu2iylTHFwXz5q1f8X2gODFnaM0xXJWq+u5jKzoXhbzlI0nmY2i8nNqd7A5O4m95nYJgVtKVdtvbtN8E+3VFLPuS3no X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:VI1PR07MB0960; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0960; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 4:R0hpVegWRJFheWldEPqR/E8juda6hrk01hEiNfq1xjfWKHeTgr0UOhC4tIEEzYmOBDgTEbz92modbd8BOG08+h2DXV5ORoCw5xDIXWakN/noh0TW2qt361NmjZjcVe7q/LXrwpG4sWmONsWI/x2XZIUsoz0SkRldt2O9rUQTI35gG5YEa575xqhu65Coj4rg8EgM4WDZgi39aPZif+NFrX/HwiAKxsWSEQTXzdMCHQRfDsgV50Mv8ZOdotgWeA+Nd12oPGH6Xb22m0pJGLSpD2CMLZ2ae0Kph9p1lrecrlVI5+nE5fZdJh95wT3rrZD0JH0Sh/i50GwcqPgl6KFCE+te1Q5cdB4h5ubEzJva41LC++yUEBMZYxfLqnl8JPyUHrjluz0+S8qWP8ZfIADwXtBaolvJtDONyQzvNOsPse/EsdsHkaUSxJgJyAqP1g+Rg0KglUfxRtvM0VsYO39kUgXJE0V/+0Dp9KfNpBAP76KqYxCwNRwK3Y+c/mvAz+vfuQY2bBiArvUvZYk49Fq+cpad+7MtWLdCVtRsiTwJUydprR+XkrgyVFVc7gUzRJ3L57BkCzDRXeBsD3ew+k4A3n/0NfBGIbXkUCmg7ByLumY86Ls5ItoyTlOkt94EWDhjlCycJgCf9kq5HlyqrWtIEw1L6Ym0IMbM/4wPAlP1MRm+Q2z3hHNeG6ly1L+E49g2 X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(6049001)(7916002)(39450400003)(377424004)(252514010)(24454002)(189002)(199003)(106356001)(105586002)(38730400001)(4001350100001)(8676002)(54356999)(25786008)(42186005)(107886002)(65826007)(6486002)(86362001)(230700001)(97736004)(31696002)(90366009)(81156014)(101416001)(305945005)(31686004)(33646002)(81166006)(76176999)(50986999)(23746002)(189998001)(7736002)(5001770100001)(3846002)(6116002)(2906002)(6666003)(47776003)(65806001)(65956001)(6246003)(64126003)(229853002)(53546003)(50466002)(66066001)(2950100002)(93886004)(5660300001)(53936002)(83506001)(36756003)(92566002)(68736007)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0960; H:[159.107.197.235]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; VI1PR07MB0960; 23:5ln6uN8BZ7+U29QGbtOqplc34mK50yoEJDQk1?= =?Windows-1252?Q?RhHu4kEaCjHfrIHZwAO1h04GHdjgQxnGpALFbZ00EcXyq2rlWjwSCH/V?= =?Windows-1252?Q?Gtuq6dip53nu4As/Wihk1xTRq/GRPe7Hi3ZHrWaE6TreTVzzGBW5g0Lw?= =?Windows-1252?Q?GQ95D5SqwNLNdL+rLIOBLuERyqtEr2qFWsn0udHK3whQ4H1kf64d6IEs?= =?Windows-1252?Q?6bKe/OlEeubvxwiLBaeJxC6OHfeccjG7/9+uG4Yv+/9o201EEjYkJuvR?= =?Windows-1252?Q?mcpGT8Gz7Cj8m6a4t8OYnRKvDSGwZ4chwkoTj03nN9NdsYkRHmGvEneh?= =?Windows-1252?Q?aCcwPF13d4fZX7MaHkpKpY61QxCJK6GKpgZ7DX3f5N0C2EDiNYldC2vf?= =?Windows-1252?Q?BfjOUgaaYAp++xPaIbY32bleX0KEJF04fJ6nqdH84qxXnXPuynlL68Cw?= =?Windows-1252?Q?1l39oBfQXONd++uRUUBFRSW90mZlIxBJoIQKOoAcwD8VS3NchUjdtyKt?= =?Windows-1252?Q?8lRszWxVP9G5dPSCJIEqmMmG7qReK1sEBAgzL23Wnzg6ODQfOqYAHzsM?= =?Windows-1252?Q?WHDKdgJC740c5zynz4k9hpsGlCx5QPbUvOer2Bnqr7OKgEXY9Zkd/FU4?= =?Windows-1252?Q?lvRRnTvd2uuOjHSwSKHoi6tmk6VysA91+b6RBQd7IPwI5uQ3BsK3vh0x?= =?Windows-1252?Q?/B7acJfIykZRSthMgg7DlPOn4QABG3yt6YOzT+K5ba6EOoD42PqLiqpI?= =?Windows-1252?Q?Y+sn4GwgEPqJAMgXPUc0xjiObuLgtm7Lpd2tJrUymUGMADYQznMtQpd9?= =?Windows-1252?Q?5F0lWUTt00QzraKcWQcCSKt/90c7tDgXklJOFGW1EY6ZCoRxXMzLBFbn?= =?Windows-1252?Q?kOZCwWXDxX9ukz/TPad+fVWlAc/96gd8h3kHFI24rUPQIy2/YoFNK/rs?= =?Windows-1252?Q?47MdPbWQqRZ6eL84lcKM+zhI4wbNaAAJTZ1iKh6izZK5N6n1DlDgBo1t?= =?Windows-1252?Q?XsUIc+ObvGRXOT8SadPvtnGGlgbrTjqiHdCIhL1Fj1QOJQ/GVscfayMx?= =?Windows-1252?Q?B1voIo3H+HPdwUdEB7q38CdXEATAnuB8zW9si6aOHDQfVlr104KPsKPA?= =?Windows-1252?Q?J/KCT23vVQ2QrijIIymwGIEXmq53NTfvcB/EjbRsWw4oYqfzaOfG8h2z?= =?Windows-1252?Q?1xmtb5ErlVb9wLdnK2MwnXM+U8BhM27ZaoaD7q8sceJ+8k6IqIQ6Hkyp?= =?Windows-1252?Q?UfEl9B2I5y9alOJ0cbxhN/ON63W/XT4A1KdNDjB9dfF5STUonIy2AN/v?= =?Windows-1252?Q?t9kv8NOzO/reHoxCyitVE1tGdiYGyIw3IDqU7DXI3WqgObej3h6dcKnb?= =?Windows-1252?Q?aDP3Rulme3rG4nhDkf4nFtvaYhUU/Q+iLaDI63SAbfFlgXyMjAK2rhGw?= =?Windows-1252?Q?yUIKtZ0h4K6zfEuLUEKS9qRFJ4OpFRZu10uYf5k9DKyGRnj04a07ONQa?= =?Windows-1252?Q?Ji9xvEmVqMt+/yhOUdfxAnm5eUqfOFZJb55LDkBybbhF0F4CaiVajL3h?= =?Windows-1252?Q?JXC6SdtEcPAV7Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 6:zzZpWedDwTvCKpD1OaqCbPveFJhu4LvOP5re3ecdNNcx3dHMoTQcvfG+oO0sYYdwLLhMIh1l4293T7Zn5YFLQFTAqFiCw3nFS1z1NnL5gXkopXPcu3ofn8YTYxsqZ+WsPGl5YZ2k/OEszVJzfLclpj7FWto89pEo8MG5vPo85UX0pEPamd5bW/e4eAQZVocYUL3Oz7ama55K9BEuJ2UFx3TvF2dhSoQuoUDz7Og5coSi00sVxXVVB2nMdhfK858T395XjvvGLnvGOWeccoxHw810j212x400amDraIcvB4CZTOKcF1/R7LTytP8QF6T4+OXaWG1x7C804Eqk9T0u1jRO6FT/jjg2SfmtDE6ElLIx1zj8jMLrrG2kAcSkugvGL31okkC1TkWGKhj3xS/eTA==; 5:F7epH8Hg8pmcreQhdS44Ayj/7M0egFAX2InP4u9YHtV1HaFmCP7qHBYJcEO2MfjXoTMpsmmILC4G+CKOLhs7VA6uqY5UIobqQGtzEBsLV+A8eWg3Rr115at+magJjptQgGkoPzm8AP1h6AJWp1eJpl02z23qJcS5KQAMWI7XA8M=; 24:DVDxOK71RrpIZyZJ9w5yTvvXL0aakywc8AGAlmTD84kcVOIw9WCbIKkA6R+onb8iziEY7B4D8LOkaN/q4dmozmpHyL9mYKsTeCDQRX9wNyE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0960; 7:GOK4UqRwFmIW3ridh7Iew4sguRdmvHL0DSzgw4RfMzkHN+E938j43E8Ps6Fiu4ONK3vKei+REnNfXP3FE6Ga6q7q2wGT5aMFmtjZfQJ2n9JRwDnECZozbQRi5qSxRknTFktsd0KBw5lQYPNDxjzsSM8kM4fCV2FOjC9fFgA76X+ObANUwI35uXr/BnYr6C0SbZmDt8BFwXd0CQS+z5evvWZt1qXCgwBIf/mx0MzzxZ52xaqUfmoPVzWcb6EPV7EDTV2Mccbu/2YkWw5ZrIM0pM0RoO80Z+9BLqWnlwEruS5c0MjrbNtkQ0DutSkIct2E6/BIU/6IQxm18/vjuWMKpBsIP/SyLWUODgiiwZu4ntBVldW8e4mBSgLcFomn88wtO53XGkT69EqgRshyJom2/RKxGW1bvt4UAuaiKMPEUiwP79CR6C6DZPCxqvRFJL1XGlX6GU8q77z7Sq+DLZBO8IC/ch0ur+BfGXMm/Ig3WkscBsmNGaCWiPpNaHfDijneDTIuWrrC7dDwM7JxzUMgkQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 16:43:39.8343 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0960 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7me6+5TMiDOZt1rS4sGoum0XfrgOM DkweS5b8ZPLYdPkOYwBTFJdNSmpOZllqkb5dAldGQ1sje8EvwYrnF2ayNTC+5+1i5OSQEDCR OLTwMGMXIxeHkMA6Rol9T++ygiSEBI4zSvy4mACSYBHoZZZ4P/sJC0iCUSBOYueahawQHf8Y Jb4s+c0IkhAWsJL4tbAdrFtEwEti89KLUEU3mSS+vrzGBpJgEzCSmNp/HmwSr4C9xPzercwg NouAisS/E3PABokKxEi83LMKqkZQ4uRMiM2cQL27z7UD2RwczEC9D7aWgYSZBeQltr+dwwzx joLE9c3XWSDsCYwSr1q1Ib7RkHh44S8rRNxXYnHvETYYe87Z5WB3SgisYJO4vmA5G4RzkU3i 34cHUB3ZEocXXGSHsK0kXv/6zghRtJxJ4s6ew1AdX1gl5s5thZorI/FkxXpmiEQvm8S1nztZ IA5JldhyowWqY5OAxMnZx9kmMGrMQvLrLIT/ZiH5bwEj8ypG0eLU4uLcdCNjvdSizOTi4vw8 vbzUkk2MwCRxcMtv3R2Mq187HmIU4GBU4uEt6J8RIcSaWFZcmXuIUYKDWUmEt34pUIg3JbGy KrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQZGzrCrq7Z99wgw+S0f 6+raLs65NWqd5IfYl/UWD+6kF523y3u46415dNvRdz+N9FouhEk3GG58ejfV12v1962mkn5f 97Tyqbr+N9Mta1prb1yq+eJG4vvwa1odljoX+063TXvHvMqpquv3qSM2V5Y9Ulx8+XvKa4PQ UMfPywzkl15YK+H7sX+DEktxRqKhFnNRcSIAd9ngEQ4DAAA= Archived-At: Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:43:46 -0000 If I have a product that does not support modA (actually does not even want to know it exists), as I understand the product still has to - have the modA yang module available to run PYANG - bad, but acceptable - have the modA on the network node / yang-server itself, to be able to run my YANG/Netconf SW stack, which will result in the unsupported modA showing up in ietf-netconf-monitoring and ietf-yang-library (although only as an import). - not acceptable So while this maybe a question best solved by tooling, if you can think about any other design pattern to achieve this more cleanly I would be grateful regards Balazs On 2017-02-06 17:19, Juergen Schoenwaelder wrote: > On Mon, Feb 06, 2017 at 04:50:09PM +0100, Ladislav Lhotka wrote: >>> On 6 Feb 2017, at 16:36, Balazs Lengyel wrote: >>> >>> I agree that clever tools could and SHOULD ignore unused imports, but will they? Will you ever modify PYANG ? Will my unnamed SW provider modify xxx? (Was that a rethorical question, maybe) >>> >> I share your concern, in fact the import *is* used in modB. There is no indication in 7950 that contents of statements that happen to be disabled via "if-feature" can be syntactically incorrect. >> > Perhaps there is confusion between _parsing_ and _implementing_: > > - To _parse_ modB, you need to be able to resolve import modA since > there is YANG syntax that only makes sense if information from modA > is available. It should not matter to a generic parser whether > certain features are enabled or not. > > - To _implement_ modB without the features that require modA, you are > fine to do so without implementing modA. (In this case, the import of > modA starts to look like an unused import.) > > What exactly is the problem with this? > > /js > > PS: If we allow if-feature on import statements, someone would have to > code YANG parsers to enable them to validate conditional imports > for any possible combination of features to ensure that the > imports work out in all possible cases. > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Feb 6 08:58:43 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE146129592 for ; Mon, 6 Feb 2017 08:58:41 -0800 (PST) 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, 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 sfyB2_rAoZQG for ; Mon, 6 Feb 2017 08:58:40 -0800 (PST) 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 B383A129F1B for ; Mon, 6 Feb 2017 08:58:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8259676D; Mon, 6 Feb 2017 17:58:39 +0100 (CET) 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 SPu1b_JiRhSd; Mon, 6 Feb 2017 17:58:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 6 Feb 2017 17:58:39 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D9BF200BD; Mon, 6 Feb 2017 17:58:39 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LWsDHmyEjE6G; Mon, 6 Feb 2017 17:58:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F001200BC; Mon, 6 Feb 2017 17:58:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B49583E6935C; Mon, 6 Feb 2017 17:58:40 +0100 (CET) Date: Mon, 6 Feb 2017 17:58:40 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20170206165840.GA93408@elstar.local> Mail-Followup-To: Balazs Lengyel , Ladislav Lhotka , Benoit Claise References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> <20170206161900.GA93308@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: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:58:42 -0000 > - have the modA on the network node / yang-server itself, to be able to run > my YANG/Netconf SW stack, which will result in the unsupported modA showing > up in ietf-netconf-monitoring and ietf-yang-library (although only as an > import). - not acceptable Balasz, even if we would make the import of modA 'if-feature conditional', you would still have to list modA for import in the YANG library since a client's YANG parser still needs modA to do its work. There is nothing in the YANG specifications that says you can conditionally parse a module and skip over YANG definitions if you believe a certain feature does not matter. Perhaps a proper explanation for your customers what 'for import' means in ietf-netconf-monitoring and ietf-yang-library is the solution. The other alternative is to talk to the module author to split the module into smaller pieces. /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 Mon Feb 6 08:58:53 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8726A129F1A for ; Mon, 6 Feb 2017 08:58:51 -0800 (PST) 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 04RjRNN27iQQ for ; Mon, 6 Feb 2017 08:58:48 -0800 (PST) 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 62C4B129592 for ; Mon, 6 Feb 2017 08:58:48 -0800 (PST) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 0E25960107; Mon, 6 Feb 2017 17:58:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486400327; bh=Wx85SOEnOc0AmVko3DRf6bB4FPx4pTJ263jlzcb9XMY=; h=From:Date:To; b=hfIHpjMz8MLCjFBQeKU9w4q9Yg2zWpgTaOJUhq1W1d8L4rFzaIM+RhnjzJWla9wr5 rHMKJPE4uRSHYyUqtD9CjYQGF0FpRDHxV/J0J2m6VqvSiXkMZ7rsI48/9+fxIItWyM DmmtBHiZ+Y1JXoV8bmqc/OLyjm/+fdHteg325hNA= 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: Mon, 6 Feb 2017 17:58:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <558C286A-0E50-4BCE-83F8-1B01E5150D3D@nic.cz> References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> <20170206161900.GA93308@elstar.local> To: Balazs Lengyel X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 16:58:51 -0000 > On 6 Feb 2017, at 17:43, Balazs Lengyel = wrote: >=20 > If I have a product that does not support modA (actually does not even = want to know it exists), as I understand the product still has to >=20 > - have the modA yang module available to run PYANG - bad, but = acceptable > - have the modA on the network node / yang-server itself, to be able = to run my YANG/Netconf SW stack, which will result in the unsupported = modA showing up in ietf-netconf-monitoring and ietf-yang-library = (although only as an import). - not acceptable It depends on implementation but, strictly speaking, it is not necessary = that modA be present on the server. It should suffice to include it in = YANG library, as I suggested. It is then up to the client to get modA if = needed. I don't think it is a big problem. In YANG 1.0 it wasn't even clear whether modules that are imported but = not implemented have to be included in hello. Lada >=20 > So while this maybe a question best solved by tooling, if you can = think about any other design pattern to achieve this more cleanly I = would be grateful >=20 > regards Balazs >=20 >=20 >=20 > On 2017-02-06 17:19, Juergen Schoenwaelder wrote: >> On Mon, Feb 06, 2017 at 04:50:09PM +0100, Ladislav Lhotka wrote: >>>> On 6 Feb 2017, at 16:36, Balazs Lengyel = wrote: >>>>=20 >>>> I agree that clever tools could and SHOULD ignore unused imports, = but will they? Will you ever modify PYANG ? Will my unnamed SW provider = modify xxx? (Was that a rethorical question, maybe) >>>>=20 >>> I share your concern, in fact the import *is* used in modB. There is = no indication in 7950 that contents of statements that happen to be = disabled via "if-feature" can be syntactically incorrect. >>>=20 >> Perhaps there is confusion between _parsing_ and _implementing_: >>=20 >> - To _parse_ modB, you need to be able to resolve import modA since >> there is YANG syntax that only makes sense if information from = modA >> is available. It should not matter to a generic parser whether >> certain features are enabled or not. >>=20 >> - To _implement_ modB without the features that require modA, you = are >> fine to do so without implementing modA. (In this case, the import = of >> modA starts to look like an unused import.) >>=20 >> What exactly is the problem with this? >>=20 >> /js >>=20 >> PS: If we allow if-feature on import statements, someone would have = to >> code YANG parsers to enable them to validate conditional imports >> for any possible combination of features to ensure that the >> imports work out in all possible cases. >>=20 >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 6 09:14:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289AF12959F for ; Mon, 6 Feb 2017 09:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 m110EVQFvcpJ for ; Mon, 6 Feb 2017 09:14:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2BD3F12959E for ; Mon, 6 Feb 2017 09:14:07 -0800 (PST) X-AuditID: c1b4fb3a-7d7ff70000005e23-46-5898aeddb377 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id 1D.69.24099.DDEA8985; Mon, 6 Feb 2017 18:14:06 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 6 Feb 2017 18:13:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vNP75LVVFbv/NSsDUb412EYkd9rG2KEjsM4RMLw3Wpc=; b=eP7AuzJsVnN0u1ppLZGrdG1X32a4P+2fztHRXhtjngam3V2XGDQePayrl5ggUHuMeiSpK+o47LDrz37OsRVJZ8ViBChgOuaSpmKvXnbhCxrKuMBWxqRoPnhAa9IwvC0Ej011srLfcZy86pVn29nPQIrSRACP7otRnLQtpNRilpk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.235] (91.82.100.59) by AM2PR07MB0946.eurprd07.prod.outlook.com (10.162.37.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 6 Feb 2017 17:13:29 +0000 To: Ladislav Lhotka References: <12a1d334-6a19-d154-c103-7d67bad22053@ericsson.com> <852D54C6-5DD9-4C9E-8AFE-A51303247BD5@nic.cz> <42671eb3-7951-1e5e-029c-5d8bb3266fef@ericsson.com> <20170206161900.GA93308@elstar.local> <558C286A-0E50-4BCE-83F8-1B01E5150D3D@nic.cz> From: Balazs Lengyel Message-ID: Date: Mon, 6 Feb 2017 18:13:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <558C286A-0E50-4BCE-83F8-1B01E5150D3D@nic.cz> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: AM4PR0902CA0004.eurprd09.prod.outlook.com (10.171.89.14) To AM2PR07MB0946.eurprd07.prod.outlook.com (10.162.37.141) X-MS-Office365-Filtering-Correlation-Id: 8df42f4e-b662-4f4e-8830-08d44eb37885 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM2PR07MB0946; X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 3:b9XaSDBa1uZu24eefWDyKRahowiluZctNjRyG5DdX2bz5rhDv5R5DvCYUfoD6lbubDrb9ZecpSK4ExV7IllDGqwBHbg41ITHApycVviuzD8/ilbkJlpPv1JwZwGxLepvAEA+EL5R7NDCawSs01LvBTK0/jvflV+TFY+7v/KRpg7mfBKKzFWWwwVOnVIkYM3rqFN5eVL89hoQjaBVX58p2UqlN8b129rSp0CizdIRFpjJdMAoFOj2UClTVPsC9WA7WkMgRw9jL+o4fyMCAuQORw==; 25:2I6+m55XxNjXUJ+xNB2k6OH0cduRgD6uQbAXQlHMF5AfkLK6MiXEhr0ZtTBvRqO1owbTkBjP5r0PVepQFgGbGBI5kr2BLIUBpTARDa1WYCe+npfaF7RgBTI8R+yi04BhE2z8nyCK+EC6F5ubM8u+RQThFAa5yMdLjNiLVo9tUEGWoPc9p06Lxvr3BhwBs/vyRiUDegS8AGZ9CGrqqhxevIhLdQLMY3htoVR7i5xwXMZC6RifLXJc8eREspb8Hsk0ygTZqK5f++bFpNkVdj6GIxNSVEuI0jAqqI3GJB0vg2M3PEDFOgqxSlik/yqT0Jnw3Nq9IbGG6hqeImKp4MuAjCuo41y+t+q5iLUENYcZxrYGK3+n1/qlpQWu2uT25J8y/8nkQETgXBOaw2jgXZRuZhvoTLxNTCFzKvmPLlDpMXDZWYLwY8/aBNYzToYPdOZCh3aoL4hJfS3Q0NDkEVLsxA== X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 31:OtYEMKV92/In81qyNgOmmd42VmOXcL0E/WtGEnklzDWtkLxDVPLRr8bzjZHiKdBIB5SPaUjZvKwBs7v3EVfBRoODH5iEWSdT1cq5f3S225o70jeV7B3xCTNZ3R/1jaKld5xj4AsA0dnpue5EYUx04JuahrtMyhBvBY16F2bFq0M28AxESktgsgq0b7TYT5R8vUUaZGz/Ar6HatCBvmKyNyWSHy3vtrEUWsQMehrHsCSwhkPeNaxt1qRK7GXcj7GU7Azn7+kxLxj9q8Ufuhu1rQ==; 20:U1FDF8iBhffngXMnwkDQ4YOe+SQT4I3NbMeJXLkUs2n9GaSnitrV7N6a9tI6ktnmaUZSnMh8c3AsAzk2iv86IYs64RFzI+KJFIH3QVjiXFYZJZqNXOiQYytzjVXtWRoUOKnHxhID1Xn+vY1XvlGZR12tTSkkDNBmrZdy5v06EinqgNgECDiCuYstD+xmhhX+1kobp8DeDVLt4z+b8h27LCdx4DKNajo6pyQlmCCrfJX+KF4iuFMQopJaud8sVTgAjvd/RRYr6iLq7UzMl72XI4/jMN/FAAJUizr9MIF30PsxWzwRXPLXNMWmCVNYEuLj3fxxjuAgEofGOMoa7AZ1WDUiMNu3eANUmrX+PhsgASfsLGgPFjZdDWZ5flHOfK9dxVZAB0UPftRM9odRhialN6pG7xFZzisLLJDXckbkQSasPRWpxpsSbK3hatS3fFEKSzrsqIT9ePyyYK2DyqCUmOmHe9m9/iLXgMtZeguc5/gpUw4cUKAxUxi+eSbR6ny/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(20170203043)(5005006)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:AM2PR07MB0946; BCL:0; PCL:0; RULEID:; SRVR:AM2PR07MB0946; X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 4:yCtWnFelhR3Gfrg91GvgXjs/UJaz/6ZIJ9uihTgXJKhZt1d/tBSZS2+sBQL0lp0QvDSlEHAPjzOJUpgy7xq+B2C/KQcRCDweuBvxTKy/wGcoZbfEz4hOON19PmOV+yMPQTrVUJ56l875yqSr3PwRzZizJ12CZycKop9MRVXSN5CDa4Wi1PLWG9zFFQxGHRaDxLuW5PvxmFg0GsAt/1fmxJWsFHGm1Mv2PdMuAgyB6oXGwCKJAuDcUkpLDJNk4zPgrkHDU0Xl2XgN+BW2BPHB73byDkExeiHbGRCKQeCMRu5/4q6m2TwDHLeughNle2ScmTMq037dUFgVyxmFW4omGPD6uMKeNzoTuXfwNKaUNsWZtJinc7i2x6coeDa+YhWZ+VpbplW/PR904sR22WaJ4HYngn/WygzO0+xaYj0oUZvmolqvl0YVaT25FMQ4vmnuCRmk0MBivapJkdkwqVrspJsGXsbmBJ8UoxM32aqvbBpniHDpoI+N7v0hYnbGeJu+8wmDSpgzYrQaZxbdYGcqEfx/UAmWuzOZuA+rwPjjNZOMtoGeFwdFusoWDGGuz5qoM0JrW2s18XD5Rpgf7bqeInRt5hJLCGLwyg6lT1/XH+s6hA17l1lqU1EniUdbWTbeqW6thrDBPFFFUmELR+u98fmsb2EQN0sGvQWnC8JhTi+fvq/ZeeFc5fjnxLXa5bTp X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(24454002)(252514010)(189002)(377424004)(199003)(90366009)(3846002)(6116002)(6916009)(2950100002)(33646002)(6666003)(230700001)(31696002)(38730400001)(54356999)(86362001)(23746002)(4326007)(83506001)(25786008)(229853002)(50986999)(68736007)(81156014)(8676002)(81166006)(76176999)(6486002)(2906002)(106356001)(36756003)(65956001)(66066001)(105586002)(47776003)(65806001)(31686004)(101416001)(42186005)(64126003)(53546003)(6246003)(50466002)(7736002)(110136003)(5660300001)(93886004)(65826007)(305945005)(4001350100001)(97736004)(53936002)(189998001)(92566002)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0946; H:[159.107.197.235]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; AM2PR07MB0946; 23:jdNUFXHmJp6QGH4gzIV5dUZ6yInAlfqhK1N47?= =?Windows-1252?Q?st2ActYWZUntJbdQ/ob+31TQOplTj7kIt1pbfyvr7GiLU8v6KIPMJqlg?= =?Windows-1252?Q?moAt9dtJxbgQ4EW023iAtfbs7gitjvBaN3w3Y11s6ltBmKMY6prqBErD?= =?Windows-1252?Q?Hsom4nTT+TRjICOUoVvEIHHeRQuYd7IdXjJdhq0EhU+C+K6ftVLEb1KL?= =?Windows-1252?Q?bBKGQIesWFZijbUS4sucuwr3El//NuhNdPLTpEcoqH8L0KD8hUQbUr1M?= =?Windows-1252?Q?3lBed4pcY5sjJoDqUzojI5vY468zhq5a9FPlh43vWGTilZ5gt2ZM5J/6?= =?Windows-1252?Q?8ufK2H59kWegWElCOhfYUTMEzFZNbW+Ardnzd8LLErXS+RTbl4s4hwC5?= =?Windows-1252?Q?QjjVITAlmCOQOIsnC1CDPQkXd8gV3qAWEwuL9u9giONcc4r9N3yhx9pq?= =?Windows-1252?Q?Y8xUgSPIsaE3hQCzmA2FU4EYeSMim/fQkK+FaAErT++KmNdQzXwIl/sE?= =?Windows-1252?Q?R3t34TnF9+/MZ+8ndS1fwZ44UEaf2y6gyJrNelHmotV65VG/aHERvjaG?= =?Windows-1252?Q?EfqTyqZE/6huieBFIcDv+EOlzJvM872g3By4Xa92H0o7oGTfOdyJX0dh?= =?Windows-1252?Q?h/mkjiMZsv9zO4FHgG1rMJM31u8h+6jQVW9vSBm/n0rRFPViZAKCxJCQ?= =?Windows-1252?Q?cnADYNvYV1TCkaDxUdU1eSuAfcynxZHBryX6sWvZR+piehWeYyDrBFTf?= =?Windows-1252?Q?RRCGNv9h2HIPqgkLKdJ5eIxoO1/YLfIq7oXIGVnQczJXR6AlZKCva47f?= =?Windows-1252?Q?S3Tuo7YQj0vAeGoVb3AmkaZycG/YOZAiAjAvGnVZ+5VU+qb4Rh+J6ZvX?= =?Windows-1252?Q?O+Nwn77YHlG8uBZSo+vUkXVsyOD+j9sEcuUz2fFdLDKhH5Gjjziq1j+0?= =?Windows-1252?Q?Qt6gk5Eqc9CkluCRmnwFx2sbpkqhSptJveZBlfdERgpJDoQyJBXMdXqP?= =?Windows-1252?Q?rZmisy0kY6jNZOX7jm4nJQ0pfUPYKwRLBmlSo0EJO4M7E1FyYtOluAId?= =?Windows-1252?Q?qzLRoAsZ0GqrAW5ZUrGwxHMOI0315XyFTo/xoIVAsoekweXf7fnM8el2?= =?Windows-1252?Q?ag/RZdvj2banAkN7Y7vh5ETW6OHC22lojhYJAG+8UknIcbCVOQO4BPjl?= =?Windows-1252?Q?n9zq2EWb5kVp/yjT2UTDZQO2Qf0uL+Dmal8qSBiWdijqd5BrX3BTNHMU?= =?Windows-1252?Q?HaswBjbykQNOxUnB65eTiCEBalG4UOEsZPzv/rC5dpx2kt7j+Tokc/Qw?= =?Windows-1252?Q?rh9ImrkPsXu3KbbAaOTSLa1WSWDa/1p4MhnL5lrhQ5YQhd1MIq9YumW1?= =?Windows-1252?Q?+jWBKt8PK2YsmBfc2DM1mMM1oZGkG1a9Ug3HLWUZO84QWmyfipf6x8cu?= =?Windows-1252?Q?WP8jLCb+6eNKvFjo5afUsyQZu1W10Yto25T1lXakjwf1/im7pVHL7CX5?= =?Windows-1252?Q?eS70KBIVW51llijcu6WgPnubcoSlOdBmEAIexVbAf4IrkIWXmeoQAuuR?= =?Windows-1252?Q?SYL4Ax2imYgPMY=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 6:KBjEMzlqODpy264Hv6G4OmT8o258mD006FBBZWmHzJLC1UPzF1YCNcMz8UKkYH04iKlOy3GlL+9xCSClU0XwQXgRDrgRp84rVOdeJE1VWjvYKmDjdcMu5SsoiM7pH9DV3YykEajHR1kxvKrrT2j/D0rWuUPZx2d5MCi3bYJk4d/K4+tWLJUBuoCM6GLECtoQs4amB0bB+pABbKde96Hh33QdvTXTC697k8qEdza1QmL1KZ7hu0yMPj1iCbpCrR4zWYxJl+++bNmuzAhlcc2952fvlOqXmfFvieVS/f16njatlDexv/I8JevXjKhihyE4vdlrNerzYfqUljOIAj0s2Mg0mR7a7on4YZ7iEdzwuZwMBtCtpVvYVFsxZVj/icUGnpB9F5j44QQmQ7gpSTdENw==; 5:2ag+LhpOpnFzAfYjwWTJrF0idmxGZiAjtJ57i3W1j3qZE1T7gIl5tP8VcQs250qP8JGqxciHW+n8t5J+a00kWZOwadWQNsKmursMPShAgrkUkHYpkFHXN881W6zxck2+FaAojGFpQnykHYyFh5Ia8iOXYQFwTuS24YmFcqCKmHA=; 24:hYwyzKDZHF350ym6XFGr71IhiGQKgLo91fdOWv13Uv4O6M3xEdCROryKaTWgzpDeFYjX4WzrqpxzTnVoQzoXhTIEP3rLc8Git/DA/17KMJA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM2PR07MB0946; 7:o9yoe8+e7g91DUCS/NTnGJxtUpxfyh2c9J3j7c+k1LgoRJL9WYXdrnyZa7snqMRoKKqzEAruWPhjrQBDdM4zbrqLJt0syCaOH4hoBt858kxGy51Uh8xCAufsrBthA1BCjNBhvGPYxDlONGPIbDkwr9BSWtrUYBonPalywn8fpGem4l8ZMK2dmnScQaPCZjo9S1HT6mhW2HqTEuGtN9w6ljeI305UeEQd77y891PE7r6SRb8oIatZZpUFglBu7qcfrqytmaiZipJLweBgs2PhluyMzDQK9TQgMPNhE70igEaPnkVaC1XXstVe1yQteqxBGSxJDoYV44OBMWaVfRF3RLre8FIHFqOJWP7lyUxNmJaD3msPcqPQyCJU1btXf9SyQR1DP7Zx6IQAMVLTK7gRT299Nbe+aMrCcXOqDV6GM1X5zqbAncVy3u9KNesubREMV1Ow0AZLQI0lQ36JKO8s+uJfvTdcqkKdFKHsI2SJQrKhLvKMm2Z/mZt+SBN0Mf22qWqSD1Qf5iw2QNfLHmM0ig== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 17:13:29.2690 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0946 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2K7je69dTMiDL7sEbW4sGoum0XfrgOM DkweS5b8ZPLYdPkOYwBTFJdNSmpOZllqkb5dAlfGhQf7mQoa5Ste/97G2sD4ULyLkZNDQsBE 4vyTayxdjFwcQgLrGCXuH9zEBuEcZ5R4fP8fE4jDItDLLHH92F9mkBZGgTiJnWsWskJU/WWU 2LBnBwtIQljASuLXwnZWEFtEQFni4oSfUHP3M0tMObiaESTBLKApcfXpNnYQm03ASGJq/3mw Zl4Be4mfK0+AbWARUJE4++ATWI2oQIzEyz2roGoEJU7OfAJmcwIt23mqHehWDqCZ9hIPtpZB jJeX2P52DjPEbwoS1zdfB7tBQqCDUWLa3xNgvUICGhIPL/xlhSjylfjeupoJxr7e+pgdomEF m8TFPzeYIJyLbBJXT62HqsqWONX7iwXCtpJ4/es7I0TRciaJtq2T2CCcL6wSk47MY4OokpF4 smI9M0RiApvE5TNX2SEOSZXYcqOFbQKj5iwk/81C+GkWkp8WMDKvYhQtTi0uzk03MtJLLcpM Li7Oz9PLSy3ZxAhMEwe3/LbawXjwueMhRgEORiUe3oL+GRFCrIllxZW5hxglOJiVRHjrlwKF eFMSK6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYLQ87csnbXpV dtqSdXsYZhb3hXo8WHZgxk3L5U+if28WYgqYK7rryD2ZlI07Fwduz5y844r+Vp+WL3eUvB3f TnF+Odu9oMut9J5vig9HxpuKt+xP8g1uTBVZ+2dSfMWlWad28HbdtQpVeZHJN/9J8dbk5k3u YjGi3VXue5T2Pbk8xeH0sTaZ3UFKLMUZiYZazEXFiQDegfCBDwMAAA== Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] Conditional import -possible ? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:14:10 -0000 Thanks, for the help. My ideal solution would be to have if-feature on imports, and for the tools not check anything that is excluded by if-feature; as if it was not even there. My practical solution will probably be to refactor the modules and move such conditional imports and references into separate modules that will augment in whatever is needed. This way if I don't need modA, I will just remove both modA and modB-refAugmenter. Nice for the customer, somewhat ugly for the designer. module modA { prefix modA; leaf leafA {} } module modB { container base { ... } } module modB-refAugmenter { import modA; import modB; augment /modB:base { leaf refToA { type leafref { path /modA:leafA ; } } } regards Balazs On 2017-02-06 17:58, Ladislav Lhotka wrote: >> On 6 Feb 2017, at 17:43, Balazs Lengyel wrote: >> >> If I have a product that does not support modA (actually does not even want to know it exists), as I understand the product still has to >> >> - have the modA yang module available to run PYANG - bad, but acceptable >> - have the modA on the network node / yang-server itself, to be able to run my YANG/Netconf SW stack, which will result in the unsupported modA showing up in ietf-netconf-monitoring and ietf-yang-library (although only as an import). - not acceptable > It depends on implementation but, strictly speaking, it is not necessary that modA be present on the server. It should suffice to include it in YANG library, as I suggested. It is then up to the client to get modA if needed. I don't think it is a big problem. > > In YANG 1.0 it wasn't even clear whether modules that are imported but not implemented have to be included in hello. > > Lada > >> So while this maybe a question best solved by tooling, if you can think about any other design pattern to achieve this more cleanly I would be grateful >> >> regards Balazs >> >> >> >> On 2017-02-06 17:19, Juergen Schoenwaelder wrote: >>> On Mon, Feb 06, 2017 at 04:50:09PM +0100, Ladislav Lhotka wrote: >>>>> On 6 Feb 2017, at 16:36, Balazs Lengyel wrote: >>>>> >>>>> I agree that clever tools could and SHOULD ignore unused imports, but will they? Will you ever modify PYANG ? Will my unnamed SW provider modify xxx? (Was that a rethorical question, maybe) >>>>> >>>> I share your concern, in fact the import *is* used in modB. There is no indication in 7950 that contents of statements that happen to be disabled via "if-feature" can be syntactically incorrect. >>>> >>> Perhaps there is confusion between _parsing_ and _implementing_: >>> >>> - To _parse_ modB, you need to be able to resolve import modA since >>> there is YANG syntax that only makes sense if information from modA >>> is available. It should not matter to a generic parser whether >>> certain features are enabled or not. >>> >>> - To _implement_ modB without the features that require modA, you are >>> fine to do so without implementing modA. (In this case, the import of >>> modA starts to look like an unused import.) >>> >>> What exactly is the problem with this? >>> >>> /js >>> >>> PS: If we allow if-feature on import statements, someone would have to >>> code YANG parsers to enable them to validate conditional imports >>> for any possible combination of features to ensure that the >>> imports work out in all possible cases. >>> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Feb 6 09:40:46 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7780F1293D8; Mon, 6 Feb 2017 09:40:44 -0800 (PST) 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, MIME_QP_LONG_LINE=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 aAdJyG_Rrcrg; Mon, 6 Feb 2017 09:40:43 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 4A09A128B44; Mon, 6 Feb 2017 09:40:43 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id f144so7333239pfa.2; Mon, 06 Feb 2017 09:40:43 -0800 (PST) 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 :mime-version; bh=lvxqx/JCVuWJClXZu/SqCaFwbMqda/i8zHN6kZ7ufYg=; b=Tda3S69P6kBoCDTiEUgQYixn9Os77IZnALMao+lMTcc/SgleN2mANyKtcZ+kVOl6rq ehiaQH5ACDGtsMv8unmD4dzg01zpCpDrIybvoy69IyU8YKobY9OWtBZ6VQXiYRYL7ElM /nBRJ7SvIOgk1oN2Gev2XkkorHGsG93QOdmVrZSC6PsF1Z3EbJZONBd5vfR3ZfoWYYRJ BpMaiSAFktJX0QBksRUioWJ+PoPNv0Fh2SQmi5dQ+fbZ3v+5VawGEqBio4BP1heIrtFj 4j0SVHrjY9+lO7/aJ4RI+B4JY2vdAKK3fUkz4TjjohdQE3GyzTbV3B8WATuWTWG9DNYq 4+Yg== 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:mime-version; bh=lvxqx/JCVuWJClXZu/SqCaFwbMqda/i8zHN6kZ7ufYg=; b=hz3oFCDqahLPcQTT892Ysypo9pOKW2v5hG8hPIofpZVsYt+n1DwCxifpvmFdfLKyHS NL6+XVc8mtxJxPTjzkve3NX5iTPh/hH9vnH9HvmTT7xLAdtVfeQd9j5UqXGWLQLP2l27 IlHgoWppXFVS4eBGSKAtHmP7ZH60fsyNcWhhgGQTv/Bf640i4NLNVuWRAvvnZ9hcQp5g RSj3H8CaJoGi4WgQWqgyJccL1d8bZBtwcy3BVhAOGqJ4TeP9iWQX9UOnvuQH6Nk1K5Q+ 49dXIcE1cEB8Y0hGZjZxW8mZ7D7TKjQ87JcBSdfPAp/fVerugHh8g8ExWj02bPIp5Tfe Ez0Q== X-Gm-Message-State: AIkVDXJVRooem/ARyewzjOZk7HcTSKuVw5tGr4KbOsAjTc7fyZzVVGGryDFn4YE00pTLoQ== X-Received: by 10.99.67.6 with SMTP id q6mr14591134pga.156.1486402842893; Mon, 06 Feb 2017 09:40:42 -0800 (PST) Received: from [192.168.255.248] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id d29sm4170359pfk.83.2017.02.06.09.40.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 09:40:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Mon, 06 Feb 2017 09:40:40 -0800 From: Jeff Tantsura To: Message-ID: <7E238729-5E7B-4268-ADB0-352B9F7A9DE8@gmail.com> Thread-Topic: YANG Doctors review for draft-ietf-rtgwg-yang-key-chain-13 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3569218841_36721848" Archived-At: Cc: 'rtgwg-chairs' , draft-ietf-rtgwg-yang-key-chain@ietf.org Subject: [yang-doctors] YANG Doctors review for draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 17:40:44 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3569218841_36721848 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Dear YANG Doctors, Could you please review draft-ietf-rtgwg-yang-key-chain-13 draft, it is ready for RTGWG LC. Many thanks! Cheers, Jeff --B_3569218841_36721848 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear YANG Doctors,

 

Could you please review draft-ietf-rtgwg-yang-key-chain-1= 3 draft, it is ready for RTGWG LC.

<= span style=3D'font-size:11.0pt'> 

Many thanks!

 

Cheers,

Jeff

 

 

--B_3569218841_36721848-- From nobody Mon Feb 6 16:52:49 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F15512954C; Mon, 6 Feb 2017 16:52:47 -0800 (PST) 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, MIME_QP_LONG_LINE=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 VFNcKo1r7iGI; Mon, 6 Feb 2017 16:52:45 -0800 (PST) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::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 87C0712955C; Mon, 6 Feb 2017 16:52:45 -0800 (PST) Received: by mail-pf0-x244.google.com with SMTP id y143so7945710pfb.1; Mon, 06 Feb 2017 16:52:45 -0800 (PST) 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=X1JBfgbaaPkpS8e8STIUABTWrEhtFWXX+HHAcBrAiUk=; b=MAFxhhaieu0Nb4E0bzja6cq4xQpINpKpOR/0uejZgc0sqCnqGuvQhuMgo+pKGBuued GA10QGiNE6ZxIUuvsLLGAXbMpBxeyzlzElZ5j+95s/xGxCxfH4TyIeyxkPmW6VGL4O93 bdN+KKq9Wnn94zh+xH88LR4VWIwzGqCr1RN/l4fuWkmkdtKAi++g9sjSdcP+2Uqd7SSP ef5gf+LXfh7fjjsRJ+tiJPanbhc7aSeJ/vLnezi0LjnlCl2wrwx48/98d9ffKr2vpdU4 jLgakDQuhLFetDkyNPdj0TLF67cQ5iyHdBxtVA5KWbHWYgvr2s8XjaNLMz15qV23lnY7 +D1A== 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=X1JBfgbaaPkpS8e8STIUABTWrEhtFWXX+HHAcBrAiUk=; b=ZCKahI/jErVGmxxW9dAxQ/Hr2Mu+LN/Fd8861eXz+G/wUHVzbvZc11P006B88GNjd4 74YdX075FgTIiTwQ9xRF5BmLzFsg9zBBES11PFeP+BQMWYcQl1ld4bHBsiL2b8Kvn7Wn A0AbMhZVAxrsOzA7zZUd1gslDERPaOX2m00w0H/XFdDgJCOsssNdvTW+ZxwivPRYvuqL zQ9uEHwgirRT2Pa3gOfONPCIYAPlS2DHVYwdStWjJWMDvvxBqk5lW/YOhYaGdf2yKM39 Ez5W4Y8t5Gx5WEDz/JPx0CD3LaSiZWrgT6fMZp+cEEhKRAsPjsPAAH4vtx6ilGMekB0V S9iA== X-Gm-Message-State: AIkVDXLkrRsDAdsE4Gsk7xxjeQz3BmqtlngGkkdqdrytUAu/P/ZYXh4HWHweM1jmS2FW9w== X-Received: by 10.84.200.200 with SMTP id u8mr21393780plh.98.1486428765103; Mon, 06 Feb 2017 16:52:45 -0800 (PST) Received: from [192.168.255.248] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id z70sm5519361pff.26.2017.02.06.16.52.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 16:52:44 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Mon, 06 Feb 2017 16:52:40 -0800 From: Jeff Tantsura To: Xufeng Liu , Ladislav Lhotka , "draft-ietf-rtgwg-yang-rip.all@ietf.org" Message-ID: <1AAA038F-6C88-46AE-B1E4-B1D79CBD3F75@gmail.com> Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-rip-02 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 00:52:47 -0000 Hi Lada, Thanks for the review. Does update address your concerns?=20 Thanks! Cheers, Jeff =20 On 1/16/17, 13:35, "Xufeng Liu" wrote: Hi Lada, =20 Thanks for the review. An updated version https://tools.ietf.org/html/d= raft-ietf-rtgwg-yang-rip-03 has just been posted to address most of these it= ems. Please let us know for any further issues. =20 Thanks, - Xufeng =20 > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Wednesday, December 7, 2016 11:01 AM > To: draft-ietf-rtgwg-yang-rip.all@ietf.org > Cc: yang-doctors@ietf.org > Subject: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 >=20 > Hi, >=20 > I was assigned to be the YANG doctor for this document. Here is my > review: >=20 > **** General comments >=20 > Overall, the module is in a good shape and integrates nicely with the= core > routing data model [RFC 8022]. >=20 > The I-D text is rather scarce, apart from the module it essentially c= ontains only > boilerplate stuff. Some information about the context in which this m= odule is > supposed to be used, design decisions etc. would be certainly useful. >=20 [Xufeng]=20 Added sections 2.1 to 2.7 to describe. =20 > A non-normative appendix with a configuration example (instance data)= would > also help people that are not fluent in YANG to understand what data = are > included in this model. >=20 [Xufeng]=20 Added Appendix A. to show an example. =20 > Some parts of the model =E2=80=93 "distribute-list", "redistribute", "bfd", > "authentication" on interfaces (or at least the "key" list) =E2=80=93 are p= robably not > specific to RIP and could be used by other protocols as well. If it i= s so, it would > be better to model them separately as general mechanisms. >=20 [Xufeng]=20 The "bfd" and "authentication" sections have been re-used by importing= the corresponding models. The ways that we use them are based on the recomm= endations from the corresponding models. For some portions of "distribute-li= st" and "redistribute", we previously re-used some references from https://t= ools.ietf.org/html/draft-ietf-rtgwg-policy-model-01, but that draft has expi= red and got out of synch with the other current IETF model drafts. Moreover,= some of the "redistribute" are not common with other protocols, and may be = better to specified in this protocol specific way. =20 > Documents containing YANG modules that are imported by ietf-rip shoul= d > appear among normative references. One way to achieve this (which is = also > useful by itself) is to include a table of namespace prefixes, see e.= g. >=20 > https://tools.ietf.org/html/rfc8022#section-2.3 [Xufeng] Added according the reference. Thanks. >=20 > **** Specific comments >=20 > - Matching identities is done in the old YANG 1.0 way, for > example: >=20 > when "rt:type =3D 'rip:ripv2' or rt:type =3D 'rip:ripng'" >=20 > This is fragile because the identities are matched based on > string equality, so the result depends on the choice of the > namespace prefix. Unless there is a strong reason not to use > YANG 1.1, this is much simpler and more rubust >=20 > when "derived-from(rt:type, 'rip:rip')" [Xufeng] Done. Thanks. >=20 > - In "redistribution", the must expressions are outright broken, > e.g. for IS-IS: >=20 > must "../../../../../rt:control-plane-protocol" > + "[rt:name =3D current()]/type =3D 'isis'" { ... } >=20 > First, the ietf-rip module also needs to import ietf-isis, and > then the must statement can be rewritten like so: >=20 > must "derived-from-or-self(" > + "../../../../../rt:control-plane-protocol" > + "[rt:name =3D current()]/type, 'isis:isis')" [Xufeng] Fixed. >=20 > - Some descriptions could mention that the parameter (feature > etc.) only applies to RIP. For example, in >=20 > feature interface-statistics { > description > "This feature indicates that the system supports collectin= g > per-interface statistic data."; > } >=20 > I would add "... related to RIP." at the end. [Xufeng] Changed for this and some other descriptions. >=20 > - Maybe it's absolutely clear to experts but the name and > description of the "neighbor-configuration" feature look like > the feature can make neighbors remotely configurable. I had to > look up where it is used to find out what's the real > meaning. Perhaps something like "explicit-neighbors" might be > easier to understand? [Xufeng] Changed. >=20 > - The name of "no-supply" leaf looks strange. I checked a couple > of CLIs and they use "passive", "passive-interface" or > "send-options" for preventing RIP updates from being sent. [Xufeng] Changed. >=20 > - In "split-horizon" leaf, I would use "poison-reverse" enum > rather than "poison". [Xufeng] Fixed. >=20 > Lada >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C =20 From nobody Tue Feb 7 04:37:57 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36681129BA6; Tue, 7 Feb 2017 04:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 g2fy7PieUIMu; Tue, 7 Feb 2017 04:37:53 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 17847129B94; Tue, 7 Feb 2017 04:37:53 -0800 (PST) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 97ADD1821394; Tue, 7 Feb 2017 13:37:00 +0100 (CET) From: Ladislav Lhotka To: Jeff Tantsura , Xufeng Liu , "draft-ietf-rtgwg-yang-rip.all\@ietf.org" In-Reply-To: <1AAA038F-6C88-46AE-B1E4-B1D79CBD3F75@gmail.com> References: <1AAA038F-6C88-46AE-B1E4-B1D79CBD3F75@gmail.com> Date: Tue, 07 Feb 2017 13:37:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-rip-02 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 12:37:56 -0000 Hi Jeff, Jeff Tantsura writes: > Hi Lada, > > Thanks for the review. > Does update address your concerns? Indeed it does. Lada > > Thanks! > > Cheers, > Jeff >=20=20 > > On 1/16/17, 13:35, "Xufeng Liu" wrote: > > Hi Lada, >=20=20=20=20=20 > Thanks for the review. An updated version https://tools.ietf.org/html= /draft-ietf-rtgwg-yang-rip-03 has just been posted to address most of these= items. > Please let us know for any further issues. >=20=20=20=20=20 > Thanks, > - Xufeng >=20=20=20=20=20 > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Wednesday, December 7, 2016 11:01 AM > > To: draft-ietf-rtgwg-yang-rip.all@ietf.org > > Cc: yang-doctors@ietf.org > > Subject: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 > >=20 > > Hi, > >=20 > > I was assigned to be the YANG doctor for this document. Here is my > > review: > >=20 > > **** General comments > >=20 > > Overall, the module is in a good shape and integrates nicely with t= he core > > routing data model [RFC 8022]. > >=20 > > The I-D text is rather scarce, apart from the module it essentially= contains only > > boilerplate stuff. Some information about the context in which this= module is > > supposed to be used, design decisions etc. would be certainly usefu= l. > >=20 > [Xufeng]=20 > Added sections 2.1 to 2.7 to describe. >=20=20=20=20=20 > > A non-normative appendix with a configuration example (instance dat= a) would > > also help people that are not fluent in YANG to understand what dat= a are > > included in this model. > >=20 > [Xufeng]=20 > Added Appendix A. to show an example. >=20=20=20=20=20 > > Some parts of the model =E2=80=93 "distribute-list", "redistribute"= , "bfd", > > "authentication" on interfaces (or at least the "key" list) =E2=80= =93 are probably not > > specific to RIP and could be used by other protocols as well. If it= is so, it would > > be better to model them separately as general mechanisms. > >=20 > [Xufeng]=20 > The "bfd" and "authentication" sections have been re-used by importi= ng the corresponding models. The ways that we use them are based on the rec= ommendations from the corresponding models. For some portions of "distribut= e-list" and "redistribute", we previously re-used some references from http= s://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-01, but that draft ha= s expired and got out of synch with the other current IETF model drafts. Mo= reover, some of the "redistribute" are not common with other protocols, and= may be better to specified in this protocol specific way. >=20=20=20=20=20 > > Documents containing YANG modules that are imported by ietf-rip sho= uld > > appear among normative references. One way to achieve this (which i= s also > > useful by itself) is to include a table of namespace prefixes, see = e.g. > >=20 > > https://tools.ietf.org/html/rfc8022#section-2.3 > [Xufeng] Added according the reference. Thanks. > >=20 > > **** Specific comments > >=20 > > - Matching identities is done in the old YANG 1.0 way, for > > example: > >=20 > > when "rt:type =3D 'rip:ripv2' or rt:type =3D 'rip:ripng'" > >=20 > > This is fragile because the identities are matched based on > > string equality, so the result depends on the choice of the > > namespace prefix. Unless there is a strong reason not to use > > YANG 1.1, this is much simpler and more rubust > >=20 > > when "derived-from(rt:type, 'rip:rip')" > [Xufeng] Done. Thanks. > >=20 > > - In "redistribution", the must expressions are outright broke= n, > > e.g. for IS-IS: > >=20 > > must "../../../../../rt:control-plane-protocol" > > + "[rt:name =3D current()]/type =3D 'isis'" { ... } > >=20 > > First, the ietf-rip module also needs to import ietf-isis, a= nd > > then the must statement can be rewritten like so: > >=20 > > must "derived-from-or-self(" > > + "../../../../../rt:control-plane-protocol" > > + "[rt:name =3D current()]/type, 'isis:isis')" > [Xufeng] Fixed. > >=20 > > - Some descriptions could mention that the parameter (feature > > etc.) only applies to RIP. For example, in > >=20 > > feature interface-statistics { > > description > > "This feature indicates that the system supports collect= ing > > per-interface statistic data."; > > } > >=20 > > I would add "... related to RIP." at the end. > [Xufeng] Changed for this and some other descriptions. > >=20 > > - Maybe it's absolutely clear to experts but the name and > > description of the "neighbor-configuration" feature look like > > the feature can make neighbors remotely configurable. I had = to > > look up where it is used to find out what's the real > > meaning. Perhaps something like "explicit-neighbors" might be > > easier to understand? > [Xufeng] Changed. > >=20 > > - The name of "no-supply" leaf looks strange. I checked a coup= le > > of CLIs and they use "passive", "passive-interface" or > > "send-options" for preventing RIP updates from being sent. > [Xufeng] Changed. > >=20 > > - In "split-horizon" leaf, I would use "poison-reverse" enum > > rather than "poison". > [Xufeng] Fixed. > >=20 > > Lada > >=20 > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20=20=20=20=20 > > --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Feb 7 11:32:29 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367A129E52; Tue, 7 Feb 2017 11:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 LHOTV5e4Ushw; Tue, 7 Feb 2017 11:32:25 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::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 9F0D4129E4E; Tue, 7 Feb 2017 11:32:25 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id v184so12873009pgv.1; Tue, 07 Feb 2017 11:32:25 -0800 (PST) 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=DeXaVFeODQKctCvGcU7K/oWfG9z6/wQOwRIBQpvKe+Y=; b=i2kcWAoSCC3/A/X+HV3Pm5s7ibvO3/Vh5u8F5WdjCat7zkVU8X/Xv5Id122rE5NHAY zTuz+PIKCHzZ5wkctxmW3BU8/ND+/XyPTcDnrSlRR5cyjfLsjdcOklFPZ7D4EDIZ3EF2 b7d0FDDUOserHE8D3X+Sug8mH2Bx+d/Mx0jrLNg0kMG8SbyiB3m6RsenMix9G8f/Oy4I leYD+P9JGyevEmsAg5IhqcbY+F8hPWH7Qr/l1rLHw74yjkJSHQdVrbzys9jb8mODBm0d k+BKV3ODcFSXmyJpBOkKUuAka601eKEwZpQ3NYnXvP6/NVxRnPndoP9+ilaQm08TJloK /qBw== 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=DeXaVFeODQKctCvGcU7K/oWfG9z6/wQOwRIBQpvKe+Y=; b=Y3EF1o5ByeCosr0g9XmsXQjbAMwFBCogeiGUjg4ihN/2s1+evMeYE+9FmcFAMpDOSw cXOyvu8Vsoaw9+Rg//dIYvNCvHm+nfOyDk8aDJreOtEFe8VUyLorb7Cow3DQGmHHKZ4X 7P2AM741lOtGDo2Ti4lVCS1euKxkV23+EmtHTrYi/JaSPsMBe0Hun1tCP3jHamt/Aztk rQPO0blAKFgMFsqhRbA8F5gQonCfibIqROzrG0s0xJHIq+7x/h8aEXotJ2rQUwC0AgKG ecXRGMjL76G6D31P1uuLKaD4OZ9chOyDGwYC02LUG+jq6Tnzwgc1OhIBVfHqt/masEmz U4BQ== X-Gm-Message-State: AIkVDXK1DvelOcCzg6TUfSo0BsHmnCWvIbg3gM5K6ay/j/6l0cXnjjSxwNLI1j0RiXkMtQ== X-Received: by 10.84.194.37 with SMTP id g34mr28183595pld.105.1486495945136; Tue, 07 Feb 2017 11:32:25 -0800 (PST) Received: from [192.168.255.248] (107-1-141-74-ip-static.hfc.comcastbusiness.net. [107.1.141.74]) by smtp.gmail.com with ESMTPSA id z74sm13463301pfd.70.2017.02.07.11.32.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 11:32:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Tue, 07 Feb 2017 11:32:22 -0800 From: Jeff Tantsura To: Ladislav Lhotka , Xufeng Liu , "draft-ietf-rtgwg-yang-rip.all@ietf.org" Message-ID: Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 References: <1AAA038F-6C88-46AE-B1E4-B1D79CBD3F75@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-rip-02 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 19:32:28 -0000 Thanks! We are starting WGLC =20 Cheers, Jeff =20 On 2/7/17, 04:37, "Ladislav Lhotka" wrote: Hi Jeff, =20 Jeff Tantsura writes: =20 > Hi Lada, > > Thanks for the review. > Does update address your concerns? =20 Indeed it does. =20 Lada =20 > > Thanks! > > Cheers, > Jeff > =20 > > On 1/16/17, 13:35, "Xufeng Liu" wrote: > > Hi Lada, > =20 > Thanks for the review. An updated version https://tools.ietf.org/= html/draft-ietf-rtgwg-yang-rip-03 has just been posted to address most of th= ese items. > Please let us know for any further issues. > =20 > Thanks, > - Xufeng > =20 > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Wednesday, December 7, 2016 11:01 AM > > To: draft-ietf-rtgwg-yang-rip.all@ietf.org > > Cc: yang-doctors@ietf.org > > Subject: YANG doctor review of draft-ietf-rtgwg-yang-rip-02 > >=20 > > Hi, > >=20 > > I was assigned to be the YANG doctor for this document. Here is= my > > review: > >=20 > > **** General comments > >=20 > > Overall, the module is in a good shape and integrates nicely wi= th the core > > routing data model [RFC 8022]. > >=20 > > The I-D text is rather scarce, apart from the module it essenti= ally contains only > > boilerplate stuff. Some information about the context in which = this module is > > supposed to be used, design decisions etc. would be certainly u= seful. > >=20 > [Xufeng]=20 > Added sections 2.1 to 2.7 to describe. > =20 > > A non-normative appendix with a configuration example (instance= data) would > > also help people that are not fluent in YANG to understand what= data are > > included in this model. > >=20 > [Xufeng]=20 > Added Appendix A. to show an example. > =20 > > Some parts of the model =E2=80=93 "distribute-list", "redistribute", = "bfd", > > "authentication" on interfaces (or at least the "key" list) =E2=80=93= are probably not > > specific to RIP and could be used by other protocols as well. I= f it is so, it would > > be better to model them separately as general mechanisms. > >=20 > [Xufeng]=20 > The "bfd" and "authentication" sections have been re-used by imp= orting the corresponding models. The ways that we use them are based on the = recommendations from the corresponding models. For some portions of "distrib= ute-list" and "redistribute", we previously re-used some references from htt= ps://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-01, but that draft ha= s expired and got out of synch with the other current IETF model drafts. Mor= eover, some of the "redistribute" are not common with other protocols, and m= ay be better to specified in this protocol specific way. > =20 > > Documents containing YANG modules that are imported by ietf-rip= should > > appear among normative references. One way to achieve this (whi= ch is also > > useful by itself) is to include a table of namespace prefixes, = see e.g. > >=20 > > https://tools.ietf.org/html/rfc8022#section-2.3 > [Xufeng] Added according the reference. Thanks. > >=20 > > **** Specific comments > >=20 > > - Matching identities is done in the old YANG 1.0 way, for > > example: > >=20 > > when "rt:type =3D 'rip:ripv2' or rt:type =3D 'rip:ripng'" > >=20 > > This is fragile because the identities are matched based= on > > string equality, so the result depends on the choice of = the > > namespace prefix. Unless there is a strong reason not to= use > > YANG 1.1, this is much simpler and more rubust > >=20 > > when "derived-from(rt:type, 'rip:rip')" > [Xufeng] Done. Thanks. > >=20 > > - In "redistribution", the must expressions are outright b= roken, > > e.g. for IS-IS: > >=20 > > must "../../../../../rt:control-plane-protocol" > > + "[rt:name =3D current()]/type =3D 'isis'" { ... } > >=20 > > First, the ietf-rip module also needs to import ietf-isi= s, and > > then the must statement can be rewritten like so: > >=20 > > must "derived-from-or-self(" > > + "../../../../../rt:control-plane-protocol" > > + "[rt:name =3D current()]/type, 'isis:isis')" > [Xufeng] Fixed. > >=20 > > - Some descriptions could mention that the parameter (feat= ure > > etc.) only applies to RIP. For example, in > >=20 > > feature interface-statistics { > > description > > "This feature indicates that the system supports col= lecting > > per-interface statistic data."; > > } > >=20 > > I would add "... related to RIP." at the end. > [Xufeng] Changed for this and some other descriptions. > >=20 > > - Maybe it's absolutely clear to experts but the name and > > description of the "neighbor-configuration" feature look= like > > the feature can make neighbors remotely configurable. I = had to > > look up where it is used to find out what's the real > > meaning. Perhaps something like "explicit-neighbors" mig= ht be > > easier to understand? > [Xufeng] Changed. > >=20 > > - The name of "no-supply" leaf looks strange. I checked a = couple > > of CLIs and they use "passive", "passive-interface" or > > "send-options" for preventing RIP updates from being sen= t. > [Xufeng] Changed. > >=20 > > - In "split-horizon" leaf, I would use "poison-reverse" en= um > > rather than "poison". > [Xufeng] Fixed. > >=20 > > Lada > >=20 > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > =20 > > =20 --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 =20 From nobody Tue Feb 7 19:31:02 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE051297DE for ; Tue, 7 Feb 2017 19:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.226 X-Spam-Level: X-Spam-Status: No, score=-3.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, PLING_QUERY=0.994, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BhoKUE3i6wcf for ; Tue, 7 Feb 2017 19:30:58 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6229E12971E for ; Tue, 7 Feb 2017 19:30:58 -0800 (PST) X-AuditID: c1b4fb25-4bbfb70000006c88-9e-589a90eed51a Received: from ESGSCHC002.ericsson.se (Unknown_Domain [146.11.116.71]) by (Symantec Mail Security) with SMTP id 29.F7.27784.EE09A985; Wed, 8 Feb 2017 04:30:56 +0100 (CET) Received: from ESGSCMB105.ericsson.se ([169.254.88.39]) by ESGSCHC002.ericsson.se ([146.11.116.71]) with mapi id 14.03.0319.002; Wed, 8 Feb 2017 11:30:53 +0800 From: Hongji Zhao To: "yang-doctors@ietf.org" Thread-Topic: [pim] Hi everyone! I have submitted draft-zhao-pim-igmp-mld-snooping-yang-00. Could you please provide some comments? Thanks a lot ! Thread-Index: AdKBu7RqobgU0zVKR8yBaseQ5dIxiA== Date: Wed, 8 Feb 2017 03:30:53 +0000 Message-ID: <4425C5378D37A84E9AB4B38990B0839211CCDCD6@ESGSCMB105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [146.11.116.6] Content-Type: multipart/alternative; boundary="_000_4425C5378D37A84E9AB4B38990B0839211CCDCD6ESGSCMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyibvEXffDhFkRBkdfGlm86vjJZNG36wCj A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx5NguxoK9phUXP+xnbmC8rtfFyMkhIWAi 8enDbdYuRi4OIYF1jBJXW9+zQziLGSUWLJnHAlLFJqAj0dm9lRnEFhEwljj+sAnI5uBgFtCW ONbsClIvLDCZUeLO0mtsII6IwAxGiUuPdzJBNOhJXD50EKyZRUBFYuqRDjYQm1fAV2LGE4gF jAJiEt9PrQGrZxYQl7j1ZD4TxHkCEkv2nGeGsEUlXj7+xwphK0hM33CPEaI+X+L0190sEDMF JU7OfMIygVFoFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxihanFifl phsZ66UWZSYXF+fn6eWllmxiBMbKwS2/VXcwXn7jeIhRgINRiYd3Q+esCCHWxLLiytxDjBIc zEoivCv6gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUw Oiky9v1tFW6oZqm6f3mpcMl875O7Zvp7tS////HFRYNrVyTLizJ2TWs8n+LrXxaSVF551s3v TvUuhfVbgtfsYtxjsy2K8ZTeO515jcePZDIdtbx63C43OLD1VV8au4HKa3UGk2tPP32ffviI aM4JNYboP9+PzVp/WWHKvXkXL93rln3G6JfcpsRSnJFoqMVcVJwIAKZyYlmRAgAA Archived-At: Cc: Jeff Tantsura Subject: [yang-doctors] [pim] Hi everyone! I have submitted draft-zhao-pim-igmp-mld-snooping-yang-00. Could you please provide some comments? Thanks a lot ! X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 03:31:00 -0000 --_000_4425C5378D37A84E9AB4B38990B0839211CCDCD6ESGSCMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone I have submitted IGMP and MLD snooping yang model draft, and I hope to coop= erate with more people, I also need some more comments! If you have any issues about the draft, please send them to me, and I would= like to get more people to involve with these drafts. Name: draft-zhao-pim-igmp-mld-snooping-yang Revision: 00 Title: A Yang Data Model for IGMP and MLD Snooping Document date: 2017-02-06 Group: Individual Submission Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-zhao-pim-igmp-ml= d-snooping-yang-00.txt Status: https://datatracker.ietf.org/doc/draft-zhao-pim-igmp-mld-sn= ooping-yang/ Htmlized: https://tools.ietf.org/html/draft-zhao-pim-igmp-mld-snoopin= g-yang-00 Abstract: This document defines a YANG data model that can be used to configure an= d manage Internet Group Management Protocol (IGMP) and Multicast Listener D= iscovery (MLD) Snooping devices. BR/Hongji --_000_4425C5378D37A84E9AB4B38990B0839211CCDCD6ESGSCMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi everyone

 

I have submitted IGMP and MLD snooping yang model= draft, and I hope to cooperate with more people, I also need some more com= ments!

 

If you have any issues about the draft, please se= nd them to me, and I would like to get more people to involve with these dr= afts.

 

 

Name:       &n= bsp;          draft-zhao-pim-i= gmp-mld-snooping-yang

Revision:      &nbs= p;       00

Title:       &= nbsp;           &nbs= p;  A Yang Data Model for IGMP and MLD Snooping

Document date:      = ;         2017-02-06

Group:       &= nbsp;          Individual Subm= ission

Pages:       &= nbsp;           27

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-zhao-pim-igmp-mld-snooping-yang-= 00.txt

Status:       =   https://datatracker.ietf.org/doc/draft-zhao-pim-igmp-mld-snooping-yang/=

Htmlized:       https://tools.ietf.org/html/draft-zhao-pim-igmp-mld-snooping-yang-00

 

 

Abstract:

   This document defines a YANG data mo= del that can be used to configure and manage Internet Group Management Prot= ocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices.

 

 

 

 

BR/Hongji

 

--_000_4425C5378D37A84E9AB4B38990B0839211CCDCD6ESGSCMB105erics_-- From nobody Tue Feb 7 23:27:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17891299E6 for ; Tue, 7 Feb 2017 23:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.528 X-Spam-Level: X-Spam-Status: No, score=-13.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PLING_QUERY=0.994, 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, 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 rEc_Z9WFux8N for ; Tue, 7 Feb 2017 23:27:10 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C2A1296FB for ; Tue, 7 Feb 2017 23:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8645; q=dns/txt; s=iport; t=1486538830; x=1487748430; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Zz6VySWvaZYAhkrUwL6rZrM+dcQTkNXkhqg5hfbvcxI=; b=A7/S4C/np5BSvkH3QYh7L6oM2fEUI6CKH6BbQeEZxTv2q6OLJT0V2c1Y giaI8ZRuhHh/ZYEe7eB8506hU/TIutSgKpVCkgkhxW80VW+bY5brX0MML OktYVgqUU4cFXzMTj8NiWNBHs/HboReDGfphCNLqhUaXpbUne/HO30CJp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQB5x5pY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BQypfjWFykH0fkAqFLIIMHwEMhXYCgkxLGAECAQEBAQEBAWI?= =?us-ascii?q?ohGoCBAEBK0ELEAs7CycwBgEMBgIBAYlwDrIrK4soAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYZMggUIgmKKGh8Fj0OMLYZtiyWBe1OERIMthkaLDYgFHzh+HxMIFRU?= =?us-ascii?q?YJIR6gUk/NQGIfQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208,217";a="650500549" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2017 07:27:08 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v187R79B013974; Wed, 8 Feb 2017 07:27:07 GMT To: Hongji Zhao , "yang-doctors@ietf.org" References: <4425C5378D37A84E9AB4B38990B0839211CCDCD6@ESGSCMB105.ericsson.se> From: Benoit Claise Message-ID: <8fe1f666-3920-dd0c-4a1d-b46935b73fca@cisco.com> Date: Wed, 8 Feb 2017 08:27:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4425C5378D37A84E9AB4B38990B0839211CCDCD6@ESGSCMB105.ericsson.se> Content-Type: multipart/alternative; boundary="------------5661A2A71D9BB343519E46F9" Archived-At: Cc: Jeff Tantsura Subject: Re: [yang-doctors] [pim] Hi everyone! I have submitted draft-zhao-pim-igmp-mld-snooping-yang-00. Could you please provide some comments? Thanks a lot ! X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 07:27:13 -0000 This is a multi-part message in MIME format. --------------5661A2A71D9BB343519E46F9 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hongji, We have already some reviews under way, and I would prefer to use our resources for WG documents in WG LC. This is described at https://www.ietf.org/iesg/directorate/yang-doctors.html The YANG doctors are all volunteers. Below are guidelines for response time 1) WG document in WGLC: 2 - 4 weeks 2) WG document under development: 2 - 8 weeks 3) non-WG document: best effort (really) A list of assigned YANG doctors can be found at http://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history Now, if a YANG doctor wants to volunteer, as best effort, .... Regards, Benoit > > Hi everyone > > I have submitted IGMP and MLD snooping yang model draft, and I hope to > cooperate with more people, I also need some more comments! > > If you have any issues about the draft, please send them to me, and I > would like to get more people to involve with these drafts. > > Name: draft-zhao-pim-igmp-mld-snooping-yang > > Revision: 00 > > Title: A Yang Data Model for IGMP and MLD Snooping > > Document date: 2017-02-06 > > Group: Individual Submission > > Pages: 27 > > URL: > https://www.ietf.org/internet-drafts/draft-zhao-pim-igmp-mld-snooping-yang-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-zhao-pim-igmp-mld-snooping-yang/ > > Htmlized: > https://tools.ietf.org/html/draft-zhao-pim-igmp-mld-snooping-yang-00 > > Abstract: > > This document defines a YANG data model that can be used to > configure and manage Internet Group Management Protocol (IGMP) and > Multicast Listener Discovery (MLD) Snooping devices. > > BR/Hongji > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --------------5661A2A71D9BB343519E46F9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hongji,

We have already some reviews under way, and I would prefer to use our resources for WG documents in WG LC.
This is described at https://www.ietf.org/iesg/directorate/yang-doctors.html
The YANG doctors are all volunteers. Below are guidelines for response time
1) WG document in WGLC: 2 - 4 weeks
2) WG document under development: 2 - 8 weeks
3) non-WG document: best effort (really)
A list of assigned YANG doctors can be found at
http://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history
Now, if a YANG doctor wants to volunteer, as best effort, ....

Regards, Benoit

Hi everyone

I have submitted IGMP and MLD snooping yang model draft, and I hope to cooperate with more people, I also need some more comments!

If you have any issues about the draft, please send them to me, and I would like to get more people to involve with these drafts.

Name: draft-zhao-pim-igmp-mld-snooping-yang

Revision: 00

Title: A Yang Data Model for IGMP and MLD Snooping

Document date: 2017-02-06

Group: Individual Submission

Pages: 27

URL: https://www.ietf.org/internet-drafts/draft-zhao-pim-igmp-mld-snooping-yang-00.txt

Status: https://datatracker.ietf.org/doc/draft-zhao-pim-igmp-mld-snooping-yang/

Htmlized: https://tools.ietf.org/html/draft-zhao-pim-igmp-mld-snooping-yang-00

Abstract:

This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping devices.

BR/Hongji



_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors

--------------5661A2A71D9BB343519E46F9-- From nobody Thu Feb 9 08:34:29 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC95E129B9F for ; Thu, 9 Feb 2017 08:34:27 -0800 (PST) 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 TLyfFLkdIVpb for ; Thu, 9 Feb 2017 08:34:21 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 F2B2F129BBD for ; Thu, 9 Feb 2017 08:34:02 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v77so24810215wmv.0 for ; Thu, 09 Feb 2017 08:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language:disposition-notification-to; bh=6TId+pYHnhshJNSohD2zJ6HAmCUrYaOjS5pIPElytF0=; b=bfMEMjI5dvblYoV4DXjLkJiXGrlH8mQPPmeoCdPbeCmaMAXpJ0vWL+1tlJkXMDDu2j FCIQVlBbiWwSMtMvW5D5cb2uxSR34e3ujjNvlx8z4nQkDRiDsYiyqP9OYxxahkm8DgNa i2FyovRXhw3GLHLstJsR8qgiCtpex19N25Z0HNrbAVxaLxOIoCb++aO7JteJ/hEwyRDj jPua2CJYKgG1VUmxZMLdgo78XWJUeskiKPQ9Aesh8oGf7JuAk2SYt1LKakMeCAnUy/dr JvSGpq3cV2i397Cl6A4YBRVhTFcji+RSZF5XtjI8kZ683+DjNOZKQp4FIXMM2RY4YXSr HNjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language:disposition-notification-to; bh=6TId+pYHnhshJNSohD2zJ6HAmCUrYaOjS5pIPElytF0=; b=iHCYVggpyw1s18dH5xIqNSdWpnYKiqQqmCViKT/R/ApK1s7BYdu94cq3XHmD/V+CEl m3d1M7J/J8im/ad6+EBEyqYGQHv4x0/P1PgqG0qMOP9YzJOmp8Qu5UXTp1Kwh3Mv2scs AulpCY/u0R2T/fjA6JZD5QSmXfFFpXezpGakS8ewRcR3FfuC1fK4o+CQ+o3n75z3C0r9 Q0lbLtA4PHp+izC0vIBYGMkFiywiuiNv4tT6X50YMWgilnwD1MhiChmv7N6Qn8T4J8MZ ELeTstOB3yR3mit+LbX/194q4oBfx7vbyBqxPVAByKHCO55sW18dXxi/H4kjG87E4QOw idfQ== X-Gm-Message-State: AMke39nrjKC9aUdabvhq9D3I3GH7as19bCf4k4/nQQiDAc/wNKwKR0/brep0ma26tIpGaw== X-Received: by 10.28.48.7 with SMTP id w7mr3772190wmw.78.1486658041149; Thu, 09 Feb 2017 08:34:01 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340FFE.dip0.t-ipconnect.de. [91.52.15.254]) by smtp.gmail.com with ESMTPSA id e16sm19337932wra.36.2017.02.09.08.33.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 08:34:00 -0800 (PST) From: "Mehmet Ersue" To: Date: Thu, 9 Feb 2017 17:33:59 +0100 Message-ID: <01c401d282f2$51457a50$f3d06ef0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C5_01D282FA.B30AA5A0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKC8YPoEETEqvUgRw+wI2jedAErjA== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0203.589C99F8.006B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: [yang-doctors] Merged YANG FAQ page X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 16:34:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C5_01D282FA.B30AA5A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, we are merging the two YANG pages from YANG doctors and NETMOD Wikis. It is planned to provide a link to the new FAQ page from the YANG doctors page and NETMOD Wiki. Please find below a draft FAQ page. https://trac.ietf.org/trac/ops/wiki/YANGDoctorsFAQ Please review the answers on the page and let us know how they could be improved. There are 14 open questions at the end of the page. Can any of you provide a short FAQ answer to these questions? Thanks, Mehmet ------=_NextPart_000_01C5_01D282FA.B30AA5A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

we are merging the two = YANG pages from YANG doctors and NETMOD Wikis.

It is planned to provide = a link to the new FAQ page from the YANG doctors page and NETMOD = Wiki.

 

Please find below a = draft FAQ page.

https://trac.= ietf.org/trac/ops/wiki/YANGDoctorsFAQ

 

Please review the = answers on the page and let us know how they could be = improved.

 

There are 14 open = questions at the end of the page.

Can any of you provide a = short FAQ answer to these questions?

 

Thanks,

Mehmet

 

------=_NextPart_000_01C5_01D282FA.B30AA5A0-- From nobody Thu Feb 9 09:20:20 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B466129BED for ; Thu, 9 Feb 2017 09:20:20 -0800 (PST) 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 X1zmyeu4_5es for ; Thu, 9 Feb 2017 09:20:18 -0800 (PST) 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 2A8A5129C1E for ; Thu, 9 Feb 2017 09:20:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5EABF744; Thu, 9 Feb 2017 18:20:16 +0100 (CET) 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 MwyS6k_dAalN; Thu, 9 Feb 2017 18:20:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 9 Feb 2017 18:20:16 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13EBA200BD; Thu, 9 Feb 2017 18:20:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MK3oe7MOiGzS; Thu, 9 Feb 2017 18:20:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2749200BE; Thu, 9 Feb 2017 18:20:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F24DB3E6F2F9; Thu, 9 Feb 2017 18:20:18 +0100 (CET) Date: Thu, 9 Feb 2017 18:20:18 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20170209172018.GB2168@elstar.local> Mail-Followup-To: Mehmet Ersue , yang-doctors@ietf.org References: <01c401d282f2$51457a50$f3d06ef0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c401d282f2$51457a50$f3d06ef0$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] Merged YANG FAQ page X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 17:20:20 -0000 On Thu, Feb 09, 2017 at 05:33:59PM +0100, Mehmet Ersue wrote: > Hi All, > > There are 14 open questions at the end of the page. > > Can any of you provide a short FAQ answer to these questions? > Some questions seem odd or totally outdated. For example, YANG does not have keyrefs. The official published versions never had. This already addresses the last four items - just dump them. /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 Fri Feb 10 11:14:50 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03CE12945D for ; Fri, 10 Feb 2017 11:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 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=-1.887, 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 jVUtki3uIUih for ; Fri, 10 Feb 2017 11:14:45 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002ED129AD7 for ; Fri, 10 Feb 2017 11:14:43 -0800 (PST) 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=ShXhgMrpAKJUNYYroDsdcDE038Z2VBLXCxCbmnI8a38=; b=XDf1O88MNJZnXHEO6V3GDZFg0R+pJdrl/1F1gyThLPjnSZyfg0bWIpvRvKEsxc+1IfhqSeWRtGbSNqU4mZiyWLOhfFtT2kZ501ugeqH9jlH9GAi9bRnl1AfjknXFju3BrVTDWobheXyQHw0uKz7nPvqkq4ZT8MVIu/adINbnj9A= 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_256_CBC_SHA384_P384) id 15.1.888.5; Fri, 10 Feb 2017 19:14:42 +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.0888.026; Fri, 10 Feb 2017 19:14:42 +0000 From: Kent Watsen To: Mehmet Ersue , "yang-doctors@ietf.org" Thread-Topic: [yang-doctors] Merged YANG FAQ page Thread-Index: AdKC8YPoEETEqvUgRw+wI2jedAErjAAtoHAA Date: Fri, 10 Feb 2017 19:14:42 +0000 Message-ID: <5C56235E-1C16-4AA9-90C8-B98660A1E9C1@juniper.net> References: <01c401d282f2$51457a50$f3d06ef0$@gmail.com> In-Reply-To: <01c401d282f2$51457a50$f3d06ef0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 0676c208-a53f-4a33-0145-08d451e9115d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:kC7m/+mF5nq9ETZ3hrnVAgxOiXYXH47kRsHxkoHHfytn6L2qmTkq5hLQSlvfIg4FVen3P/qSTwYQG/oauFDhSnmk5OCgirx38e9E8pk8av/cRr/+rkzt7JKK/8CqDsWwe6yX+XJfrAD76ZWMiSipt3/zsNuJrcbcFYOuo8432mqn1L3iosD78dNCppjw8IlqvnYFowqMT77xrhKL5yPm+U+lAMvptQZVGV+FC+zkh27xZeKrwu3NyvigZ9v2uvnbnKcRz0QmbMtxcJ3xKDysF7Ng/nNa6SJk/RYosxknmQFe02S5JJXFqQFIamq3i+Rtc3/RuRu18FwlT7BD0hLG4WVZomxcxTqFYDNwmzHyb1/hhetZ8wxdo7VCf0XkMdrwDVEx3mjf2VWz7s5vM1DEgnobX5LJG9/qfOZhqplX4Z9jd4214aK6/QePC2OjZBstQmgL1O5NB5f21w1Ft5pTrdDw3kSXKLWh0fA2OBIA+Mh6Bs5p3yQ+ZG95F2sa1hXpeLdzBxV2iB1T1rWq7nVDiQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0214EB3F68 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39850400002)(39860400002)(39410400002)(39450400003)(39840400002)(24454002)(189002)(53754006)(377454003)(199003)(35754003)(38730400002)(92566002)(8676002)(6246003)(39060400001)(3846002)(54896002)(2950100002)(99286003)(6512007)(236005)(66066001)(82746002)(229853002)(53936002)(83506001)(83716003)(81166006)(2501003)(81156014)(7736002)(6116002)(102836003)(3660700001)(33656002)(2900100001)(106356001)(105586002)(189998001)(4001350100001)(76176999)(25786008)(7906003)(6486002)(6306002)(77096006)(5660300001)(6436002)(606005)(2906002)(101416001)(50986999)(36756003)(122556002)(3280700002)(97736004)(86362001)(54356999)(8936002)(68736007)(6506006)(104396002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5C56235E1C164AA990C8B98660A1E9C1junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2017 19:14:42.5213 (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: [yang-doctors] Merged YANG FAQ page X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 19:14:49 -0000 --_000_5C56235E1C164AA990C8B98660A1E9C1junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGZpeGVkIGEgY291cGxlIGFuc3dlcnMuDQoNCksuDQoNCk9uIDIvOS8xNywgMTE6MzMgQU0s ICJ5YW5nLWRvY3RvcnMgb24gYmVoYWxmIG9mIE1laG1ldCBFcnN1ZSIgPHlhbmctZG9jdG9ycy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzp5YW5nLWRvY3RvcnMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIG1lcnN1ZUBnbWFpbC5jb208bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20+PiB3cm90 ZToNCg0KSGkgQWxsLA0KDQp3ZSBhcmUgbWVyZ2luZyB0aGUgdHdvIFlBTkcgcGFnZXMgZnJvbSBZ QU5HIGRvY3RvcnMgYW5kIE5FVE1PRCBXaWtpcy4NCkl0IGlzIHBsYW5uZWQgdG8gcHJvdmlkZSBh IGxpbmsgdG8gdGhlIG5ldyBGQVEgcGFnZSBmcm9tIHRoZSBZQU5HIGRvY3RvcnMgcGFnZSBhbmQg TkVUTU9EIFdpa2kuDQoNClBsZWFzZSBmaW5kIGJlbG93IGEgZHJhZnQgRkFRIHBhZ2UuDQpodHRw czovL3RyYWMuaWV0Zi5vcmcvdHJhYy9vcHMvd2lraS9ZQU5HRG9jdG9yc0ZBUQ0KDQpQbGVhc2Ug cmV2aWV3IHRoZSBhbnN3ZXJzIG9uIHRoZSBwYWdlIGFuZCBsZXQgdXMga25vdyBob3cgdGhleSBj b3VsZCBiZSBpbXByb3ZlZC4NCg0KVGhlcmUgYXJlIDE0IG9wZW4gcXVlc3Rpb25zIGF0IHRoZSBl bmQgb2YgdGhlIHBhZ2UuDQpDYW4gYW55IG9mIHlvdSBwcm92aWRlIGEgc2hvcnQgRkFRIGFuc3dl ciB0byB0aGVzZSBxdWVzdGlvbnM/DQoNClRoYW5rcywNCk1laG1ldA0KDQo= --_000_5C56235E1C164AA990C8B98660A1E9C1junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <2FA52822A90B794FA9E320DD438B508E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOiMwMDAwQ0M7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlh bnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9y bTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFz ZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGZpeGVk IGEgY291cGxlIGFuc3dlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5LLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvOS8xNywgMTE6MzMgQU0sICZx dW90O3lhbmctZG9jdG9ycyBvbiBiZWhhbGYgb2YgTWVobWV0IEVyc3VlJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86eWFuZy1kb2N0b3JzLWJvdW5jZXNAaWV0Zi5vcmciPnlhbmctZG9jdG9ycy1i b3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzptZXJzdWVA Z21haWwuY29tIj5tZXJzdWVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5IaSBBbGws PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj53ZSBhcmUgbWVyZ2luZyB0aGUg dHdvIFlBTkcgcGFnZXMgZnJvbSBZQU5HIGRvY3RvcnMgYW5kIE5FVE1PRCBXaWtpcy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMDBDQyI+SXQgaXMgcGxhbm5lZCB0byBwcm92aWRlIGEgbGluayB0byB0aGUgbmV3IEZBUSBw YWdlIGZyb20gdGhlIFlBTkcgZG9jdG9ycyBwYWdlIGFuZCBORVRNT0QgV2lraS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPlBsZWFzZSBmaW5kIGJlbG93IGEgZHJhZnQgRkFR IHBhZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDAwQ0MiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFj L29wcy93aWtpL1lBTkdEb2N0b3JzRkFRIj5odHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy9vcHMv d2lraS9ZQU5HRG9jdG9yc0ZBUTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAw Q0MiPlBsZWFzZSByZXZpZXcgdGhlIGFuc3dlcnMgb24gdGhlIHBhZ2UgYW5kIGxldCB1cyBrbm93 IGhvdyB0aGV5IGNvdWxkIGJlIGltcHJvdmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwMDBDQyI+VGhlcmUgYXJlIDE0IG9wZW4gcXVlc3Rpb25zIGF0IHRoZSBlbmQgb2YgdGhlIHBh Z2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDAwQ0MiPkNhbiBhbnkgb2YgeW91IHByb3ZpZGUgYSBzaG9ydCBGQVEgYW5z d2VyIHRvIHRoZXNlIHF1ZXN0aW9ucz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAw Q0MiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJERSIgc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPk1laG1ldDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5C56235E1C164AA990C8B98660A1E9C1junipernet_-- From nobody Mon Feb 13 06:01:13 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E631129535; Mon, 13 Feb 2017 06:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NkO9q8YOXfWt; Mon, 13 Feb 2017 06:01:09 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5C01E1294A5; Mon, 13 Feb 2017 06:01:06 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 652A71821391; Mon, 13 Feb 2017 15:00:27 +0100 (CET) From: Ladislav Lhotka To: draft-ietf-rtgwg-yang-key-chain.all@ietf.org Date: Mon, 13 Feb 2017 15:01:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: yang-doctors@ietf.org Subject: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:01:11 -0000 Hi, I was assigned to be the YANG doctor for this document. Here is my review: **** General comments ***** Configuration and state data The module "ietf-key-chain" represents state data in a way that departs from the convention that has been used so far in most IETF modules, i.e. separate configuration and state data trees. I know this is a controversial topic but I also won't hide that I prefer the "traditional" arrangement. In any case, this data model organization clutters the output of the NETCONF "get" operation. I assume in most (all?) cases the "*-state" parameters will be the same as the configured value. ***** Cryptographic algorithm types What is the reason for representing these as a YANG choice with empty leaves? I think it would be more natural to use a single leaf, either an enumeration or (if extensibility is important) identityref. ***** Reusability The module defines key-chain as a grouping with the aim of making it reusable in other modules. However, this approach has known problems that are discussed in draft-ietf-netmod-schema-mount. I am not sure how relevant they are in this case but, for one, the "key-chain-ref" type is not applicable if the "key-chain" grouping is used in another module. An alternative is not to use the grouping and rely on schema mount. ***** Key string style The difference between ASCII and hexadecimal formats of key strings should be explained. I understand that the latter is a hash of the key and, if so, I'd suggest to include "hexadecimal-string" also in state data. Also, I believe that storing clear-text key in configuration is insecure and Security Considerations should warn against it. ***** Example It might be useful to include an appendix with example instance data. **** Specific comments ***** Sec. 2 - paragraph 2: s/where ever/wherever/ ***** Sec. 3 - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter is used in other places of the text). - paragraph 2: the suggested way of supporting assymetric keys looks like a hack, I would suggest a more explicit representation, e.g. using a choice. ***** Sec. 4 - The module has inconsistent indentation: up to "grouping crypto-algorithm-types", top-level statements are indented with four spaces, the subsequent ones with five spaces. ***** Sec. 6 - The statement "Given that the key chains themselves are sensitive data, it is RECOMMENDED that the NETCONF communication channel be encrypted." is misleading because RFC 6241 requires that transport protocols for NETCONF guarantee confidentiality (and RFC 8040 does the same for RESTCONF). Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 13 06:33:12 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30431295E0; Mon, 13 Feb 2017 06:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 poyK0IiMmqkl; Mon, 13 Feb 2017 06:33:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 82873129633; Mon, 13 Feb 2017 06:33:09 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 266EB1AE039A; Mon, 13 Feb 2017 15:33:07 +0100 (CET) Date: Mon, 13 Feb 2017 15:33:06 +0100 (CET) Message-Id: <20170213.153306.1164034975842789777.mbj@tail-f.com> To: lhotka@nic.cz 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: Cc: yang-doctors@ietf.org, draft-ietf-rtgwg-yang-key-chain.all@ietf.org Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:33:11 -0000 Hi, I had reasons to read this document the other day, and I have some additional comments: o The revision history should be trimmed to just a single entry. The idea is to only keep revision only for published versions (in this case RFC versions). o Lists should be named with the singular form, so "list key-chain-entries" should be "key-chain-entry". But I wonder about the terminolgy; the draft text says: A key chain is a list of elements each containing a key so I think the YANG names should reflect this terminology. Thus I suggest that "key-chain-list" is renamed to "key-chain" and "key-chain-entry" to "key". If you agree, the top-level container should probably be renamed to "key-chains" (and "key-chains-state") also. Ladislav Lhotka wrote: > Hi, > > I was assigned to be the YANG doctor for this document. Here is my > review: > > **** General comments > > ***** Configuration and state data > > The module "ietf-key-chain" represents state data in a way that > departs from the convention that has been used so far in most > IETF modules, i.e. separate configuration and state data > trees. I know this is a controversial topic but I also won't > hide that I prefer the "traditional" arrangement. In any case, > this data model organization clutters the output of the NETCONF > "get" operation. I assume in most (all?) cases the "*-state" > parameters will be the same as the configured value. But this module does have two separate top-level trees, /key-chain and /key-chain-state. What do I miss? > ***** Sec. 4 > > - The module has inconsistent indentation: up to "grouping > crypto-algorithm-types", top-level statements are indented with > four spaces, the subsequent ones with five spaces. I suggest you run "pyang -f yang --yang-canonical" on your module. It will produce a module that is consistent with our IETF modules in terms of indentation and module layout. /martin From nobody Mon Feb 13 06:46:52 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4555912967A; Mon, 13 Feb 2017 06:46:51 -0800 (PST) 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 Q2cDFCvyIDFh; Mon, 13 Feb 2017 06:46:50 -0800 (PST) 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 DF44E129633; Mon, 13 Feb 2017 06:46:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3613; q=dns/txt; s=iport; t=1486997209; x=1488206809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8x347tqPqeH00+IKA7fXUcqqvqA4qiM9QMnVSpz6yVo=; b=g73RSkNWj3qin774uaQSBLUDqXjbUHGmpkNj5FZUguyGC7io3PrABcy2 QfVVwHwD5Qd+KrljQ03aK2HggDArShkkpRJwj4ZRIzMvDkeI7ArvPdAmu VOzhiaaBPHd+k/2xzAkUteiHbDZqCgd5fXfi2B43A98rj+DezWT4DN6r9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQCIxqFY/5JdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageNWqUzgg+CDIYiAoJnPxgBAgEBAQEBAQFiKIRqBjo/EAI?= =?us-ascii?q?BCDYQMiUCBAENBYlqsFSLRQEBAQEBAQEBAQEBAQEBAQEBAQEfizuKGh8BBJtyA?= =?us-ascii?q?ZITgXuIZ4YjkxQBHziBAFEVhQEegWF1iSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208";a="384093930" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 14:46:48 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v1DEkmXn019249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 14:46:48 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 09:46:48 -0500 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, 13 Feb 2017 09:46:48 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFnA/iA Date: Mon, 13 Feb 2017 14:46:47 +0000 Message-ID: References: In-Reply-To: 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.24.67.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 14:46:51 -0000 Hi Lada,=20 Thanks for the review, an initial read indicates some good comments. As editor, I will work with my co-authors to respond to them. However, see one question below. On 2/13/17, 9:01 AM, "Ladislav Lhotka" wrote: >Hi, > >I was assigned to be the YANG doctor for this document. Here is my >review: > >**** General comments > >***** Configuration and state data >=20 > The module "ietf-key-chain" represents state data in a way that > departs from the convention that has been used so far in most > IETF modules, i.e. separate configuration and state data > trees. I know this is a controversial topic but I also won't > hide that I prefer the "traditional" arrangement. In any case, > this data model organization clutters the output of the NETCONF > "get" operation. I assume in most (all?) cases the "*-state" > parameters will be the same as the configured value. Are you sure you are looking at the right version of the draft? We went back and forth several times on this and the -13 has a separate key-chain and key-chain-state data node at the top level as you suggest. Thanks, Acee=20 > >***** Cryptographic algorithm types > > What is the reason for representing these as a YANG choice with > empty leaves? I think it would be more natural to use a single > leaf, either an enumeration or (if extensibility is important) > identityref. > >***** Reusability > > The module defines key-chain as a grouping with the aim of > making it reusable in other modules. However, this approach has > known problems that are discussed in > draft-ietf-netmod-schema-mount. I am not sure how relevant they > are in this case but, for one, the "key-chain-ref" > type is not applicable if the "key-chain" grouping is used in > another module. An alternative is not to use the grouping and > rely on schema mount. > >***** Key string style > > The difference between ASCII and hexadecimal > formats of key strings should be explained. I understand that > the latter is a hash of the key and, if so, I'd suggest to > include "hexadecimal-string" also in state data. > > Also, I believe that storing clear-text key in configuration is > insecure and Security Considerations should warn against it. > >***** Example > > It might be useful to include an appendix with example instance >data. > >**** Specific comments > =20 >***** Sec. 2 > > - paragraph 2: s/where ever/wherever/ > >***** Sec. 3 > > - paragraph 1: replace both Key-Id a Key-ID with Key ID (the > latter is used in other places of the text). > > - paragraph 2: the suggested way of supporting assymetric keys > looks like a hack, I would suggest a more explicit > representation, e.g. using a choice. > >***** Sec. 4 > > - The module has inconsistent indentation: up to "grouping > crypto-algorithm-types", top-level statements are indented with > four spaces, the subsequent ones with five spaces. > >***** Sec. 6 > > - The statement "Given that the key chains themselves are > sensitive data, it is RECOMMENDED that the NETCONF > communication channel be encrypted." is misleading because RFC > 6241 requires that transport protocols for NETCONF guarantee > confidentiality (and RFC 8040 does the same for RESTCONF). > >Lada > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 13 07:07:52 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5650C1296A6; Mon, 13 Feb 2017 07:07:50 -0800 (PST) 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 U4j4QEClp7Fi; Mon, 13 Feb 2017 07:07:48 -0800 (PST) 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 26A0D129699; Mon, 13 Feb 2017 07:07:48 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id BC47260180; Mon, 13 Feb 2017 16:07:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486998466; bh=mfxlHeHknZmzuuzVW1qguAZocWxjDM2I1v+RUYEQPlU=; h=From:Date:To; b=h9SnJp54pSoewXkF/M7RlROOr9ptc0HOWp4NJHpRcElAKB1cufwv9nvvW74L1Mnyh NAobMwmGNrsk8A6jYOxzLaDtBNac5wQos8O56qyMEUzJs7dRTNDZLf0uLHE2J7ealX watxnnOLu0toyBQ/Cz1uA5OMkrtu04ysx1KxEs70= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170213.153306.1164034975842789777.mbj@tail-f.com> Date: Mon, 13 Feb 2017 16:07:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170213.153306.1164034975842789777.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: Cc: Benoit Claise , draft-ietf-rtgwg-yang-key-chain.all@ietf.org Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:07:50 -0000 > On 13 Feb 2017, at 15:33, Martin Bjorklund wrote: >=20 > Hi, >=20 > I had reasons to read this document the other day, and I have some > additional comments: >=20 > o The revision history should be trimmed to just a single entry. The > idea is to only keep revision only for published versions (in this > case RFC versions). I think that at least in some cases, e.g. if a module stays relatively = long in the draft stage, it makes sense to record all revisions so as to = be able to tell them apart. 6087bis says: It is not required to keep the full revision history of draft versions (e.g., modules contained within Internet-Drafts). That is, within a sequence of draft versions, only the most recent revision need be recorded in the module. So it doesn't preclude recording "intermediate" revisions. I would = personally leave it to each author's discretion. =20 >=20 > o Lists should be named with the singular form, so "list > key-chain-entries" should be "key-chain-entry". But I wonder about > the terminolgy; the draft text says: >=20 > A key chain is a list of elements each containing a key >=20 > so I think the YANG names should reflect this terminology. Thus I > suggest that "key-chain-list" is renamed to "key-chain" and > "key-chain-entry" to "key". If you agree, the top-level container > should probably be renamed to "key-chains" (and "key-chains-state") > also. I agree. >=20 >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I was assigned to be the YANG doctor for this document. Here is my >> review: >>=20 >> **** General comments >>=20 >> ***** Configuration and state data >>=20 >> The module "ietf-key-chain" represents state data in a way that >> departs from the convention that has been used so far in most >> IETF modules, i.e. separate configuration and state data >> trees. I know this is a controversial topic but I also won't >> hide that I prefer the "traditional" arrangement. In any case, >> this data model organization clutters the output of the NETCONF >> "get" operation. I assume in most (all?) cases the "*-state" >> parameters will be the same as the configured value. >=20 > But this module does have two separate top-level trees, /key-chain and > /key-chain-state. What do I miss? Hmm, I don't know what I saw, maybe I got confused by the groupings. I = am sorry for the noise, please ignore this item. Thanks, Lada >=20 >> ***** Sec. 4 >>=20 >> - The module has inconsistent indentation: up to "grouping >> crypto-algorithm-types", top-level statements are indented with >> four spaces, the subsequent ones with five spaces. >=20 > I suggest you run "pyang -f yang --yang-canonical" on your module. It > will produce a module that is consistent with our IETF modules in > terms of indentation and module layout. >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 13 07:09:43 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE71296AC; Mon, 13 Feb 2017 07:09:41 -0800 (PST) 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 JuLGJNJzXBIT; Mon, 13 Feb 2017 07:09:40 -0800 (PST) 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 09F4A1296AB; Mon, 13 Feb 2017 07:09:40 -0800 (PST) Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:10]) by mail.nic.cz (Postfix) with ESMTPSA id C07FC60180; Mon, 13 Feb 2017 16:09:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1486998578; bh=zhwg9Z9ovbrK2C1RTsIeXRR1Fcpgy3FxrCNSMifE8Pk=; h=From:Date:To; b=edAgkcQoWP5YAkBTG47bgQ2YWB7McMMCbBrlYKGexGvw6XZU1HFOyKKiFztf+YU5M 2Nyt1Szjw1Bag3cA1onG22GVX+0d6ddLBekjkOitOeX56B5Vt9WCIZGGFWB2xtC5lt EVbKwRCPG+jjH47AXdDQG1PybkupOpyC/b28AMpo= 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: Mon, 13 Feb 2017 16:09:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:09:42 -0000 > On 13 Feb 2017, at 15:46, Acee Lindem (acee) wrote: >=20 > Hi Lada,=20 >=20 > Thanks for the review, an initial read indicates some good comments. = As > editor, I will work with my co-authors to respond to them. However, = see > one question below. >=20 > On 2/13/17, 9:01 AM, "Ladislav Lhotka" wrote: >=20 >> Hi, >>=20 >> I was assigned to be the YANG doctor for this document. Here is my >> review: >>=20 >> **** General comments >>=20 >> ***** Configuration and state data >>=20 >> The module "ietf-key-chain" represents state data in a way that >> departs from the convention that has been used so far in most >> IETF modules, i.e. separate configuration and state data >> trees. I know this is a controversial topic but I also won't >> hide that I prefer the "traditional" arrangement. In any case, >> this data model organization clutters the output of the NETCONF >> "get" operation. I assume in most (all?) cases the "*-state" >> parameters will be the same as the configured value. >=20 >=20 > Are you sure you are looking at the right version of the draft? We = went > back and forth several times on this and the -13 has a separate = key-chain > and key-chain-state data node at the top level as you suggest. Sure, see my response to Martin - I must have suffered from a mental = blackout. :-) Sorry for that, Lada >=20 > Thanks, > Acee=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >>=20 >> ***** Cryptographic algorithm types >>=20 >> What is the reason for representing these as a YANG choice with >> empty leaves? I think it would be more natural to use a single >> leaf, either an enumeration or (if extensibility is important) >> identityref. >>=20 >> ***** Reusability >>=20 >> The module defines key-chain as a grouping with the aim of >> making it reusable in other modules. However, this approach has >> known problems that are discussed in >> draft-ietf-netmod-schema-mount. I am not sure how relevant they >> are in this case but, for one, the "key-chain-ref" >> type is not applicable if the "key-chain" grouping is used in >> another module. An alternative is not to use the grouping and >> rely on schema mount. >>=20 >> ***** Key string style >>=20 >> The difference between ASCII and hexadecimal >> formats of key strings should be explained. I understand that >> the latter is a hash of the key and, if so, I'd suggest to >> include "hexadecimal-string" also in state data. >>=20 >> Also, I believe that storing clear-text key in configuration is >> insecure and Security Considerations should warn against it. >>=20 >> ***** Example >>=20 >> It might be useful to include an appendix with example instance >> data. >>=20 >> **** Specific comments >>=20 >> ***** Sec. 2 >>=20 >> - paragraph 2: s/where ever/wherever/ >>=20 >> ***** Sec. 3 >>=20 >> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the >> latter is used in other places of the text). >>=20 >> - paragraph 2: the suggested way of supporting assymetric keys >> looks like a hack, I would suggest a more explicit >> representation, e.g. using a choice. >>=20 >> ***** Sec. 4 >>=20 >> - The module has inconsistent indentation: up to "grouping >> crypto-algorithm-types", top-level statements are indented with >> four spaces, the subsequent ones with five spaces. >>=20 >> ***** Sec. 6 >>=20 >> - The statement "Given that the key chains themselves are >> sensitive data, it is RECOMMENDED that the NETCONF >> communication channel be encrypted." is misleading because RFC >> 6241 requires that transport protocols for NETCONF guarantee >> confidentiality (and RFC 8040 does the same for RESTCONF). >>=20 >> Lada >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 13 07:27:26 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3651295F6; Mon, 13 Feb 2017 07:27:25 -0800 (PST) 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 hiL6x2mEbxsX; Mon, 13 Feb 2017 07:27:22 -0800 (PST) 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 82C90129451; Mon, 13 Feb 2017 07:27:22 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B542A6BF; Mon, 13 Feb 2017 16:27:20 +0100 (CET) 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 H7RmRNzTnYi1; Mon, 13 Feb 2017 16:27:19 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 13 Feb 2017 16:27:20 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F980200C1; Mon, 13 Feb 2017 16:27:20 +0100 (CET) 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 8uWbG9u3qEDW; Mon, 13 Feb 2017 16:27:20 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAACF200BE; Mon, 13 Feb 2017 16:27:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C29D23E73EED; Mon, 13 Feb 2017 16:27:22 +0100 (CET) Date: Mon, 13 Feb 2017 16:27:22 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170213152720.GB11159@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , Benoit Claise , draft-ietf-rtgwg-yang-key-chain.all@ietf.org References: <20170213.153306.1164034975842789777.mbj@tail-f.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: Cc: Benoit Claise , draft-ietf-rtgwg-yang-key-chain.all@ietf.org Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 15:27:25 -0000 On Mon, Feb 13, 2017 at 04:07:46PM +0100, Ladislav Lhotka wrote: > > > On 13 Feb 2017, at 15:33, Martin Bjorklund wrote: > > > > Hi, > > > > I had reasons to read this document the other day, and I have some > > additional comments: > > > > o The revision history should be trimmed to just a single entry. The > > idea is to only keep revision only for published versions (in this > > case RFC versions). > > I think that at least in some cases, e.g. if a module stays relatively long in the draft stage, it makes sense to record all revisions so as to be able to tell them apart. > > 6087bis says: > > It is not required to keep the full revision history of draft > versions (e.g., modules contained within Internet-Drafts). That is, > within a sequence of draft versions, only the most recent revision > need be recorded in the module. > > So it doesn't preclude recording "intermediate" revisions. I would personally leave it to each author's discretion. > This must be new text, I liked RFC 6087 more; I do not want to know about all the intermediate editing steps someone did, regardless how long it did to finish the editing. Since we ask module authors to update the revision date on intermedia Internet-Draft versions, there is also no ambiguity. /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 Mon Feb 13 08:31:39 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60A8129541; Mon, 13 Feb 2017 08:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 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=-1.887, 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 iishlcD04UXX; Mon, 13 Feb 2017 08:31:37 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0110.outbound.protection.outlook.com [104.47.37.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 C492A12952C; Mon, 13 Feb 2017 08:31:36 -0800 (PST) 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=2ywD8ftHLAeuI5krkOfD4OfeOEDaBW6OHuiu0jOp3Hs=; b=RKAgCYaVLY3Z4ZdLlMjCWIvOmkbdFhtNyvqBkG4eUfkoqjbvJlOEItJP8hYkwmqyz1qfJpkLj6wA3ABGH146G9sSxsB/fUTMlBrsrZoZkaHmDlJnMYlnxh5BdSpkCobXsJc9ZYrtJAkXj0MDwtS6q5KGhY+wl9OAkMuvT6ktf8s= 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_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 13 Feb 2017 16:31:35 +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.0919.011; Mon, 13 Feb 2017 16:31:35 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Ladislav Lhotka" Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgYcc0wnNyrz+k2VMX64PSiSPaFnCdEAgAAFegD//74dgA== Date: Mon, 13 Feb 2017 16:31:35 +0000 Message-ID: <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> In-Reply-To: <20170213152720.GB11159@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 3313588d-5a65-4fef-2092-08d4542dc6e2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:yvWr5PmsLlQGnmofJtptUm2XhUwQwoeuuH4xuyLUuQ1PFhYmwqRPaEaYpukSIcWPNNK0oPGPrjGrqbb4ITXC+2BarTmx3yJGjZX2R+NW1XpwFRud7tPs4ESZA36B4HelcDLHP2MQO+hH2IxUWN4OJVt0hD4D9MsMBbAZztYqcI6X5QIKxd6wuzom6bRPQb4ODq52nq8XgACqmqeeHAVDdV3AKvZ5Cj3kuQqQXVOaAoIIlpOq+0Fsrjb9xqa9sZxLOYg9nWuhDXKP9sLUQ2ulQDvfSQDbt5D1No9/9q0THKWRBFcxYxWT82USp2NrCFp3fIIV3u6HZZk/qUdCTRR9AVu4rsWBFKfrLM7+9W1455tuoejazB9U33HxiIyVtZgJCt9lg0iO5DGerlCm1HM0RImSi9jNxlz+E+im5KuiDoa5DIOPf3COxoCTRCXVQMpq3J38G4inGycYAHPzTFP5z/iJRjhOS+hmhYqi/lJYn00E2Wb4G4OzGRjoYRlhmABtkT6hfQOf/1nHNUeFuAUW9g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39450400003)(39840400002)(39850400002)(39860400002)(189002)(199003)(51444003)(33656002)(106356001)(106116001)(25786008)(5660300001)(50986999)(54356999)(101416001)(2906002)(4326007)(229853002)(76176999)(53936002)(66066001)(189998001)(230783001)(54906002)(7736002)(8936002)(122556002)(99286003)(3280700002)(36756003)(3660700001)(6512007)(2950100002)(6116002)(93886004)(102836003)(105586002)(305945005)(8676002)(81156014)(81166006)(97736004)(3846002)(6246003)(83506001)(4001350100001)(2900100001)(77096006)(6506006)(6486002)(38730400002)(82746002)(68736007)(6436002)(86362001)(83716003)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4B59407FFB3DE74BAF2DC21850F5499B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 16:31:35.1350 (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: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 16:31:39 -0000 DQo+IFRoaXMgbXVzdCBiZSBuZXcgdGV4dCwgSSBsaWtlZCBSRkMgNjA4NyBtb3JlOyBJIGRvIG5v dCB3YW50IHRvIGtub3cNCj4gYWJvdXQgYWxsIHRoZSBpbnRlcm1lZGlhdGUgZWRpdGluZyBzdGVw cyBzb21lb25lIGRpZCwgcmVnYXJkbGVzcyBob3cNCj4gbG9uZyBpdCBkaWQgdG8gZmluaXNoIHRo ZSBlZGl0aW5nLiBTaW5jZSB3ZSBhc2sgbW9kdWxlIGF1dGhvcnMgdG8NCj4gdXBkYXRlIHRoZSBy ZXZpc2lvbiBkYXRlIG9uIGludGVybWVkaWEgSW50ZXJuZXQtRHJhZnQgdmVyc2lvbnMsIHRoZXJl DQo+IGlzIGFsc28gbm8gYW1iaWd1aXR5Lg0KDQpJIGFncmVlLiAgSGF2aW5nIHRoZSBpbnRlcm1l ZGlhdGUgcmV2aXNpb25zIGxpc3RlZCBhdCBhbGwgd2FzIG9ubHkgaW50ZW5kZWQgZm9yIHdoaWxl IGEgZHJhZnQgd2FzIHdvcmsgaW4gcHJvZ3Jlc3MuICBUaGUgZmluYWwgUkZDIG1vZHVsZSdzIGhp c3Rvcnkgc2hvdWxkIG9ubHkgcmVmbGVjdCBvdGhlciBwdWJsaXNoZWQgbW9kdWxlcy4NCg0KQlRX LCBBY2VlLCBJIG5vdGljZWQgaW4gU2VjdGlvbiAyOg0KDQogICBUaGUgbW9kdWxlIG5hbWUgd2Fz IGNoYW5nZSBmcm9tIGlldGYta2V5LWNoYWluIHRvIGlldGYtcm91dGluZy1rZXktDQogICBjaGFp biB0byBhdm9pZCBkaXNhbWJpZ3VhdGUgaXQgZnJvbSB0aGUgaWV0Zi1zeXN0ZW0ta2V5Y2hhaW4g bW9kdWxlDQogICBkZWZpbmVkIGluIFtORVRDT05GLVNFUlZFUi1DT05GXS4gIEhvd2V2ZXIsIGR1 ZSB0byBwb3B1bGFyIGRlbWFuZCwNCiAgIHRoZSBtb2R1bGUgbmFtZSBoYXMgYmVlbiByZXN0b3Jl ZCB0byBzaW1wbHkgaWV0Zi1rZXktY2hhaW4uDQoNClBsZWFzZSBub3RlIHRoYXQgdGhlIE5FVENP TkYga2V5Y2hhaW4gbW9kZWwgaGFzIHNpbmNlIGJlZW4gcmVuYW1lZCBhbmQgcHVsbGVkIG91dCBp bnRvIGl0cyBvd24gZHJhZnQgKGRyYWZ0LWlldGYtbmV0Y29uZi1rZXlzdG9yZSksIHNpbmNlIGZv bGtzIHJlbWFpbmVkIGNvbmZ1c2VkIGFmdGVyIHlvdXIgZHJhZnQgZGlkbid0IGNoYW5nZSBpdHMg bmFtZS4gICBObyB3b3JyaWVzLCAia2V5c3RvcmUiIGlzIGEgbW9yZSBhcHQgbmFtZSBmb3IgbXkg ZHJhZnQncyBtb2RlbHMgYW55d2F5Lg0KDQpIb3dldmVyLCB3aXRoIHRoZSBuZXcgbmFtZXMgbm93 IGJlaW5nIHN1ZmZpY2llbnRseSBkaWZmZXJlbnQsIEkgdGhpbmsgdGhhdCB0aGUgbmFtaW5nIGhp c3RvcnkgaW4gdGhlIHBhcmFncmFwaCBhYm92ZSBjYW4gYmUgcmVtb3ZlZC4gIFRoYXQgc2FpZCwg aXQgd291bGQgc3RpbGwgYmUgdXNlZnVsIGZvciB5b3VyIGRyYWZ0IHRvIHBvaW50IHJlYWRlcnMg dG8gdGhlIG90aGVyICJrZXkgY2hhaW4iIGRyYWZ0LCBpbiBjYXNlIHRoZXkgbGFuZCBvbiB5b3Vy cyBieSBhY2NpZGVudCwgb3IgYXJlIG90aGVyd2lzZSBpbnRlcmVzdGVkIGluIHNlZWluZyBob3cg a2V5cyBhcmUgaGFuZGxlZCB0aGVyZS4NCg0KS2VudA0KDQoNCg0KDQoNCg0K From nobody Mon Feb 13 09:23:05 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE4F129559; Mon, 13 Feb 2017 09:23:04 -0800 (PST) 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 kM08frw3XPz0; Mon, 13 Feb 2017 09:23:03 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED0F1294C6; Mon, 13 Feb 2017 09:23:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1780; q=dns/txt; s=iport; t=1487006582; x=1488216182; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LTSsWpS1nri5JwQCIX5e1YvZaZdm7vynYGPdHnU3ea8=; b=ltDx0ZSYEXXmSHsdUhh8qm3SIYRYVx6iy4ZCYXX9Xe2w024UGCPQOcRE Z/nSYcsTOxhK/8YMdbSImz/SITGc/Xm2E5NNjdjzre7Lcd7MVzDjCf9Z8 UZQKkdssxPDfnbhDp4lhq3SHoG3gF/Du37j9CC+KRRN6Ymqy2oVRp7zd0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDU6qFY/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageNWpIMkyeCD4IMhiICgWw/GAECAQEBAQEBAWIohGoBBAF?= =?us-ascii?q?5EAIBCA44MiUCBAENBYliCLEAi0UBAQEBAQEBAQEBAQEBAQEBAQEBH4s7hD6FX?= =?us-ascii?q?B8BBI9CAUCLbwGSE4F7hReJc4gsimgBHziBAFEVhQIdgWF1iSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,156,1484006400"; d="scan'208";a="383545821" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 17:23:01 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v1DHN1QD031116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 17:23:01 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 12:23:00 -0500 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, 13 Feb 2017 12:23:01 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Juergen Schoenwaelder , Ladislav Lhotka Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFnU/wA//+7Z+2AAGWzgP//uomA Date: Mon, 13 Feb 2017 17:23:00 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> In-Reply-To: <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> 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.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7EBA0CE780029D48AB5544CAD13CD4EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:23:04 -0000 Hi Kent,=20 On 2/13/17, 11:31 AM, "Kent Watsen" wrote: > >> This must be new text, I liked RFC 6087 more; I do not want to know >> about all the intermediate editing steps someone did, regardless how >> long it did to finish the editing. Since we ask module authors to >> update the revision date on intermedia Internet-Draft versions, there >> is also no ambiguity. > >I agree. Having the intermediate revisions listed at all was only >intended for while a draft was work in progress. The final RFC module's >history should only reflect other published modules. > >BTW, Acee, I noticed in Section 2: > > The module name was change from ietf-key-chain to ietf-routing-key- > chain to avoid disambiguate it from the ietf-system-keychain module > defined in [NETCONF-SERVER-CONF]. However, due to popular demand, > the module name has been restored to simply ietf-key-chain. > >Please note that the NETCONF keychain model has since been renamed and >pulled out into its own draft (draft-ietf-netconf-keystore), since folks >remained confused after your draft didn't change its name. No worries, >"keystore" is a more apt name for my draft's models anyway. > >However, with the new names now being sufficiently different, I think >that the naming history in the paragraph above can be removed. Sure.=20 >That said, it would still be useful for your draft to point readers to >the other "key chain" draft, The other draft is not a =B3key chain=B2 draft and I was happy to see the misnomer corrected. >in case they land on yours by accident, or are otherwise interested in >seeing how keys are handled there. I don=B9t feel this is necessary. Thanks, Acee=20 > >Kent > > > > > > From nobody Mon Feb 13 11:45:13 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DE1129891; Mon, 13 Feb 2017 11:45:12 -0800 (PST) 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 6cDLuowO79RP; Mon, 13 Feb 2017 11:45:10 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0124.outbound.protection.outlook.com [104.47.37.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 53BE7129618; Mon, 13 Feb 2017 11:45:10 -0800 (PST) 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=MaxoEWUbJBjh86y9ABebWAKUUzuUExlZ1nF6p31b9Sc=; b=BvpoASVPOOvRWHJRupd2TfTvTVjtI6Pvh7PvDd1RJkW+EGU1T6Zhns2sZlLGbIuYuJQ80KGxAGqfC3xK3PBcK0rmsKFRIFVRMgOC2GdDLwP/CY6/6av2JOn16di4bcAm4FBRHaT53fizUjBjScaqUAEj5DtwtYP8KLXOfG+IuD8= 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_256_CBC_SHA384_P384) id 15.1.919.10; Mon, 13 Feb 2017 19:45:08 +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.0919.011; Mon, 13 Feb 2017 19:45:08 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Juergen Schoenwaelder , Ladislav Lhotka Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgYcc0wnNyrz+k2VMX64PSiSPaFnCdEAgAAFegD//74dgIAAYjEA///T5QA= Date: Mon, 13 Feb 2017 19:45:08 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@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.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: b0673ca0-1dd9-4ac6-89ff-08d45448d0e9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:DtIb4e2nUO336Vv65GBuouV2EQrBGboxIN+delepjkd1QTikRMbdiKkKmOG5to5DK7hBcD0//g/aQqvAIwxJuAx1RroUhlaDYwVYc70+dElFrMFFLkx+pixjEw8kBaKm6r3K4sz5v0n7n6ZB6zETU8s6Uv3eLUC15/JOSRmCAunVb6RGlj4vQjyfRDYY66gJn2sDsurCPSzt5GCBzkQLH1HRzSz/0r+maWgtE8f154rTzmE+Re//eJRtva5EOtUJHpTmL2rRn/Fj3umv6PLALnxrcpNKlnbluWTJ5oAL9TaMqHW+YZNPOujg8Vfn8D/ffzPZplLNOMcxpMBwQ+S6Nj6FACfvXjSqClGMU6DD6v0eCPG44JJwtj/N/T1urtjJtOENDWBn/28VhLsJxvbAWXFUlLhncql26rcU+OfA+sQjrv10XoLJmVnR7gIz8lm0OoODnZ94od09dBNIckt/A1Ehb3oq6cUm5k3B/KxHHvh/cgcz8+DjNASwbkmgwRpfz2XwWa+eU+PAVEO9dIiTjg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(199003)(189002)(25786008)(38730400002)(53936002)(54906002)(99286003)(6246003)(8936002)(230783001)(8676002)(81156014)(81166006)(33656002)(86362001)(6486002)(6436002)(6506006)(3660700001)(68736007)(5660300001)(305945005)(7736002)(2950100002)(3846002)(102836003)(6116002)(77096006)(6512007)(2900100001)(189998001)(82746002)(83506001)(4326007)(97736004)(3280700002)(4001350100001)(2906002)(83716003)(229853002)(122556002)(54356999)(76176999)(66066001)(36756003)(101416001)(106356001)(50986999)(105586002)(106116001)(93886004)(92566002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <18A655F53AF1084DBB94D356CA724BFD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 19:45:08.3825 (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: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:45:12 -0000 DQoNCj4+IFRoYXQgc2FpZCwgaXQgd291bGQgc3RpbGwgYmUgdXNlZnVsIGZvciB5b3VyIGRyYWZ0 IHRvIHBvaW50IHJlYWRlcnMgdG8NCj4+dGhlIG90aGVyICJrZXkgY2hhaW4iIGRyYWZ0LA0KPg0K PiBUaGUgb3RoZXIgZHJhZnQgaXMgbm90IGEgwrNrZXkgY2hhaW7CsiBkcmFmdCBhbmQgSSB3YXMg aGFwcHkgdG8gc2VlIHRoZQ0KPiBtaXNub21lciBjb3JyZWN0ZWQuDQoNCkkgdGhpbmsgeW91J3Jl IG92ZXJzdGF0aW5nIGEgcm91dGVyLWNlbnRyaWMgdmlldy4gIEFzIGV4cGxhaW5lZCBiZWZvcmUs DQpib3RoIE9TWCBhbmQgTGludXggKGFuZCBtYXliZSBtb3JlKSBoYXZlICJrZXljaGFpbiIgdXRp bGl0aWVzIHRoYXQgdGhlDQpvdGhlciBkcmFmdCdzIFlBTkcgbW9kdWxlIGlzIG1vZGVsZWQgYWZ0 ZXIuIA0KDQoNCj4+IGluIGNhc2UgdGhleSBsYW5kIG9uIHlvdXJzIGJ5IGFjY2lkZW50LCBvciBh cmUgb3RoZXJ3aXNlIGludGVyZXN0ZWQgaW4NCj4+IHNlZWluZyBob3cga2V5cyBhcmUgaGFuZGxl ZCB0aGVyZS4NCj4NCj4gSSBkb27CuXQgZmVlbCB0aGlzIGlzIG5lY2Vzc2FyeS4NCg0KQnV0IGl0 IHdvdWxkIGJlIGhlbHBmdWwuDQoNCg0KSy4NCg0KDQoNCg== From nobody Mon Feb 13 12:11:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6194F129405; Mon, 13 Feb 2017 12:11:53 -0800 (PST) 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 AteE5UlqlDym; Mon, 13 Feb 2017 12:11:52 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFDD1293D6; Mon, 13 Feb 2017 12:11:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1766; q=dns/txt; s=iport; t=1487016711; x=1488226311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3ZHiH/RBLXdcxdFBQguDa8sIBv8Xq7ZD87hwIFSMyxk=; b=kLSR/DFD3p1Dd+nAU79NLYA4fCeBRZ2xerNlDskFy011nO3YTHsJkwYs OPcbCxOfA9XGHnsKGHmahWnBIheBG9AHKmat9W55RYtWFtK5ORSw6L5+E CZnvnNMt2h9cpGzRveA8mBvrtskS7Tw08QrWx7kgc/VLexjZGEy5Fs5In 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C+AwD1EaJY/4YNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUq87gg+CDIYiAhqBVEAXAQIBAQEBAQEBYiiEagY0RRA?= =?us-ascii?q?CAQgODigCAjAlAgQBDQWJapE5nUYGgieLSgEBAQEBAQEBAQEBAQEBAQEBAQEfg?= =?us-ascii?q?QWKNoRUgwCCRh8BBI9CjDABkhORBZMUASABNoEAURWFAh2BYXWJIYEMAQEB?= X-IronPort-AV: E=Sophos;i="5.35,157,1484006400"; d="scan'208";a="197747407" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Feb 2017 20:11:51 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1DKBopG007430 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 20:11:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 15:11:50 -0500 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, 13 Feb 2017 15:11:50 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Juergen Schoenwaelder , Ladislav Lhotka Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFnU/wA//+7Z+2AAGWzgP//uomAgAB7iwD//7OegA== Date: Mon, 13 Feb 2017 20:11:50 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> In-Reply-To: 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.195] Content-Type: text/plain; charset="euc-kr" Content-ID: <9744277FDF7873448487FB4139C9084A@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 20:11:53 -0000 DQoNCk9uIDIvMTMvMTcsIDI6NDUgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5u ZXQ+IHdyb3RlOg0KDQo+DQo+DQo+Pj4gVGhhdCBzYWlkLCBpdCB3b3VsZCBzdGlsbCBiZSB1c2Vm dWwgZm9yIHlvdXIgZHJhZnQgdG8gcG9pbnQgcmVhZGVycyB0bw0KPj4+dGhlIG90aGVyICJrZXkg Y2hhaW4iIGRyYWZ0LA0KPj4NCj4+IFRoZSBvdGhlciBkcmFmdCBpcyBub3QgYSCp+GtleSBjaGFp bqn3IGRyYWZ0IGFuZCBJIHdhcyBoYXBweSB0byBzZWUgdGhlDQo+PiBtaXNub21lciBjb3JyZWN0 ZWQuDQo+DQo+SSB0aGluayB5b3UncmUgb3ZlcnN0YXRpbmcgYSByb3V0ZXItY2VudHJpYyB2aWV3 LiAgQXMgZXhwbGFpbmVkIGJlZm9yZSwNCj5ib3RoIE9TWCBhbmQgTGludXggKGFuZCBtYXliZSBt b3JlKSBoYXZlICJrZXljaGFpbiIgdXRpbGl0aWVzIHRoYXQgdGhlDQo+b3RoZXIgZHJhZnQncyBZ QU5HIG1vZHVsZSBpcyBtb2RlbGVkIGFmdGVyLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB5b3UgZmVl bCBzdHJvbmdseSB0aGF0IHlvdXIgd29yayBpcyB2ZXJ5IGltcG9ydGFudCBidXQsDQpsaWtlIHRo ZSBiYXNpYyByb3V0aW5nIHByb3RvY29scywgdGhlcmUgYXJlIG5ldHdvcmsgZGV2aWNlcyBvdGhl ciB0aGFuDQpyb3V0ZXJzIHRoYXQgd2lsbCBpbXBsZW1lbnQgcHJvdG9jb2wgYXV0aGVudGljYXRp b24gYmFzZWQgb24ga2V5LWNoYWlucy4NCg0KDQo+IA0KPg0KPg0KPj4+IGluIGNhc2UgdGhleSBs YW5kIG9uIHlvdXJzIGJ5IGFjY2lkZW50LCBvciBhcmUgb3RoZXJ3aXNlIGludGVyZXN0ZWQgaW4N Cj4+PiBzZWVpbmcgaG93IGtleXMgYXJlIGhhbmRsZWQgdGhlcmUuDQo+Pg0KPj4gSSBkb26p9nQg ZmVlbCB0aGlzIGlzIG5lY2Vzc2FyeS4NCj4NCj5CdXQgaXQgd291bGQgYmUgaGVscGZ1bC4NCg0K SSBkaXNhZ3JlZSBhbmQgYmVsaWV2ZSB0aGlzIHdvdWxkIHNldCBhIGJhZCBwcmVjZWRlbnQuIENh biB5b3UgcG9pbnQgdG8NCm90aGVyIFJGQ3MgdGhhdCBoYXZlIHJlZmVyZW5jZXMgdG8gb3RoZXIg ZG9jdW1lbnRzIGluIGNhc2UgcmVhZGVycyB3ZXJlDQpsb29raW5nIGZvciB0aG9zZSBkb2N1bWVu dHMgcmF0aGVyIHRoYW4gdGhlIGRvY3VtZW50IGl0c2VsZj8gV2VyZSB5b3UNCnBsYW5uaW5nIG9u IGFkZGluZyByZWZlcmVuY2VzIGluIHRoZSBrZXlzdG9yZSBtb2RlbCB0byBvdGhlciBkb2N1bWVu dHMNCnRoYXQgcmVhZGVycyBtYXkgaGF2ZSBiZWVuIHNlYXJjaGluZyBmb3I/DQoNClRoYW5rcywN CkFjZWUNCg0KDQoNCj4NCj4NCj5LLg0KPg0KPg0KPg0KDQo= From nobody Mon Feb 13 12:30:05 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8176B1298C8; Mon, 13 Feb 2017 12:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 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=-1.887, 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 xiFWPzRRsz4O; Mon, 13 Feb 2017 12:30:02 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0133.outbound.protection.outlook.com [104.47.42.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084CB12989C; Mon, 13 Feb 2017 12:30:02 -0800 (PST) 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=TktMmLcO9fHNbsfM5Gl/pfveBip2SWZJTzxAacp9i9Q=; b=dYgWSJ/nAkHzNhT+rIdBSt4WwCA0DNXDN6ruZaZMiK0vVhCYVBzE3Mq+VLVVtdc8AF2ClX2g+pyWoXrKlshIHB1KuCa56UKELZ+G0fVPbKVEfm18XCjejg3G48mklf7fwZqs3IWuYfqxqgznBJchoV/p6X1uobEntc4FKgbXxpg= 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_256_CBC_SHA384_P384) id 15.1.888.5; Mon, 13 Feb 2017 20:30: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.0919.011; Mon, 13 Feb 2017 20:30:00 +0000 From: Kent Watsen To: "Acee Lindem (acee)" , Juergen Schoenwaelder , Ladislav Lhotka Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgYcc0wnNyrz+k2VMX64PSiSPaFnCdEAgAAFegD//74dgIAAYjEA///T5QCAAFtHAP//sUGA Date: Mon, 13 Feb 2017 20:29:59 +0000 Message-ID: <01A89985-1620-4642-BA30-0B8DB0881971@juniper.net> References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@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.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 472c2970-9e8e-4543-1be3-08d4544f1531 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:M1/U/YXt2MqKeqsfXGX0mcP/aU1r8REvLzhYxrAa4nhL28YtNp4OJP2jgBUkjwEWxhnPNhIAxMnGpaLuFUfcFlTnevWl7kCnOyl0+XKXI9jytOwvVpiZvMcll/L3sqmCbmonxHkyIgzX+KP08MsdvBF8Obae+S0R9/YiWtIhlhe6IFbB+0mFc5OdCBXu0gMGIiCJyBBI+w9utUAhNb5jOGV1Pm90jOzMYdPwCrZg8uMznU+N10c6aJSNU05zb5wwsJoQvWGS0IMLVtzoGNInukGVzkOzBix7/NZyYRpIYAeeVFoKjECx5BjjkuQWEVbhsauLEbjyTBdSNzZadhUoCOTRJUZ6RhRBk3Az97t6+ThPkQVXO7nvPhLjNLTZoghXl9xuVkoLbGvmr15QqI3BLbDWZFIPez1u1OoCNTHqMrFswDu45sbpogDVl49cHjCcT+8j6Bkysok3FJMb5K3vzE2Ma3do94R24gsCHxCxxKmLYJAarhTzKEaeAKwBf4+dl/3Ehg9xt7Dm7adt3qwuDg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 02176E2458 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39860400002)(39450400003)(199003)(189002)(6436002)(33656002)(105586002)(106116001)(25786008)(68736007)(229853002)(106356001)(2900100001)(189998001)(76176999)(54356999)(81003)(6506006)(6486002)(77096006)(8936002)(50986999)(230783001)(5660300001)(3660700001)(83506001)(97736004)(38730400002)(6246003)(4326007)(2906002)(2950100002)(8676002)(122556002)(3280700002)(102836003)(81166006)(3846002)(6116002)(81156014)(53936002)(305945005)(36756003)(7736002)(86362001)(6512007)(54906002)(92566002)(101416001)(66066001)(4001350100001)(99286003)(82746002)(83716003)(93886004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8D3C9CE0BB048244AE48AAB6027A538D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2017 20:29:59.9611 (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: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 20:30:03 -0000 DQo+PkkgdGhpbmsgeW91J3JlIG92ZXJzdGF0aW5nIGEgcm91dGVyLWNlbnRyaWMgdmlldy4gIEFz IGV4cGxhaW5lZCBiZWZvcmUsDQo+PmJvdGggT1NYIGFuZCBMaW51eCAoYW5kIG1heWJlIG1vcmUp IGhhdmUgImtleWNoYWluIiB1dGlsaXRpZXMgdGhhdCB0aGUNCj4+b3RoZXIgZHJhZnQncyBZQU5H IG1vZHVsZSBpcyBtb2RlbGVkIGFmdGVyLg0KPg0KPkkgdW5kZXJzdGFuZCB0aGF0IHlvdSBmZWVs IHN0cm9uZ2x5IHRoYXQgeW91ciB3b3JrIGlzIHZlcnkgaW1wb3J0YW50IGJ1dCwNCj5saWtlIHRo ZSBiYXNpYyByb3V0aW5nIHByb3RvY29scywgdGhlcmUgYXJlIG5ldHdvcmsgZGV2aWNlcyBvdGhl ciB0aGFuDQo+cm91dGVycyB0aGF0IHdpbGwgaW1wbGVtZW50IHByb3RvY29sIGF1dGhlbnRpY2F0 aW9uIGJhc2VkIG9uIGtleS1jaGFpbnMuDQoNCllvdSBtaXN1bmRlcnN0YW5kLCB0aGlzIGhhcyBu b3RoaW5nIHRvIGRvIHdpdGggbWUuICBJdCdzIHNpbXBseSBhIGZhY3QgdGhhdA0KImtleSBjaGFp biIgbWVhbnMgZGlmZmVyZW50IHRoaW5ncyB0byBkaWZmZXJlbnQgZ3JvdXBzIG9mIHBlb3BsZS4N Cg0KDQo+Pj4+IGluIGNhc2UgdGhleSBsYW5kIG9uIHlvdXJzIGJ5IGFjY2lkZW50LCBvciBhcmUg b3RoZXJ3aXNlIGludGVyZXN0ZWQgaW4NCj4+Pj4gc2VlaW5nIGhvdyBrZXlzIGFyZSBoYW5kbGVk IHRoZXJlLg0KPj4+DQo+Pj4gSSBkb27CuXQgZmVlbCB0aGlzIGlzIG5lY2Vzc2FyeS4NCj4+DQo+ PkJ1dCBpdCB3b3VsZCBiZSBoZWxwZnVsLg0KPg0KPkkgZGlzYWdyZWUgYW5kIGJlbGlldmUgdGhp cyB3b3VsZCBzZXQgYSBiYWQgcHJlY2VkZW50LiBDYW4geW91IHBvaW50IHRvDQo+b3RoZXIgUkZD cyB0aGF0IGhhdmUgcmVmZXJlbmNlcyB0byBvdGhlciBkb2N1bWVudHMgaW4gY2FzZSByZWFkZXJz IHdlcmUNCj5sb29raW5nIGZvciB0aG9zZSBkb2N1bWVudHMgcmF0aGVyIHRoYW4gdGhlIGRvY3Vt ZW50IGl0c2VsZj8gV2VyZSB5b3UNCj5wbGFubmluZyBvbiBhZGRpbmcgcmVmZXJlbmNlcyBpbiB0 aGUga2V5c3RvcmUgbW9kZWwgdG8gb3RoZXIgZG9jdW1lbnRzDQo+dGhhdCByZWFkZXJzIG1heSBo YXZlIGJlZW4gc2VhcmNoaW5nIGZvcj8NCg0KVGhlIGtleXN0b3JlIGRyYWZ0IGFscmVhZHkgaGFz IGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byB5b3VyIGRyYWZ0Lg0KDQoNCksuDQoNCg0K From nobody Mon Feb 13 12:46:40 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13966129585; Mon, 13 Feb 2017 12:46:39 -0800 (PST) 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 uTuXyrMYBrqV; Mon, 13 Feb 2017 12:46:37 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B947C12940F; Mon, 13 Feb 2017 12:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2016; q=dns/txt; s=iport; t=1487018797; x=1488228397; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UVgpEkxyC9+INcnyAyswqLDysZUdbHb1TeT18ekjvWc=; b=mCcf+hIsODZiPOKv5NSOrzJwGN2bHf7ripLUe/I8OQaKRi06yLFvxyLL jTkcHHTtebReZ/aqww7xbcqbLYoz06QTwPEHQldO52Y97Wo5sJIcgFmXx 91eTpwNUHo3+xWETgaKU7V5vSbpSYeNsADRbQXhUpdkEVJZbMrAi15sJV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCjGqJY/5BdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1KBageDUooIpTSCD4IMhiICGoFUPxgBAgEBAQEBAQFiKIRqBjR?= =?us-ascii?q?FEAIBCA4OKAICMCUCBAENBYlqkTGdRgaCJ4tTAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?R+BBYo2hFSDAIJGHwEEj0KMMAGSE5EFkxQBHziBAFEVhwB1iSGBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,157,1484006400"; d="scan'208";a="385103548" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 20:46:36 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1DKkaso022518 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Feb 2017 20:46:36 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 13 Feb 2017 15:46:35 -0500 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, 13 Feb 2017 15:46:35 -0500 From: "Acee Lindem (acee)" To: Kent Watsen , Juergen Schoenwaelder , Ladislav Lhotka Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFnU/wA//+7Z+2AAGWzgP//uomAgAB7iwD//7OegAALHVCA//+wzgA= Date: Mon, 13 Feb 2017 20:46:35 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> <01A89985-1620-4642-BA30-0B8DB0881971@juniper.net> In-Reply-To: <01A89985-1620-4642-BA30-0B8DB0881971@juniper.net> 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.195] Content-Type: text/plain; charset="euc-kr" Content-ID: <40BEC7F72E4F28429518C12261D55CDD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 20:46:39 -0000 DQoNCk9uIDIvMTMvMTcsIDM6MjkgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5u ZXQ+IHdyb3RlOg0KDQo+DQo+Pj5JIHRoaW5rIHlvdSdyZSBvdmVyc3RhdGluZyBhIHJvdXRlci1j ZW50cmljIHZpZXcuICBBcyBleHBsYWluZWQgYmVmb3JlLA0KPj4+Ym90aCBPU1ggYW5kIExpbnV4 IChhbmQgbWF5YmUgbW9yZSkgaGF2ZSAia2V5Y2hhaW4iIHV0aWxpdGllcyB0aGF0IHRoZQ0KPj4+ b3RoZXIgZHJhZnQncyBZQU5HIG1vZHVsZSBpcyBtb2RlbGVkIGFmdGVyLg0KPj4NCj4+SSB1bmRl cnN0YW5kIHRoYXQgeW91IGZlZWwgc3Ryb25nbHkgdGhhdCB5b3VyIHdvcmsgaXMgdmVyeSBpbXBv cnRhbnQgYnV0LA0KPj5saWtlIHRoZSBiYXNpYyByb3V0aW5nIHByb3RvY29scywgdGhlcmUgYXJl IG5ldHdvcmsgZGV2aWNlcyBvdGhlciB0aGFuDQo+PnJvdXRlcnMgdGhhdCB3aWxsIGltcGxlbWVu dCBwcm90b2NvbCBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBrZXktY2hhaW5zLg0KPg0KPllvdSBt aXN1bmRlcnN0YW5kLCB0aGlzIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggbWUuICBJdCdzIHNpbXBs eSBhIGZhY3QNCj50aGF0DQo+ImtleSBjaGFpbiIgbWVhbnMgZGlmZmVyZW50IHRoaW5ncyB0byBk aWZmZXJlbnQgZ3JvdXBzIG9mIHBlb3BsZS4NCj4NCj4NCj4+Pj4+IGluIGNhc2UgdGhleSBsYW5k IG9uIHlvdXJzIGJ5IGFjY2lkZW50LCBvciBhcmUgb3RoZXJ3aXNlIGludGVyZXN0ZWQNCj4+Pj4+ aW4NCj4+Pj4+IHNlZWluZyBob3cga2V5cyBhcmUgaGFuZGxlZCB0aGVyZS4NCj4+Pj4NCj4+Pj4g SSBkb26p9nQgZmVlbCB0aGlzIGlzIG5lY2Vzc2FyeS4NCj4+Pg0KPj4+QnV0IGl0IHdvdWxkIGJl IGhlbHBmdWwuDQo+Pg0KPj5JIGRpc2FncmVlIGFuZCBiZWxpZXZlIHRoaXMgd291bGQgc2V0IGEg YmFkIHByZWNlZGVudC4gQ2FuIHlvdSBwb2ludCB0bw0KPj5vdGhlciBSRkNzIHRoYXQgaGF2ZSBy ZWZlcmVuY2VzIHRvIG90aGVyIGRvY3VtZW50cyBpbiBjYXNlIHJlYWRlcnMgd2VyZQ0KPj5sb29r aW5nIGZvciB0aG9zZSBkb2N1bWVudHMgcmF0aGVyIHRoYW4gdGhlIGRvY3VtZW50IGl0c2VsZj8g V2VyZSB5b3UNCj4+cGxhbm5pbmcgb24gYWRkaW5nIHJlZmVyZW5jZXMgaW4gdGhlIGtleXN0b3Jl IG1vZGVsIHRvIG90aGVyIGRvY3VtZW50cw0KPj50aGF0IHJlYWRlcnMgbWF5IGhhdmUgYmVlbiBz ZWFyY2hpbmcgZm9yPw0KPg0KPlRoZSBrZXlzdG9yZSBkcmFmdCBhbHJlYWR5IGhhcyBhbiBpbmZv cm1hdGl2ZSByZWZlcmVuY2UgdG8geW91ciBkcmFmdC4NCg0KSSBsb29rZWQgYXQgdGhlIHRleHQg YW5kIHJlZmVyZW5jZSBpbiB0aGUga2V5c3RvcmUgZHJhZnQgYW5kIEkgc3RpbGwgZG9uoa90DQpm ZWVsIHRoYXQgdGhpcyB3aWxsIGJlIGltcG9ydGFudCBvbmNlIHRoZSB0d28gZG9jdW1lbnRzIGFy ZSBwdWJsaXNoZWQuDQoNCkFjZWUNCg0KDQoNCj4NCj4NCj5LLg0KPg0KPg0KDQo= From nobody Mon Feb 13 14:02:15 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A495129994; Mon, 13 Feb 2017 14:02:13 -0800 (PST) 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 48-uO5FGc5mO; Mon, 13 Feb 2017 14:02:12 -0800 (PST) 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 0D57012999A; Mon, 13 Feb 2017 14:02:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CE6866A4; Mon, 13 Feb 2017 23:02:01 +0100 (CET) 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 Cp9h83dgPfix; Mon, 13 Feb 2017 23:02:00 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 13 Feb 2017 23:02:01 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8454C200C1; Mon, 13 Feb 2017 23:02:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ma2DZVPHeoJI; Mon, 13 Feb 2017 23:02:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EF09200BE; Mon, 13 Feb 2017 23:02:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8F5B63E74652; Mon, 13 Feb 2017 23:02:04 +0100 (CET) Date: Mon, 13 Feb 2017 23:02:04 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170213220204.GB11730@elstar.local> Mail-Followup-To: Kent Watsen , Ladislav Lhotka , Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170213152720.GB11159@elstar.local> <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C08D428-1895-40D7-A732-BF42620F5DE6@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 22:02:13 -0000 On Mon, Feb 13, 2017 at 04:31:35PM +0000, Kent Watsen wrote: > > I agree. Having the intermediate revisions listed at all was only intended for while a draft was work in progress. The final RFC module's history should only reflect other published modules. > > BTW, Acee, I noticed in Section 2: > > The module name was change from ietf-key-chain to ietf-routing-key- > chain to avoid disambiguate it from the ietf-system-keychain module > defined in [NETCONF-SERVER-CONF]. However, due to popular demand, > the module name has been restored to simply ietf-key-chain. > > Please note that the NETCONF keychain model has since been renamed and pulled out into its own draft (draft-ietf-netconf-keystore), since folks remained confused after your draft didn't change its name. No worries, "keystore" is a more apt name for my draft's models anyway. > As said before, the module names I have seen so far to not indicate very well the difference between these two models and where they are applicable. /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 Mon Feb 13 19:02:29 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D611A1294CC; Mon, 13 Feb 2017 19:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 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=-1.887, 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 hPl6mCCWyk4Y; Mon, 13 Feb 2017 19:02:24 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0114.outbound.protection.outlook.com [104.47.41.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B698C1293F3; Mon, 13 Feb 2017 19:02:24 -0800 (PST) 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=hLkIyLOuu8Z6/2uOqj+UD7smsePCHxed3zy4DZeheWM=; b=d609NY3+G0oWuzYbrEjBn1kKA+q+M0KHx5MpwNCVTf3a43GIs+0k5gPJ/yvbMPqbudiihFjULguvZmo5NhKoRRFvhgunV2lf50v54mQU+WUsFXXNNDUvFQ2oclApy2/z91wWePJxc8DVBAwb9CzCGFr2J2d1/7CMvV0QpyQYYfA= 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_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 14 Feb 2017 03:02:22 +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.0919.011; Tue, 14 Feb 2017 03:02:22 +0000 From: Kent Watsen To: "i2rs@ietf.org" Thread-Topic: modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9g== Date: Tue, 14 Feb 2017 03:02:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 02dbe24f-0457-4317-5611-08d45485e5db x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:aSi0uQhztQPy0I00bJszzc0Ck0iOieRDyTThXZ+zwiHDghWuKuWmpQf7xIeUczeJ8tP4Q50tO5wO7Ru7+YMEj/dHeeEJyMDPoELOVPumEDvMMQR8nrBrV3MCnoB1eCI5HPrPqp8Jum4YmeWzH6ECbt8mK9R3xlFebHni3IE4k54tQ7x/UzFtzb9seJNrrfKU40reqr9qpBxnqtaPoE/ve40oBcpRyJiJUwevqqfhVuB7wdNAOaEXAWRB4CR/d0W/h31L5CXkUveaHDImUck/FQoogl/oSwzeDMsqnXjK9dbczGJdh2JirGdI/h2P3ucJT3bJN08ffM0GF2zNJohZUaCbo1JfFi5TBrEKuTtLKi4FP41X1V/cOD9lB22dmmT0IyX6wS8JfyGDa+3qwNVWAlf6/5qOT0FSIenlAMAdSZkDFKywyfYBePB/+o8wPBuKIpw15fVr+kohadTS4gBNz7unEal74it6jYTxiYQOjJUYG4ILaURjMELnHGJ7VoDqbFKZy4f0t5ylzlHXx48SYA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39850400002)(39450400003)(199003)(189002)(52314003)(53754006)(6512007)(25786008)(6436002)(6306002)(6506006)(54356999)(5640700003)(99286003)(101416001)(83716003)(7736002)(6486002)(305945005)(83506001)(82746002)(50986999)(77096006)(6916009)(4001350100001)(3280700002)(86362001)(2906002)(53936002)(38730400002)(3660700001)(2900100001)(450100001)(122556002)(33656002)(97736004)(110136004)(4326007)(8936002)(8676002)(92566002)(81166006)(230783001)(81156014)(189998001)(66066001)(36756003)(68736007)(3846002)(102836003)(6116002)(2351001)(105586002)(106116001)(2501003)(5660300001)(106356001)(81003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <067BE61197D8D34584B8EBC789B28B00@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 03:02:22.8722 (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: Cc: yang-doctors Subject: [yang-doctors] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 03:02:27 -0000 SGkgQWxsLA0KDQpJdCdzIGJlZW4gcXVpZXQgb24gdGhlIGxpc3QgYXMgYSBzbWFsbCBncm91cCBv ZiB1cyAoQWxleCwgWHVmZW5nLCBQYXZhbiwgYW5kIG15c2VsZikgd2VudCBvZmZsaW5lIHRvIGRp c2N1c3MgZm9yIGEgYml0IGJlZm9yZSBicmluZ2luZyBiYWNrIHRvIHRoZSBncm91cCwgd2hpY2gg SSdtIGRvaW5nIG5vdy4NCg0KUmVnYXJkaW5nIHJlc29sdmluZyB0aGUgbW9kZWxpbmcgdGhlIGlz c3VlLCB3ZSB3ZW50IHRocm91Z2ggbmVhcmx5IGEgZG96ZW4gaWRlYXMgdGhhdCB3ZSd2ZSBuYXJy b3dlZCBkb3duIHRvIHR3by4gIFdlIGRpc2N1c3NlZCB0aGUgcHJvcy9jb25zLCBidXQgc2luY2Ug d2UgZWFjaCBlbXBoYXNpemUgZGlmZmVyZW50IHZhbHVlcywgd2Ugd2VyZSB1bmFibGUgdG8gcmVh Y2ggYSBjb25zZW5zdXMgYW1vbmdzdCBvdXJzZWx2ZXMuICBXZSdyZSBob3BpbmcgdGhhdCBicmlu Z2luZyB0aGUgZGlzY3Vzc2lvbiBoZXJlIHdpbGwgYnJpbmcgbW9yZSBwZXJzcGVjdGl2ZXMgYW5k IHJlc29sdmUgdGhpcyBpc3N1ZS4NCg0KDQpPUFRJT04gMTogc2VwYXJhdGUgL2ZvbyBhbmQgL2Zv by1zdGF0ZSB0cmVlcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KVGhpcyBvcHRpb24gd2FzL2lzIGRlc2NyaWJlZCBoZXJlOiAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMnJzL2N1cnJlbnQvbXNnMDQzMTYuaHRtbC4NCg0KUFJP UzoNCiAgYSkgZG9lcyBOT1QgYnJlYWsgbGVnYWN5IGNsaWVudHMgKGhvdyB3ZSBnb3QgaGVyZSkN CiAgYikgY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxl cw0KICBjKSBhYmxlIHRvIHNob3cgaWYvaG93IG9wc3RhdGUgbWF5IGRpZmZlciBmcm9tIGNvbmZp Z3VyZWQgdmFsdWVzDQoNCkNPTlM6DQogIGEpIHF1ZXN0aW9uYWJseSB2YWxpZCBZQU5HIGxlYWZy ZWYgdXNhZ2UNCiAgYikgY29tcGxleCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gKHRvIGhhbmRsZSBy ZXF1aXJlLWluc3RhbmNlIGZhbHNlKQ0KICBjKSBldmVudHVhbGx5IHRoZSBtb2R1bGUgd291bGQg bmVlZCB0byBtaWdyYXRlIHRvIHRoZSBsb25nLXRlcm0gDQogICAgIHNvbHV0aW9uLCB3aGljaCB3 b3VsZCByZXN1bHQgaW4gbmVlZGluZyB0byBhbHNvIHJld3JpdGUgYWxsDQogICAgIG1vZHVsZXMg dGhhdCBoYXZlIGF1Z21lbnRlZCBpdCAoZS5nLiwgaWV0Zi10ZS10b3BvbG9neSkuDQogIGQpIGxl YWZyZWYgcGF0aCBleHByZXNzaW9ucyByZWFsbHkgb25seSB3b3JrIGZvciBjb25maWd1cmF0aW9u IGRhdGEsDQogICAgIHRob3VnaCBhIGNsZXZlciBzZXJ2ZXIgY291bGQgaGF2ZSBhIHNwZWNpYWwg YWJpbGl0eSB0byBwZWFrIGF0DQogICAgIHRoZSBvcHN0YXRlIHZhbHVlcyB3aGVuIGRvaW5nIHZh bGlkYXRpb25zLiAgT2YgY291cnNlLCB3aXRoIA0KICAgICByZXF1aXJlLWluc3RhbmNlIGlzIGZh bHNlLCB0aGUgdmFsdWUgb2YgbGVhZnJlZiBiYXNlZCB2YWxpZGF0aW9uDQogICAgIGNoZWNraW5n IGlzIG5lZ2F0ZWQgYW55d2F5LCBldmVuIGZvciBjb25maWcgdHJ1ZSBub2Rlcywgc28gdGhpcw0K ICAgICBtYXkgbm90IG1hdHRlciBtdWNoLg0KDQoNCg0KT1BUSU9OIDI6IGV4cGxpY2l0IGNsaWVu dC1vcHRpb24gdG8gYWxzbyByZXR1cm4gdGFnZ2VkIG9wc3RhdGUgZGF0YQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpUaGlzIG9wdGlvbiB0YWtlcyBhIGNvdXBsZSBmb3Jtcy4gIFRoZSBmaXJzdCBpcyBtb2R1bGUt c3BlY2lmaWMgYW5kDQp0aGUgc2Vjb25kIGlzIGdlbmVyaWMuICBJbiBib3RoIGNhc2VzLCB0aGUg aWRlYSBpcyBtb2RlbGVkIGFmdGVyIHRoZQ0Kd2l0aC1kZWZhdWx0cyBzb2x1dGlvbiAoUkZDNjI0 MyksIHdoZXJlaW4gdGhlIGNsaWVudCBwYXNzZXMgYSBzcGVjaWFsDQpmbGFnIGludG8gPGdldC1j b25maWc+IGNhdXNpbmcgdGhlIHNlcnZlciB0byBhbHNvIHJldHVybiBvcHN0YXRlIGRhdGEsDQpo YXZpbmcgYSBzcGVjaWFsIG1ldGFkYXRhIGZsYWcgc2V0LCBpbnRlcm1pbmdsZWQgd2l0aCB0aGUg Y29uZmlndXJhdGlvbg0KZGF0YS4NCg0KDQoyQTogTW9kdWxlLXNwZWNpZmljIHZlcnNpb24NCg0K ICAgbW9kdWxlIGZvbyB7DQogICAgICBpbXBvcnQgaWV0Zi1uZXRjb25mIHsgcHJlZml4IG5jOyB9 DQogICAgICBpbXBvcnQgaWV0Zi15YW5nLW1ldGFkYXRhIHsgcHJlZml4IG1kOyB9DQogICAgICBt ZDphbm5vdGF0aW9uIHNlcnZlci1wcm92aWRlZCB7DQogICAgICAgICB0eXBlIGJvb2xlYW47DQog ICAgICB9DQogICAgICBjb250YWluZXIgbm9kZXMgew0KICAgICAgICAgY29uZmlnIHRydWU7DQog ICAgICAgICBsaXN0IG5vZGUgew0KICAgICAgICAgICAga2V5ICJuYW1lIjsNCiAgICAgICAgICAg IGxlYWYgbmFtZSB7IHR5cGUgc3RyaW5nOyB9DQogICAgICAgICAgICBsZWFmIGRlcGVuZGVuY3kg ew0KICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCiAgICAgICAgICAgICAgICAgcGF0aCAi Li4vbm9kZS9uYW1lIg0KICAgICAgICAgICAgICAgICByZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0K ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KICAgICAgICAgfQ0KICAgICAgfQ0KICAg ICAgYXVnbWVudCAvbmM6Z2V0LWNvbmZpZy9uYzppbnB1dCB7DQogICAgICAgICBsZWFmIHdpdGgt c2VydmVyLXByb3ZpZGVkIHsNCiAgICAgICAgICAgIHR5cGUgYm9vbGVhbjsNCiAgICAgICAgIH0N CiAgICAgIH0NCiAgIH0NCg0KRm9yIGluc3RhbmNlOg0KDQogIDxnZXQtY29uZmlnPg0KICAgIDxz b3VyY2U+DQogICAgICA8cnVubmluZy8+DQogICAgPC9zb3VyY2U+DQogICAgPHdpdGgtc2VydmVy LXByb3ZpZGVkLz4NCiAgIDwvZ2V0LWNvbmZpZz4NCg0KICAgPGRhdGE+DQogICAgIDxub2Rlcz4N CiAgICAgICA8bm9kZT4NCiAgICAgICAgIDxuYW1lPm92ZXJsYXktbm9kZTwvbmFtZT4NCiAgICAg ICAgIDxkZXBlbmRlbmN5PnVuZGVybGF5LW5vZGU8L2RlcGVuZGVuY3k+DQogICAgICAgPC9ub2Rl Pg0KICAgICAgIDxub2RlIGZvbzpzZXJ2ZXItcHJvdmlkZWQ9J3RydWUnPg0KICAgICAgICAgPG5h bWU+dW5kZXJsYXktbm9kZTwvbmFtZT4NCiAgICAgICA8L25vZGU+DQogICAgIDwvbm9kZXM+DQog ICA8L2RhdGE+DQoNClBST1M6DQogIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBjbGllbnRzICho b3cgd2UgZ290IGhlcmUpDQogIGIpIGhhdmluZyBhbGwgZGF0YSBpbiBvbmUgbWVyZ2VkIHRyZWUg aXMgc2ltcGxlciB0byBwcm9jZXNzIA0KICAgICB0aGFuIHR3byBzZXBhcmF0ZSBxdWVyaWVzLg0K ICBjKSBtb2R1bGUgZG9lc24ndCBoYXZlIHRvIGJlIHJld3JpdHRlbiBmb3IgcmV2aXNlZC1kYXRh c3RvcmVzOw0KICAgICB0aGUgJ3dpdGgtc2VydmVyLXByb3ZpZGVkJyBzd2l0Y2ggd291bGQganVz dCBub3QgYmUgcGFzc2VkDQogICAgIGJ5IG5ldyBvcHN0YXRlLWF3YXJlIGNsaWVudHMuDQoNCkNP TlM6DQogIGEpIGluY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYg bW9kdWxlcw0KICBiKSB1bmNsZWFyIGhvdyB0byBtb2RlbCAnd2l0aC1zZXJ2ZXItcHJvdmlkZWQn IGZvciBSRVNUQ09ORg0KICAgICAoanVzdCB1c2UgYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgdG8g ZGVmaW5lIGEgcXVlcnkgcGFyYW0/KQ0KICBjKSB1bmFibGUgdG8gcmV0dXJuIHRoZSBvcHN0YXRl IHZhbHVlIGZvciBhbnkgY29uZmlndXJlZCBub2RlDQogICAgIChpcyBpdCBuZWVkZWQgaGVyZT8p DQogIGQpIHJlcXVpcmVzIHNlcnZlciB0byBzdXBwb3J0IG1ldGFkYXRhLCB3aGljaCBpcyBhIHJl bGF0aXZlbHkNCiAgICAgbmV3IGNvbmNlcHQgYW5kIG1heWJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBi eSBzZXJ2ZXJzLg0KICBlKSBvbmx5IGNoYW5nZXMgcHJlc2VudGF0aW9uLWxheWVyIChkb2Vzbid0 IGNoYW5nZSB0aGUgZmFjdCANCiAgICAgdGhhdCAnc2VydmVyLXByb3ZpZGVkJyBkYXRhIGlzIG5v dCBjb25maWd1cmF0aW9uKSwgdGh1cyB0aGUNCiAgICAgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25z IHN0aWxsIGRvbid0IHdvcmsgcXVpdGUgdGhlIHdheSBhcw0KICAgICBkZXNpcmVkLCB0aG91Z2gg YSBjbGV2ZXIgc2VydmVyIGNvdWxkIGhhdmUgYSBzcGVjaWFsIGFiaWxpdHkNCiAgICAgdG8gcGVh ayBhdCB0aGUgb3BzdGF0ZSB2YWx1ZXMgd2hlbiBkb2luZyB2YWxpZGF0aW9ucy4gT2YgDQogICAg IGNvdXJzZSwgd2l0aCByZXF1aXJlLWluc3RhbmNlIGlzIGZhbHNlLCB0aGUgdmFsdWUgb2YgbGVh ZnJlZg0KICAgICBiYXNlZCB2YWxpZGF0aW9uIGNoZWNraW5nIGlzIG5lZ2F0ZWQgYW55d2F5LCBl dmVuIGZvciBjb25maWcNCiAgICAgdHJ1ZSBub2Rlcywgc28gdGhpcyBtYXkgbm90IG1hdHRlciBt dWNoLg0KDQoNCg0KDQoyQjogR2VuZXJpYyB2ZXJzaW9uDQoNClRoZSBnZW5lcmljIHZlcnNpb24g aXMgbXVjaCB0aGUgc2FtZSwgYnV0IHJhdGhlciB0aGFuIGxldHRpbmcgdGhlDQpzb2x1dGlvbiBi ZSBsaW1pdGVkIHRvIHRoaXMgb25lIG1vZHVsZSwgdGhlIGlkZWEgaXMgdG8gZ2VuZXJhbGl6ZQ0K aXQgc28gaXQgY291bGQgYmUgYSBzZXJ2ZXItbGV2ZWwgZmVhdHVyZS4gIEhhdmluZyBhIGdlbmVy aWMgUlBDIHRvDQpyZXR1cm4gZGF0YSBmcm9tIG1vcmUgdGhhbiBvbmUgRFMgYXQgYSB0aW1lIHdh cyBzb21ldGhpbmcgdGhhdCB3YXMNCmRpc2N1c3NlZCB+MS41IHllYXJzIGFnbyB3aGVuIHdlIHdl cmUga2lja2luZyBvZmYgdGhlIG9wc3RhdGUgZWZmb3J0Lg0KDQpUaGUgUFJPUyBhbmQgQ09OUyBh cmUgc2ltaWxhciwgYnV0IHRoZXJlIGFyZSBhZGRpdGlvbmFsIENPTlMgaW4gdGhlDQpnZW5lcmlj IGNhc2UuICBUaGUgbWFpbiBvbmVzIGJlaW5nIDEpIGhvdyB0byBzaW11bHRhbmVvdXNseSByZXR1 cm4gDQpib3RoIHRoZSBjb25maWcgYW5kIG9wc3RhdGUgdmFsdWVzIGZvciBhIG5vZGUgKHNwbGl0 IGF0IHRoZSBsZWF2ZXMpDQphbmQgMikgaG93IHRvIGhhbmRsZSBzb21lIFlBTkcgc3RhdGVtZW50 cyBzdWNoIGFzIHByZXNlbmNlIGNvbnRhaW5lcnMNCmFuZCBjaG9pY2Ugbm9kZXMuICBGb3IgdGhp cyByZWFzb24sICgyQikgaXMgTk9UIGNvbnNpZGVyZWQgYSB2aWFibGUNCnNvbHV0aW9uIGFuZCBp cyBvbmx5IGhlcmUgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQgd2FzIGRpc2N1c3NlZC4NCg0K DQoNCklmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb3B0aW9ucyBwZW9wbGUgd2FudCB0byBzdWdnZXN0 LCBwbGVhc2UgZG8gc28gbm93IQ0KDQpUaGFua3MsDQpLZW50DQoNCg0KDQo= From nobody Tue Feb 14 03:09:19 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB00129568; Tue, 14 Feb 2017 03:09:14 -0800 (PST) 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 5H9puXUe5ZCf; Tue, 14 Feb 2017 03:09:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAD1293E8; Tue, 14 Feb 2017 03:09:12 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id CCD4A1AE034F; Tue, 14 Feb 2017 12:09:10 +0100 (CET) Date: Tue, 14 Feb 2017 12:09:10 +0100 (CET) Message-Id: <20170214.120910.763903356597953031.mbj@tail-f.com> To: kwatsen@juniper.net 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: Cc: i2rs@ietf.org, yang-doctors@ietf.org Subject: Re: [yang-doctors] [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 11:09:15 -0000 Hi, Kent Watsen wrote: > Hi All, > > It's been quiet on the list as a small group of us (Alex, Xufeng, > Pavan, and myself) went offline to discuss for a bit before bringing > back to the group, which I'm doing now. > > Regarding resolving the modeling the issue, we went through nearly a > dozen ideas that we've narrowed down to two. We discussed the > pros/cons, but since we each emphasize different values, we were > unable to reach a consensus amongst ourselves. We're hoping that > bringing the discussion here will bring more perspectives and resolve > this issue. > > > OPTION 1: separate /foo and /foo-state trees > -------------------------------------------- > > This option was/is described here: > https://www.ietf.org/mail-archive/web/i2rs/current/msg04316.html. > > PROS: > a) does NOT break legacy clients (how we got here) > b) consistent with convention used in many IETF modules > c) able to show if/how opstate may differ from configured values > > CONS: > a) questionably valid YANG leafref usage What does this mean? > b) complex server implementation (to handle require-instance false) Can you elaborate on this one? > c) eventually the module would need to migrate to the long-term > solution, which would result in needing to also rewrite all > modules that have augmented it (e.g., ietf-te-topology). > d) leafref path expressions really only work for configuration data, > though a clever server could have a special ability to peak at > the opstate values when doing validations. Of course, with > require-instance is false, the value of leafref based validation > checking is negated anyway, even for config true nodes, so this > may not matter much. > > > > OPTION 2: explicit client-option to also return tagged opstate data > ------------------------------------------------------------------- > > This option takes a couple forms. The first is module-specific and > the second is generic. In both cases, the idea is modeled after the > with-defaults solution (RFC6243), wherein the client passes a special > flag into causing the server to also return opstate data, > having a special metadata flag set, intermingled with the > configuration > data. > > > 2A: Module-specific version > > module foo { > import ietf-netconf { prefix nc; } > import ietf-yang-metadata { prefix md; } > md:annotation server-provided { > type boolean; > } > container nodes { > config true; > list node { > key "name"; > leaf name { type string; } > leaf dependency { > type leafref { > path "../node/name" > require-instance false; > } > } > } > } > augment /nc:get-config/nc:input { > leaf with-server-provided { > type boolean; > } > } > } I don't think this solution is substantially different from the solution in draft-ietf-i2rs-yang-network-topo-10. You have just moved a config false leaf to a meta-data annotation. This solution suffers from the same problems as the solution in draft-ietf-i2rs-yang-network-topo-10. /martin > > For instance: > > > > > > > > > > > > overlay-node > underlay-node > > > underlay-node > > > > > PROS: > a) does NOT break legacy clients (how we got here) > b) having all data in one merged tree is simpler to process > than two separate queries. > c) module doesn't have to be rewritten for revised-datastores; > the 'with-server-provided' switch would just not be passed > by new opstate-aware clients. > > CONS: > a) inconsistent with convention used in many IETF modules > b) unclear how to model 'with-server-provided' for RESTCONF > (just use a description statement to define a query param?) > c) unable to return the opstate value for any configured node > (is it needed here?) > d) requires server to support metadata, which is a relatively > new concept and maybe not well supported by servers. > e) only changes presentation-layer (doesn't change the fact > that 'server-provided' data is not configuration), thus the > leafref path expressions still don't work quite the way as > desired, though a clever server could have a special ability > to peak at the opstate values when doing validations. Of > course, with require-instance is false, the value of leafref > based validation checking is negated anyway, even for config > true nodes, so this may not matter much. > > > > > 2B: Generic version > > The generic version is much the same, but rather than letting the > solution be limited to this one module, the idea is to generalize > it so it could be a server-level feature. Having a generic RPC to > return data from more than one DS at a time was something that was > discussed ~1.5 years ago when we were kicking off the opstate effort. > > The PROS and CONS are similar, but there are additional CONS in the > generic case. The main ones being 1) how to simultaneously return > both the config and opstate values for a node (split at the leaves) > and 2) how to handle some YANG statements such as presence containers > and choice nodes. For this reason, (2B) is NOT considered a viable > solution and is only here so that it's clear that it was discussed. > > > > If there are any other options people want to suggest, please do so > now! > > Thanks, > Kent > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Feb 14 09:23:43 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D670129621 for ; Tue, 14 Feb 2017 05:55:56 -0800 (PST) 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=unavailable 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 5920Qnr4i0PL for ; Tue, 14 Feb 2017 05:55:54 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0393C129639 for ; Tue, 14 Feb 2017 05:55:54 -0800 (PST) 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=ovby2pmT+m3NcyYzG45+grsygt+jlrGtLxfzcLhQfTo=; b=NSvRgPyrr1g0dnQDu8ova2FpMQkXX+ctTxEDH8ueDzqsC/OV3s58R/B2ZtCXg3qflli/TrHgEho6GC1wwmu1zea0xpsEJUHJAzaXBxtkayJkui9Vtv+XPEAU9aTpPIFzKwyHQkvvgbmHiepdHzYjm9Fzfj3qcDPwcXqdIAhNg20= 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_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 14 Feb 2017 13:55:51 +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.0919.011; Tue, 14 Feb 2017 13:55:51 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYA= Date: Tue, 14 Feb 2017 13:55:51 +0000 Message-ID: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> References: <20170214.120910.763903356597953031.mbj@tail-f.com> In-Reply-To: <20170214.120910.763903356597953031.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 9a077415-d5f3-400a-da4d-08d454e13032 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:SesiuKO5S2QMkKIXR6zBY8+Y0Dl0jEFMHioFxp0ezKV3YS7YuFCjNJK2YySW0PqdFBYtQ0sPQndhUuGJP+wIbtebQiMZNpjTqgSAthlQBZq3VvfEndBKlbvAYYkks+K7pXX74+cTgXzO3phcxJXvTCAD8zCR8O/Y4yUWCM46pLqVSGlas7DPEmONYLXJSJzZJkHR6VATMz2GZqNeU8kcCQM9YwYGGavy9yGngyWaZEsldsoxd+3OFeTvXxXpXS3H3IPXI6LkqYjDt8wvMo55Q16dSBEkGTKZQppfEJY6+aQ7/U9QjYsip9OetjInUJPiLHanpscr1SWGqAQ/xaKiT25azhTyd+dpF1GcSbMxw5egNo6pryA5IdjnRGAygOQWJDmBz9oMIydySbpmaVk8zB/PZvGjbqCaiA66tqQlsqADElnza86Wn3zaaDxscrgEM6HpQ8fEJMYSgQ9ZMQcsU30VnT7SxRUyGTOajofd8Apkr81LobrLICDjiM1LwDuG5HHjp0YksIhwcl3Z3Zg+ow== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(199003)(189002)(52314003)(82746002)(83506001)(189998001)(38730400002)(53936002)(83716003)(6246003)(110136004)(4326007)(25786008)(50986999)(76176999)(54356999)(86362001)(122556002)(6436002)(77096006)(6486002)(101416001)(33656002)(6506006)(3660700001)(2906002)(5660300001)(66066001)(230783001)(229853002)(106356001)(3846002)(305945005)(102836003)(7736002)(6116002)(6916009)(99286003)(8936002)(92566002)(2950100002)(81156014)(2900100001)(36756003)(4001350100001)(106116001)(8676002)(105586002)(81003)(68736007)(81166006)(6306002)(97736004)(3280700002)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 14 Feb 2017 13:55:51.7274 (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: X-Mailman-Approved-At: Tue, 14 Feb 2017 09:23:42 -0800 Cc: "i2rs@ietf.org" Subject: Re: [yang-doctors] [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 13:55:56 -0000 DQoNClttb3ZpbmcgeWFuZy1kb2N0b3JzIHRvIEJDQ10NCg0KDQo+PiBPUFRJT04gMTogc2VwYXJh dGUgL2ZvbyBhbmQgL2Zvby1zdGF0ZSB0cmVlcw0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPj4gVGhpcyBvcHRpb24gd2FzL2lzIGRlc2NyaWJl ZCBoZXJlOg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMnJzL2N1 cnJlbnQvbXNnMDQzMTYuaHRtbC4NCj4+IA0KPj4gUFJPUzoNCj4+ICAgYSkgZG9lcyBOT1QgYnJl YWsgbGVnYWN5IGNsaWVudHMgKGhvdyB3ZSBnb3QgaGVyZSkNCj4+ICAgYikgY29uc2lzdGVudCB3 aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBjKSBhYmxlIHRv IHNob3cgaWYvaG93IG9wc3RhdGUgbWF5IGRpZmZlciBmcm9tIGNvbmZpZ3VyZWQgdmFsdWVzDQo+ PiANCj4+IENPTlM6DQo+PiAgIGEpIHF1ZXN0aW9uYWJseSB2YWxpZCBZQU5HIGxlYWZyZWYgdXNh Z2UNCj4NCj4gV2hhdCBkb2VzIHRoaXMgbWVhbj8NCg0KSSdtIHJlZmVycmluZyB0byBob3cgdGhl IGRlc2NyaXB0aW9uIHN0YXRlbWVudCBleHBsYWlucyB0aGF0DQp0aGUgc2VydmVyIG1heSBsb29r IHRvIG9wZXJhdGlvbmFsIHN0YXRlIGluIG9yZGVyIHRvIHJlc29sdmUNCnRoZSBsZWFmcmVmLCB3 aGljaCBpcyB0byByZXN1bHQgaW4gYmVoYXZpb3Igc2ltaWxhciB0byANCnByZS1jb25maWd1cmF0 aW9uIGluIFJGQyA3MjIzLg0KDQoNCg0KPj4gICBiKSBjb21wbGV4IHNlcnZlciBpbXBsZW1lbnRh dGlvbiAodG8gaGFuZGxlIHJlcXVpcmUtaW5zdGFuY2UgZmFsc2UpDQo+DQo+Q2FuIHlvdSBlbGFi b3JhdGUgb24gdGhpcyBvbmU/DQoNClRoaXMgaXMgcHJpbWFyaWx5IGEgcmVmbGVjdGlvbiBvZiB0 aGUgQ09OIGxpc3RlZCBhYm92ZSwgaW4gdGhhdA0KaXQgc2VlbXMgdGhhdCBhIHNlcnZlciB3b3Vs ZCBuZWVkIHRvIGhhdmUgc3BlY2lhbCBoYW5kbGluZyBmb3IgDQp3aGVuIGRlcGVuZGVuY2llcyB0 cmFuc2l0aW9uIGZyb20gYmVpbmcgcHJlc2VudCB0byBub3QtcHJlc2VudA0KYW5kIHZpY2UgdmVy c2EsIG11Y2ggbGlrZSB0aGUgY29kZSB0byBoYW5kbGUgd2hlbiBhIHBoeXNpY2FsDQpjYXJkIGlz IHBsdWdnZWQgaW4gb3IgcmVtb3ZlZC4NCg0KTm90ZTogSSBzaG91bGQndmUgbGlzdGVkIHRoaXMg YXMgYSBDT04gZm9yIE9QVElPTiAyIGFzIHdlbGwuDQoNCg0KDQo+PiAgIGMpIGV2ZW50dWFsbHkg dGhlIG1vZHVsZSB3b3VsZCBuZWVkIHRvIG1pZ3JhdGUgdG8gdGhlIGxvbmctdGVybSANCj4+ICAg ICAgc29sdXRpb24sIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiBuZWVkaW5nIHRvIGFsc28gcmV3cml0 ZSBhbGwNCj4+ICAgICAgbW9kdWxlcyB0aGF0IGhhdmUgYXVnbWVudGVkIGl0IChlLmcuLCBpZXRm LXRlLXRvcG9sb2d5KS4NCj4+ICAgZCkgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25zIHJlYWxseSBv bmx5IHdvcmsgZm9yIGNvbmZpZ3VyYXRpb24gZGF0YSwNCj4+ICAgICAgdGhvdWdoIGEgY2xldmVy IHNlcnZlciBjb3VsZCBoYXZlIGEgc3BlY2lhbCBhYmlsaXR5IHRvIHBlYWsgYXQNCj4+ICAgICAg dGhlIG9wc3RhdGUgdmFsdWVzIHdoZW4gZG9pbmcgdmFsaWRhdGlvbnMuICBPZiBjb3Vyc2UsIHdp dGggDQo+PiAgICAgIHJlcXVpcmUtaW5zdGFuY2UgaXMgZmFsc2UsIHRoZSB2YWx1ZSBvZiBsZWFm cmVmIGJhc2VkIHZhbGlkYXRpb24NCj4+ICAgICAgY2hlY2tpbmcgaXMgbmVnYXRlZCBhbnl3YXks IGV2ZW4gZm9yIGNvbmZpZyB0cnVlIG5vZGVzLCBzbyB0aGlzDQo+PiAgICAgIG1heSBub3QgbWF0 dGVyIG11Y2guDQo+PiANCj4+IA0KPj4gDQo+PiBPUFRJT04gMjogZXhwbGljaXQgY2xpZW50LW9w dGlvbiB0byBhbHNvIHJldHVybiB0YWdnZWQgb3BzdGF0ZSBkYXRhDQo+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiANCj4+IFRoaXMgb3B0aW9uIHRha2VzIGEgY291cGxlIGZvcm1zLiAgVGhlIGZpcnN0IGlzIG1v ZHVsZS1zcGVjaWZpYyBhbmQNCj4+IHRoZSBzZWNvbmQgaXMgZ2VuZXJpYy4gIEluIGJvdGggY2Fz ZXMsIHRoZSBpZGVhIGlzIG1vZGVsZWQgYWZ0ZXIgdGhlDQo+PiB3aXRoLWRlZmF1bHRzIHNvbHV0 aW9uIChSRkM2MjQzKSwgd2hlcmVpbiB0aGUgY2xpZW50IHBhc3NlcyBhIHNwZWNpYWwNCj4+IGZs YWcgaW50byA8Z2V0LWNvbmZpZz4gY2F1c2luZyB0aGUgc2VydmVyIHRvIGFsc28gcmV0dXJuIG9w c3RhdGUgZGF0YSwNCj4+IGhhdmluZyBhIHNwZWNpYWwgbWV0YWRhdGEgZmxhZyBzZXQsIGludGVy bWluZ2xlZCB3aXRoIHRoZQ0KPj4gY29uZmlndXJhdGlvbg0KPj4gZGF0YS4NCj4+IA0KPj4gDQo+ PiAyQTogTW9kdWxlLXNwZWNpZmljIHZlcnNpb24NCj4+IA0KPj4gICAgbW9kdWxlIGZvbyB7DQo+ PiAgICAgICBpbXBvcnQgaWV0Zi1uZXRjb25mIHsgcHJlZml4IG5jOyB9DQo+PiAgICAgICBpbXBv cnQgaWV0Zi15YW5nLW1ldGFkYXRhIHsgcHJlZml4IG1kOyB9DQo+PiAgICAgICBtZDphbm5vdGF0 aW9uIHNlcnZlci1wcm92aWRlZCB7DQo+PiAgICAgICAgICB0eXBlIGJvb2xlYW47DQo+PiAgICAg ICB9DQo+PiAgICAgICBjb250YWluZXIgbm9kZXMgew0KPj4gICAgICAgICAgY29uZmlnIHRydWU7 DQo+PiAgICAgICAgICBsaXN0IG5vZGUgew0KPj4gICAgICAgICAgICAga2V5ICJuYW1lIjsNCj4+ ICAgICAgICAgICAgIGxlYWYgbmFtZSB7IHR5cGUgc3RyaW5nOyB9DQo+PiAgICAgICAgICAgICBs ZWFmIGRlcGVuZGVuY3kgew0KPj4gICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCj4+ICAg ICAgICAgICAgICAgICAgcGF0aCAiLi4vbm9kZS9uYW1lIg0KPj4gICAgICAgICAgICAgICAgICBy ZXF1aXJlLWluc3RhbmNlIGZhbHNlOw0KPj4gICAgICAgICAgICAgICAgfQ0KPj4gICAgICAgICAg ICAgfQ0KPj4gICAgICAgICAgfQ0KPj4gICAgICAgfQ0KPj4gICAgICAgYXVnbWVudCAvbmM6Z2V0 LWNvbmZpZy9uYzppbnB1dCB7DQo+PiAgICAgICAgICBsZWFmIHdpdGgtc2VydmVyLXByb3ZpZGVk IHsNCj4+ICAgICAgICAgICAgIHR5cGUgYm9vbGVhbjsNCj4+ICAgICAgICAgIH0NCj4+ICAgICAg IH0NCj4+ICAgIH0NCj4NCj4gSSBkb24ndCB0aGluayB0aGlzIHNvbHV0aW9uIGlzIHN1YnN0YW50 aWFsbHkgZGlmZmVyZW50IGZyb20gdGhlDQo+IHNvbHV0aW9uIGluIGRyYWZ0LWlldGYtaTJycy15 YW5nLW5ldHdvcmstdG9wby0xMC4gIFlvdSBoYXZlIGp1c3QgbW92ZWQNCj4gYSBjb25maWcgZmFs c2UgbGVhZiB0byBhIG1ldGEtZGF0YSBhbm5vdGF0aW9uLiAgVGhpcyBzb2x1dGlvbiBzdWZmZXJz DQo+IGZyb20gdGhlIHNhbWUgcHJvYmxlbXMgYXMgdGhlIHNvbHV0aW9uIGluDQo+IGRyYWZ0LWll dGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0xMC4NCg0KVGhlcmUgYXJlIHR3byBwcmltYXJ5IGRp ZmZlcmVuY2VzOg0KDQoxKSBJdCBkb2Vzbid0IGJyZWFrIGxlZ2FjeSBjbGllbnRzLCBiZWNhdXNl IGl0IHJlcXVpcmVzIHRoZSBjbGllbnQgdG8NCiAgIGV4cGxpY2l0bHkgcGFzcyBhICd3aXRoLXNl cnZlci1wcm92aWRlZCcgZmxhZyBpbiB0aGUgPGdldC1jb25maWc+DQogICByZXF1ZXN0IGluIG9y ZGVyIHRvIGdldCBiYWNrIHRoZSBleHRlbmRlZCByZXNwb25zZS4gIExpa2V3aXNlLCBpdA0KICAg ZG9lc24ndCBicmVhayBiYWNrdXAvcmVzdG9yZSB3b3JrZmxvd3MsIGFzIHRoZSBzZXJ2ZXIgY2Fu IGRpc2NhcmQNCiAgIGFueSAnc2VydmVyLXByb3ZpZGVkJyBub2RlcyBwYXNzZWQgaW4gYW4gPGVk aXQtY29uZmlnPiBvcGVyYXRpb24uDQogICBMYXN0bHksIGl0IGRvZXNuJ3QgYnJlYWsgPGxvY2s+ Lzx1bmxvY2s+LCBhcyB0aGVyZSBpcyBubyBjb21pbmdsaW5nDQogICBvZiBvcHN0YXRlIGRhdGEg aW4gdGhlICdydW5uaW5nJyBkYXRhc3RvcmUuDQoNCjIpIEl0IGRvZXNuJ3Qgc2F5IGFueXRoaW5n IGFib3V0IGhvdyB0aGUgb3BzdGF0ZSBkYXRhIGlzIHN0b3JlZCBvbiB0aGUNCiAgIHNlcnZlci4g IFRoZSBvcHN0YXRlIGRhdGEgaXMgbm90IG1vZGVsZWQgYXQgYWxsLiAgVGhpcyBhcHByb2FjaCAN CiAgIG9ubHkgZGVmaW5lcyBhIHByZXNlbnRhdGlvbi1sYXllciBmb3JtYXQgZm9yIGhvdyBvcHN0 YXRlIGRhdGEgY2FuDQogICBiZSByZXR1cm5lZCB2aWEgYW4gUlBDLiAgVGhlIHNlcnZlciBpcyBm cmVlIHRvIHBlcnNpc3QgdGhlIG9wc3RhdGUNCiAgIGRhdGEgYW55d2F5IGl0IHdhbnRzLCBwZXJo YXBzIGluIGFuIGludGVybmFsIGRhdGFzdG9yZSBjYWxsZWQgDQogICAnb3BlcmF0aW9uYWwtc3Rh dGUnIG9yIGluIGFuIHViZXItZGF0YXN0b3JlIHdpdGggdGhlIG9wc3RhdGUgZGF0YQ0KICAgZmxh Z2dlZCB3aXRoIGEgZGF0YXN0b3JlPSdvcGVyLXN0YXRlJyBhdHRyaWJ1dGUuICBSZWdhcmRsZXNz LCBpdCdzDQogICBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIGFuZCB0aGUgY29uY2VwdHVhbCBk YXRhc3RvcmUgbW9kZWwgaXMNCiAgIHByZXNlcnZlZC4NCg0KDQoNCj4gL21hcnRpbg0KDQpLZW50 DQoNCg0KDQoNCj4+IA0KPj4gRm9yIGluc3RhbmNlOg0KPj4gDQo+PiAgIDxnZXQtY29uZmlnPg0K Pj4gICAgIDxzb3VyY2U+DQo+PiAgICAgICA8cnVubmluZy8+DQo+PiAgICAgPC9zb3VyY2U+DQo+ PiAgICAgPHdpdGgtc2VydmVyLXByb3ZpZGVkLz4NCj4+ICAgIDwvZ2V0LWNvbmZpZz4NCj4+IA0K Pj4gICAgPGRhdGE+DQo+PiAgICAgIDxub2Rlcz4NCj4+ICAgICAgICA8bm9kZT4NCj4+ICAgICAg ICAgIDxuYW1lPm92ZXJsYXktbm9kZTwvbmFtZT4NCj4+ICAgICAgICAgIDxkZXBlbmRlbmN5PnVu ZGVybGF5LW5vZGU8L2RlcGVuZGVuY3k+DQo+PiAgICAgICAgPC9ub2RlPg0KPj4gICAgICAgIDxu b2RlIGZvbzpzZXJ2ZXItcHJvdmlkZWQ9J3RydWUnPg0KPj4gICAgICAgICAgPG5hbWU+dW5kZXJs YXktbm9kZTwvbmFtZT4NCj4+ICAgICAgICA8L25vZGU+DQo+PiAgICAgIDwvbm9kZXM+DQo+PiAg ICA8L2RhdGE+DQo+PiANCj4+IFBST1M6DQo+PiAgIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBj bGllbnRzIChob3cgd2UgZ290IGhlcmUpDQo+PiAgIGIpIGhhdmluZyBhbGwgZGF0YSBpbiBvbmUg bWVyZ2VkIHRyZWUgaXMgc2ltcGxlciB0byBwcm9jZXNzIA0KPj4gICAgICB0aGFuIHR3byBzZXBh cmF0ZSBxdWVyaWVzLg0KPj4gICBjKSBtb2R1bGUgZG9lc24ndCBoYXZlIHRvIGJlIHJld3JpdHRl biBmb3IgcmV2aXNlZC1kYXRhc3RvcmVzOw0KPj4gICAgICB0aGUgJ3dpdGgtc2VydmVyLXByb3Zp ZGVkJyBzd2l0Y2ggd291bGQganVzdCBub3QgYmUgcGFzc2VkDQo+PiAgICAgIGJ5IG5ldyBvcHN0 YXRlLWF3YXJlIGNsaWVudHMuDQo+PiANCj4+IENPTlM6DQo+PiAgIGEpIGluY29uc2lzdGVudCB3 aXRoIGNvbnZlbnRpb24gdXNlZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBiKSB1bmNsZWFy IGhvdyB0byBtb2RlbCAnd2l0aC1zZXJ2ZXItcHJvdmlkZWQnIGZvciBSRVNUQ09ORg0KPj4gICAg ICAoanVzdCB1c2UgYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgdG8gZGVmaW5lIGEgcXVlcnkgcGFy YW0/KQ0KPj4gICBjKSB1bmFibGUgdG8gcmV0dXJuIHRoZSBvcHN0YXRlIHZhbHVlIGZvciBhbnkg Y29uZmlndXJlZCBub2RlDQo+PiAgICAgIChpcyBpdCBuZWVkZWQgaGVyZT8pDQo+PiAgIGQpIHJl cXVpcmVzIHNlcnZlciB0byBzdXBwb3J0IG1ldGFkYXRhLCB3aGljaCBpcyBhIHJlbGF0aXZlbHkN Cj4+ICAgICAgbmV3IGNvbmNlcHQgYW5kIG1heWJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBieSBzZXJ2 ZXJzLg0KPj4gICBlKSBvbmx5IGNoYW5nZXMgcHJlc2VudGF0aW9uLWxheWVyIChkb2Vzbid0IGNo YW5nZSB0aGUgZmFjdCANCj4+ICAgICAgdGhhdCAnc2VydmVyLXByb3ZpZGVkJyBkYXRhIGlzIG5v dCBjb25maWd1cmF0aW9uKSwgdGh1cyB0aGUNCj4+ICAgICAgbGVhZnJlZiBwYXRoIGV4cHJlc3Np b25zIHN0aWxsIGRvbid0IHdvcmsgcXVpdGUgdGhlIHdheSBhcw0KPj4gICAgICBkZXNpcmVkLCB0 aG91Z2ggYSBjbGV2ZXIgc2VydmVyIGNvdWxkIGhhdmUgYSBzcGVjaWFsIGFiaWxpdHkNCj4+ICAg ICAgdG8gcGVhayBhdCB0aGUgb3BzdGF0ZSB2YWx1ZXMgd2hlbiBkb2luZyB2YWxpZGF0aW9ucy4g T2YgDQo+PiAgICAgIGNvdXJzZSwgd2l0aCByZXF1aXJlLWluc3RhbmNlIGlzIGZhbHNlLCB0aGUg dmFsdWUgb2YgbGVhZnJlZg0KPj4gICAgICBiYXNlZCB2YWxpZGF0aW9uIGNoZWNraW5nIGlzIG5l Z2F0ZWQgYW55d2F5LCBldmVuIGZvciBjb25maWcNCj4+ICAgICAgdHJ1ZSBub2Rlcywgc28gdGhp cyBtYXkgbm90IG1hdHRlciBtdWNoLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAyQjogR2VuZXJp YyB2ZXJzaW9uDQo+PiANCj4+IFRoZSBnZW5lcmljIHZlcnNpb24gaXMgbXVjaCB0aGUgc2FtZSwg YnV0IHJhdGhlciB0aGFuIGxldHRpbmcgdGhlDQo+PiBzb2x1dGlvbiBiZSBsaW1pdGVkIHRvIHRo aXMgb25lIG1vZHVsZSwgdGhlIGlkZWEgaXMgdG8gZ2VuZXJhbGl6ZQ0KPj4gaXQgc28gaXQgY291 bGQgYmUgYSBzZXJ2ZXItbGV2ZWwgZmVhdHVyZS4gIEhhdmluZyBhIGdlbmVyaWMgUlBDIHRvDQo+ PiByZXR1cm4gZGF0YSBmcm9tIG1vcmUgdGhhbiBvbmUgRFMgYXQgYSB0aW1lIHdhcyBzb21ldGhp bmcgdGhhdCB3YXMNCj4+IGRpc2N1c3NlZCB+MS41IHllYXJzIGFnbyB3aGVuIHdlIHdlcmUga2lj a2luZyBvZmYgdGhlIG9wc3RhdGUgZWZmb3J0Lg0KPj4gDQo+PiBUaGUgUFJPUyBhbmQgQ09OUyBh cmUgc2ltaWxhciwgYnV0IHRoZXJlIGFyZSBhZGRpdGlvbmFsIENPTlMgaW4gdGhlDQo+PiBnZW5l cmljIGNhc2UuICBUaGUgbWFpbiBvbmVzIGJlaW5nIDEpIGhvdyB0byBzaW11bHRhbmVvdXNseSBy ZXR1cm4gDQo+PiBib3RoIHRoZSBjb25maWcgYW5kIG9wc3RhdGUgdmFsdWVzIGZvciBhIG5vZGUg KHNwbGl0IGF0IHRoZSBsZWF2ZXMpDQo+PiBhbmQgMikgaG93IHRvIGhhbmRsZSBzb21lIFlBTkcg c3RhdGVtZW50cyBzdWNoIGFzIHByZXNlbmNlIGNvbnRhaW5lcnMNCj4+IGFuZCBjaG9pY2Ugbm9k ZXMuICBGb3IgdGhpcyByZWFzb24sICgyQikgaXMgTk9UIGNvbnNpZGVyZWQgYSB2aWFibGUNCj4+ IHNvbHV0aW9uIGFuZCBpcyBvbmx5IGhlcmUgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQgd2Fz IGRpc2N1c3NlZC4NCj4+IA0KPj4gDQo+PiANCj4+IElmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb3B0 aW9ucyBwZW9wbGUgd2FudCB0byBzdWdnZXN0LCBwbGVhc2UgZG8gc28NCj4+IG5vdyENCj4+IA0K Pj4gVGhhbmtzLA0KPj4gS2VudA0KPj4gDQoNCg0K From nobody Tue Feb 14 15:14:52 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDCC12942F for ; Tue, 14 Feb 2017 15:14:51 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 mYTPC5EwyqPW for ; Tue, 14 Feb 2017 15:14:49 -0800 (PST) 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 0B4F8129650 for ; Tue, 14 Feb 2017 15:14:48 -0800 (PST) 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=TFJoVh4BO7kAsoW6MLojm8eupVJAukALQrrzcLu0VUU=; b=fe/fFY6+3dJ9pdgpPkJS5bitCsMxa95Gll3oHHlfAERaqP05d3X7ghm36KPMvVxyZagFcxKWsOxf39lR+LWaInx5p5RxtANxFIHVu/8PjPHrdK3GTKBsxzQWObrtecfVr2Rbb3NlzBmKLoWicmvPvQpuKZ6o+dkmQnt3FZEQ2CU= 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_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 14 Feb 2017 23:14:46 +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.0919.011; Tue, 14 Feb 2017 23:14:46 +0000 From: Kent Watsen To: yang-doctors Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYCAAJwpAA== Date: Tue, 14 Feb 2017 23:14:46 +0000 Message-ID: <1DCB1F44-B9FE-424A-B642-4ADF7F882642@juniper.net> References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> In-Reply-To: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: 64d39c63-77bf-4529-1cbe-08d4552f4470 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:6emv6j6/WaZsBKJFwO6t8/7iTd4GXAscvuU3Poi1T2Nw/swFzaRwulleW0g5w8bZA8gps7gWpoCLrGXIYJS+EJZeXU9NJSSYHW7NIAnM1NupSjp9w3FNtWb8Otiy3e5wyjTPwUUNQVE5ZzJO0TDSJdWg0KOkbqFI29mL8Tyz3YjxVftLPvuUgIiy5alMRdQbuDGHb+ge/622bB3uMXnzqsxviOmjnjLcr03s1McTk1PS4i8ixdxR2mu3n9lxFZArHIkw1CRzD6mhRUtTZ0U5L2OZHvpGKaIDYzXzG3voIDd7DZuvwTE3xx95963czKXy3EC9M9BgptfZDww3aUGP4YFg/uodIxUKJobgmoWhaxiKN9bqKvZ398RBt79yREbzmtRf/OYYT+eo7oD4z3inmADPDbJLO113chfEd9c2pH96N0HyQahTFT8m1TJKN8Q/hxMvHezE5/D8pyNoiKS6UQJoESegU8Uaj8M0HYNEv5TKos7NwX5FQqhjWI3TQYv2hkUdMNY68x3cOXstxtbcLg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39410400002)(39850400002)(39840400002)(189002)(199003)(52314003)(66066001)(189998001)(106116001)(106356001)(68736007)(105586002)(230783001)(83506001)(7736002)(450100001)(101416001)(305945005)(77096006)(97736004)(82746002)(4001350100001)(6116002)(102836003)(3846002)(389900002)(6246003)(110136004)(81156014)(38730400002)(53936002)(5660300001)(8936002)(6506006)(6306002)(99286003)(6512007)(25786008)(6436002)(36756003)(6486002)(2950100002)(81166006)(6916009)(92566002)(2900100001)(3280700002)(122556002)(83716003)(229853002)(76176999)(86362001)(50986999)(8676002)(54356999)(33656002)(2906002)(3660700001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <35F103D50147CC45933FAD0F174C210C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 23:14:46.5494 (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: [yang-doctors] [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 23:14:51 -0000 RG9jdG9ycywNCg0KSSdtIHNlbmRpbmcgdGhpcyBtZXNzYWdlIGFnYWluIHRvIHRoZSBZQU5HIERv Y3RvcnMgbGlzdCBzaW5jZSBpdCB0aGUNCnByZXZpb3VzIGVtYWlsIHdhcyBoZWxkIHVwIGJ5IE1h aWxtYW4uICANCg0KQnV0IG5vdGUgdGhhdCB0aGlzIG1lc3NhZ2UgQkNDLWVkIHRoZSB5YW5nLWRv Y3RvcnMgYWxpYXMgbGFzdCB0aW1lLA0Kc28gcGxlYXNlIGZvbGxvdyB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgSTJSUyBtYWlsaW5nIGxpc3QgaWYgaW50ZXJlc3RlZC4NCg0KVGhhbmtzLA0KS2VudA0K DQoNCg0KLS0tLS0tLS1PUklHSU5BTCBNZXNzYWdlLS0tLS0tLS0tDQoNClttb3ZpbmcgeWFuZy1k b2N0b3JzIHRvIEJDQ10NCg0KDQo+PiBPUFRJT04gMTogc2VwYXJhdGUgL2ZvbyBhbmQgL2Zvby1z dGF0ZSB0cmVlcw0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+IA0KPj4gVGhpcyBvcHRpb24gd2FzL2lzIGRlc2NyaWJlZCBoZXJlOg0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pMnJzL2N1cnJlbnQvbXNnMDQzMTYuaHRt bC4NCj4+IA0KPj4gUFJPUzoNCj4+ICAgYSkgZG9lcyBOT1QgYnJlYWsgbGVnYWN5IGNsaWVudHMg KGhvdyB3ZSBnb3QgaGVyZSkNCj4+ICAgYikgY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNl ZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBjKSBhYmxlIHRvIHNob3cgaWYvaG93IG9wc3Rh dGUgbWF5IGRpZmZlciBmcm9tIGNvbmZpZ3VyZWQgdmFsdWVzDQo+PiANCj4+IENPTlM6DQo+PiAg IGEpIHF1ZXN0aW9uYWJseSB2YWxpZCBZQU5HIGxlYWZyZWYgdXNhZ2UNCj4NCj4gV2hhdCBkb2Vz IHRoaXMgbWVhbj8NCg0KSSdtIHJlZmVycmluZyB0byBob3cgdGhlIGRlc2NyaXB0aW9uIHN0YXRl bWVudCBleHBsYWlucyB0aGF0DQp0aGUgc2VydmVyIG1heSBsb29rIHRvIG9wZXJhdGlvbmFsIHN0 YXRlIGluIG9yZGVyIHRvIHJlc29sdmUNCnRoZSBsZWFmcmVmLCB3aGljaCBpcyB0byByZXN1bHQg aW4gYmVoYXZpb3Igc2ltaWxhciB0byANCnByZS1jb25maWd1cmF0aW9uIGluIFJGQyA3MjIzLg0K DQoNCg0KPj4gICBiKSBjb21wbGV4IHNlcnZlciBpbXBsZW1lbnRhdGlvbiAodG8gaGFuZGxlIHJl cXVpcmUtaW5zdGFuY2UgZmFsc2UpDQo+DQo+Q2FuIHlvdSBlbGFib3JhdGUgb24gdGhpcyBvbmU/ DQoNClRoaXMgaXMgcHJpbWFyaWx5IGEgcmVmbGVjdGlvbiBvZiB0aGUgQ09OIGxpc3RlZCBhYm92 ZSwgaW4gdGhhdA0KaXQgc2VlbXMgdGhhdCBhIHNlcnZlciB3b3VsZCBuZWVkIHRvIGhhdmUgc3Bl Y2lhbCBoYW5kbGluZyBmb3IgDQp3aGVuIGRlcGVuZGVuY2llcyB0cmFuc2l0aW9uIGZyb20gYmVp bmcgcHJlc2VudCB0byBub3QtcHJlc2VudA0KYW5kIHZpY2UgdmVyc2EsIG11Y2ggbGlrZSB0aGUg Y29kZSB0byBoYW5kbGUgd2hlbiBhIHBoeXNpY2FsDQpjYXJkIGlzIHBsdWdnZWQgaW4gb3IgcmVt b3ZlZC4NCg0KTm90ZTogSSBzaG91bGQndmUgbGlzdGVkIHRoaXMgYXMgYSBDT04gZm9yIE9QVElP TiAyIGFzIHdlbGwuDQoNCg0KDQo+PiAgIGMpIGV2ZW50dWFsbHkgdGhlIG1vZHVsZSB3b3VsZCBu ZWVkIHRvIG1pZ3JhdGUgdG8gdGhlIGxvbmctdGVybSANCj4+ICAgICAgc29sdXRpb24sIHdoaWNo IHdvdWxkIHJlc3VsdCBpbiBuZWVkaW5nIHRvIGFsc28gcmV3cml0ZSBhbGwNCj4+ICAgICAgbW9k dWxlcyB0aGF0IGhhdmUgYXVnbWVudGVkIGl0IChlLmcuLCBpZXRmLXRlLXRvcG9sb2d5KS4NCj4+ ICAgZCkgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25zIHJlYWxseSBvbmx5IHdvcmsgZm9yIGNvbmZp Z3VyYXRpb24gZGF0YSwNCj4+ICAgICAgdGhvdWdoIGEgY2xldmVyIHNlcnZlciBjb3VsZCBoYXZl IGEgc3BlY2lhbCBhYmlsaXR5IHRvIHBlYWsgYXQNCj4+ICAgICAgdGhlIG9wc3RhdGUgdmFsdWVz IHdoZW4gZG9pbmcgdmFsaWRhdGlvbnMuICBPZiBjb3Vyc2UsIHdpdGggDQo+PiAgICAgIHJlcXVp cmUtaW5zdGFuY2UgaXMgZmFsc2UsIHRoZSB2YWx1ZSBvZiBsZWFmcmVmIGJhc2VkIHZhbGlkYXRp b24NCj4+ICAgICAgY2hlY2tpbmcgaXMgbmVnYXRlZCBhbnl3YXksIGV2ZW4gZm9yIGNvbmZpZyB0 cnVlIG5vZGVzLCBzbyB0aGlzDQo+PiAgICAgIG1heSBub3QgbWF0dGVyIG11Y2guDQo+PiANCj4+ IA0KPj4gDQo+PiBPUFRJT04gMjogZXhwbGljaXQgY2xpZW50LW9wdGlvbiB0byBhbHNvIHJldHVy biB0YWdnZWQgb3BzdGF0ZSBkYXRhDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+IFRoaXMgb3B0aW9u IHRha2VzIGEgY291cGxlIGZvcm1zLiAgVGhlIGZpcnN0IGlzIG1vZHVsZS1zcGVjaWZpYyBhbmQN Cj4+IHRoZSBzZWNvbmQgaXMgZ2VuZXJpYy4gIEluIGJvdGggY2FzZXMsIHRoZSBpZGVhIGlzIG1v ZGVsZWQgYWZ0ZXIgdGhlDQo+PiB3aXRoLWRlZmF1bHRzIHNvbHV0aW9uIChSRkM2MjQzKSwgd2hl cmVpbiB0aGUgY2xpZW50IHBhc3NlcyBhIHNwZWNpYWwNCj4+IGZsYWcgaW50byA8Z2V0LWNvbmZp Zz4gY2F1c2luZyB0aGUgc2VydmVyIHRvIGFsc28gcmV0dXJuIG9wc3RhdGUgZGF0YSwNCj4+IGhh dmluZyBhIHNwZWNpYWwgbWV0YWRhdGEgZmxhZyBzZXQsIGludGVybWluZ2xlZCB3aXRoIHRoZQ0K Pj4gY29uZmlndXJhdGlvbg0KPj4gZGF0YS4NCj4+IA0KPj4gDQo+PiAyQTogTW9kdWxlLXNwZWNp ZmljIHZlcnNpb24NCj4+IA0KPj4gICAgbW9kdWxlIGZvbyB7DQo+PiAgICAgICBpbXBvcnQgaWV0 Zi1uZXRjb25mIHsgcHJlZml4IG5jOyB9DQo+PiAgICAgICBpbXBvcnQgaWV0Zi15YW5nLW1ldGFk YXRhIHsgcHJlZml4IG1kOyB9DQo+PiAgICAgICBtZDphbm5vdGF0aW9uIHNlcnZlci1wcm92aWRl ZCB7DQo+PiAgICAgICAgICB0eXBlIGJvb2xlYW47DQo+PiAgICAgICB9DQo+PiAgICAgICBjb250 YWluZXIgbm9kZXMgew0KPj4gICAgICAgICAgY29uZmlnIHRydWU7DQo+PiAgICAgICAgICBsaXN0 IG5vZGUgew0KPj4gICAgICAgICAgICAga2V5ICJuYW1lIjsNCj4+ICAgICAgICAgICAgIGxlYWYg bmFtZSB7IHR5cGUgc3RyaW5nOyB9DQo+PiAgICAgICAgICAgICBsZWFmIGRlcGVuZGVuY3kgew0K Pj4gICAgICAgICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCj4+ICAgICAgICAgICAgICAgICAgcGF0 aCAiLi4vbm9kZS9uYW1lIg0KPj4gICAgICAgICAgICAgICAgICByZXF1aXJlLWluc3RhbmNlIGZh bHNlOw0KPj4gICAgICAgICAgICAgICAgfQ0KPj4gICAgICAgICAgICAgfQ0KPj4gICAgICAgICAg fQ0KPj4gICAgICAgfQ0KPj4gICAgICAgYXVnbWVudCAvbmM6Z2V0LWNvbmZpZy9uYzppbnB1dCB7 DQo+PiAgICAgICAgICBsZWFmIHdpdGgtc2VydmVyLXByb3ZpZGVkIHsNCj4+ICAgICAgICAgICAg IHR5cGUgYm9vbGVhbjsNCj4+ICAgICAgICAgIH0NCj4+ICAgICAgIH0NCj4+ICAgIH0NCj4NCj4g SSBkb24ndCB0aGluayB0aGlzIHNvbHV0aW9uIGlzIHN1YnN0YW50aWFsbHkgZGlmZmVyZW50IGZy b20gdGhlDQo+IHNvbHV0aW9uIGluIGRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0x MC4gIFlvdSBoYXZlIGp1c3QgbW92ZWQNCj4gYSBjb25maWcgZmFsc2UgbGVhZiB0byBhIG1ldGEt ZGF0YSBhbm5vdGF0aW9uLiAgVGhpcyBzb2x1dGlvbiBzdWZmZXJzDQo+IGZyb20gdGhlIHNhbWUg cHJvYmxlbXMgYXMgdGhlIHNvbHV0aW9uIGluDQo+IGRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdv cmstdG9wby0xMC4NCg0KVGhlcmUgYXJlIHR3byBwcmltYXJ5IGRpZmZlcmVuY2VzOg0KDQoxKSBJ dCBkb2Vzbid0IGJyZWFrIGxlZ2FjeSBjbGllbnRzLCBiZWNhdXNlIGl0IHJlcXVpcmVzIHRoZSBj bGllbnQgdG8NCiAgIGV4cGxpY2l0bHkgcGFzcyBhICd3aXRoLXNlcnZlci1wcm92aWRlZCcgZmxh ZyBpbiB0aGUgPGdldC1jb25maWc+DQogICByZXF1ZXN0IGluIG9yZGVyIHRvIGdldCBiYWNrIHRo ZSBleHRlbmRlZCByZXNwb25zZS4gIExpa2V3aXNlLCBpdA0KICAgZG9lc24ndCBicmVhayBiYWNr dXAvcmVzdG9yZSB3b3JrZmxvd3MsIGFzIHRoZSBzZXJ2ZXIgY2FuIGRpc2NhcmQNCiAgIGFueSAn c2VydmVyLXByb3ZpZGVkJyBub2RlcyBwYXNzZWQgaW4gYW4gPGVkaXQtY29uZmlnPiBvcGVyYXRp b24uDQogICBMYXN0bHksIGl0IGRvZXNuJ3QgYnJlYWsgPGxvY2s+Lzx1bmxvY2s+LCBhcyB0aGVy ZSBpcyBubyBjb21pbmdsaW5nDQogICBvZiBvcHN0YXRlIGRhdGEgaW4gdGhlICdydW5uaW5nJyBk YXRhc3RvcmUuDQoNCjIpIEl0IGRvZXNuJ3Qgc2F5IGFueXRoaW5nIGFib3V0IGhvdyB0aGUgb3Bz dGF0ZSBkYXRhIGlzIHN0b3JlZCBvbiB0aGUNCiAgIHNlcnZlci4gIFRoZSBvcHN0YXRlIGRhdGEg aXMgbm90IG1vZGVsZWQgYXQgYWxsLiAgVGhpcyBhcHByb2FjaCANCiAgIG9ubHkgZGVmaW5lcyBh IHByZXNlbnRhdGlvbi1sYXllciBmb3JtYXQgZm9yIGhvdyBvcHN0YXRlIGRhdGEgY2FuDQogICBi ZSByZXR1cm5lZCB2aWEgYW4gUlBDLiAgVGhlIHNlcnZlciBpcyBmcmVlIHRvIHBlcnNpc3QgdGhl IG9wc3RhdGUNCiAgIGRhdGEgYW55d2F5IGl0IHdhbnRzLCBwZXJoYXBzIGluIGFuIGludGVybmFs IGRhdGFzdG9yZSBjYWxsZWQgDQogICAnb3BlcmF0aW9uYWwtc3RhdGUnIG9yIGluIGFuIHViZXIt ZGF0YXN0b3JlIHdpdGggdGhlIG9wc3RhdGUgZGF0YQ0KICAgZmxhZ2dlZCB3aXRoIGEgZGF0YXN0 b3JlPSdvcGVyLXN0YXRlJyBhdHRyaWJ1dGUuICBSZWdhcmRsZXNzLCBpdCdzDQogICBhbiBpbXBs ZW1lbnRhdGlvbiBkZXRhaWwsIGFuZCB0aGUgY29uY2VwdHVhbCBkYXRhc3RvcmUgbW9kZWwgaXMN CiAgIHByZXNlcnZlZC4NCg0KDQoNCj4gL21hcnRpbg0KDQpLZW50DQoNCg0KDQoNCj4+IA0KPj4g Rm9yIGluc3RhbmNlOg0KPj4gDQo+PiAgIDxnZXQtY29uZmlnPg0KPj4gICAgIDxzb3VyY2U+DQo+ PiAgICAgICA8cnVubmluZy8+DQo+PiAgICAgPC9zb3VyY2U+DQo+PiAgICAgPHdpdGgtc2VydmVy LXByb3ZpZGVkLz4NCj4+ICAgIDwvZ2V0LWNvbmZpZz4NCj4+IA0KPj4gICAgPGRhdGE+DQo+PiAg ICAgIDxub2Rlcz4NCj4+ICAgICAgICA8bm9kZT4NCj4+ICAgICAgICAgIDxuYW1lPm92ZXJsYXkt bm9kZTwvbmFtZT4NCj4+ICAgICAgICAgIDxkZXBlbmRlbmN5PnVuZGVybGF5LW5vZGU8L2RlcGVu ZGVuY3k+DQo+PiAgICAgICAgPC9ub2RlPg0KPj4gICAgICAgIDxub2RlIGZvbzpzZXJ2ZXItcHJv dmlkZWQ9J3RydWUnPg0KPj4gICAgICAgICAgPG5hbWU+dW5kZXJsYXktbm9kZTwvbmFtZT4NCj4+ ICAgICAgICA8L25vZGU+DQo+PiAgICAgIDwvbm9kZXM+DQo+PiAgICA8L2RhdGE+DQo+PiANCj4+ IFBST1M6DQo+PiAgIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBjbGllbnRzIChob3cgd2UgZ290 IGhlcmUpDQo+PiAgIGIpIGhhdmluZyBhbGwgZGF0YSBpbiBvbmUgbWVyZ2VkIHRyZWUgaXMgc2lt cGxlciB0byBwcm9jZXNzIA0KPj4gICAgICB0aGFuIHR3byBzZXBhcmF0ZSBxdWVyaWVzLg0KPj4g ICBjKSBtb2R1bGUgZG9lc24ndCBoYXZlIHRvIGJlIHJld3JpdHRlbiBmb3IgcmV2aXNlZC1kYXRh c3RvcmVzOw0KPj4gICAgICB0aGUgJ3dpdGgtc2VydmVyLXByb3ZpZGVkJyBzd2l0Y2ggd291bGQg anVzdCBub3QgYmUgcGFzc2VkDQo+PiAgICAgIGJ5IG5ldyBvcHN0YXRlLWF3YXJlIGNsaWVudHMu DQo+PiANCj4+IENPTlM6DQo+PiAgIGEpIGluY29uc2lzdGVudCB3aXRoIGNvbnZlbnRpb24gdXNl ZCBpbiBtYW55IElFVEYgbW9kdWxlcw0KPj4gICBiKSB1bmNsZWFyIGhvdyB0byBtb2RlbCAnd2l0 aC1zZXJ2ZXItcHJvdmlkZWQnIGZvciBSRVNUQ09ORg0KPj4gICAgICAoanVzdCB1c2UgYSBkZXNj cmlwdGlvbiBzdGF0ZW1lbnQgdG8gZGVmaW5lIGEgcXVlcnkgcGFyYW0/KQ0KPj4gICBjKSB1bmFi bGUgdG8gcmV0dXJuIHRoZSBvcHN0YXRlIHZhbHVlIGZvciBhbnkgY29uZmlndXJlZCBub2RlDQo+ PiAgICAgIChpcyBpdCBuZWVkZWQgaGVyZT8pDQo+PiAgIGQpIHJlcXVpcmVzIHNlcnZlciB0byBz dXBwb3J0IG1ldGFkYXRhLCB3aGljaCBpcyBhIHJlbGF0aXZlbHkNCj4+ICAgICAgbmV3IGNvbmNl cHQgYW5kIG1heWJlIG5vdCB3ZWxsIHN1cHBvcnRlZCBieSBzZXJ2ZXJzLg0KPj4gICBlKSBvbmx5 IGNoYW5nZXMgcHJlc2VudGF0aW9uLWxheWVyIChkb2Vzbid0IGNoYW5nZSB0aGUgZmFjdCANCj4+ ICAgICAgdGhhdCAnc2VydmVyLXByb3ZpZGVkJyBkYXRhIGlzIG5vdCBjb25maWd1cmF0aW9uKSwg dGh1cyB0aGUNCj4+ICAgICAgbGVhZnJlZiBwYXRoIGV4cHJlc3Npb25zIHN0aWxsIGRvbid0IHdv cmsgcXVpdGUgdGhlIHdheSBhcw0KPj4gICAgICBkZXNpcmVkLCB0aG91Z2ggYSBjbGV2ZXIgc2Vy dmVyIGNvdWxkIGhhdmUgYSBzcGVjaWFsIGFiaWxpdHkNCj4+ICAgICAgdG8gcGVhayBhdCB0aGUg b3BzdGF0ZSB2YWx1ZXMgd2hlbiBkb2luZyB2YWxpZGF0aW9ucy4gT2YgDQo+PiAgICAgIGNvdXJz ZSwgd2l0aCByZXF1aXJlLWluc3RhbmNlIGlzIGZhbHNlLCB0aGUgdmFsdWUgb2YgbGVhZnJlZg0K Pj4gICAgICBiYXNlZCB2YWxpZGF0aW9uIGNoZWNraW5nIGlzIG5lZ2F0ZWQgYW55d2F5LCBldmVu IGZvciBjb25maWcNCj4+ICAgICAgdHJ1ZSBub2Rlcywgc28gdGhpcyBtYXkgbm90IG1hdHRlciBt dWNoLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAyQjogR2VuZXJpYyB2ZXJzaW9uDQo+PiANCj4+ IFRoZSBnZW5lcmljIHZlcnNpb24gaXMgbXVjaCB0aGUgc2FtZSwgYnV0IHJhdGhlciB0aGFuIGxl dHRpbmcgdGhlDQo+PiBzb2x1dGlvbiBiZSBsaW1pdGVkIHRvIHRoaXMgb25lIG1vZHVsZSwgdGhl IGlkZWEgaXMgdG8gZ2VuZXJhbGl6ZQ0KPj4gaXQgc28gaXQgY291bGQgYmUgYSBzZXJ2ZXItbGV2 ZWwgZmVhdHVyZS4gIEhhdmluZyBhIGdlbmVyaWMgUlBDIHRvDQo+PiByZXR1cm4gZGF0YSBmcm9t IG1vcmUgdGhhbiBvbmUgRFMgYXQgYSB0aW1lIHdhcyBzb21ldGhpbmcgdGhhdCB3YXMNCj4+IGRp c2N1c3NlZCB+MS41IHllYXJzIGFnbyB3aGVuIHdlIHdlcmUga2lja2luZyBvZmYgdGhlIG9wc3Rh dGUgZWZmb3J0Lg0KPj4gDQo+PiBUaGUgUFJPUyBhbmQgQ09OUyBhcmUgc2ltaWxhciwgYnV0IHRo ZXJlIGFyZSBhZGRpdGlvbmFsIENPTlMgaW4gdGhlDQo+PiBnZW5lcmljIGNhc2UuICBUaGUgbWFp biBvbmVzIGJlaW5nIDEpIGhvdyB0byBzaW11bHRhbmVvdXNseSByZXR1cm4gDQo+PiBib3RoIHRo ZSBjb25maWcgYW5kIG9wc3RhdGUgdmFsdWVzIGZvciBhIG5vZGUgKHNwbGl0IGF0IHRoZSBsZWF2 ZXMpDQo+PiBhbmQgMikgaG93IHRvIGhhbmRsZSBzb21lIFlBTkcgc3RhdGVtZW50cyBzdWNoIGFz IHByZXNlbmNlIGNvbnRhaW5lcnMNCj4+IGFuZCBjaG9pY2Ugbm9kZXMuICBGb3IgdGhpcyByZWFz b24sICgyQikgaXMgTk9UIGNvbnNpZGVyZWQgYSB2aWFibGUNCj4+IHNvbHV0aW9uIGFuZCBpcyBv bmx5IGhlcmUgc28gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQgd2FzIGRpc2N1c3NlZC4NCj4+IA0K Pj4gDQo+PiANCj4+IElmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb3B0aW9ucyBwZW9wbGUgd2FudCB0 byBzdWdnZXN0LCBwbGVhc2UgZG8gc28NCj4+IG5vdyENCj4+IA0KPj4gVGhhbmtzLA0KPj4gS2Vu dA0KPj4gDQoNCg0KDQoNCg== From nobody Wed Feb 15 01:36:41 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27960129973 for ; Tue, 14 Feb 2017 15:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 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=-1.887, 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 TJcnZMG0bZ-X for ; Tue, 14 Feb 2017 15:01:49 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0126.outbound.protection.outlook.com [104.47.42.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 0A7B512995F for ; Tue, 14 Feb 2017 15:01:49 -0800 (PST) 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=WT0z7TehHPJAT0PpIhwRRfpK9TSTZvbqeMnNi6NFpO4=; b=N/p5U283FRKYATymStWZDW+dkrbIwQsxrMGsJU1LiODenRxjyIzpCJcAZ+XHLPhtTisxPvXnYAKW123JQh1/ve0yudUQK1aOL3efnAEdkzSv61ZJihTsSQlQYpd7igosULxM5ffY/On9jOMZbtUyJez+E3rt2BCNspX9ZTarde4= 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_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 14 Feb 2017 23:01:47 +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.0919.011; Tue, 14 Feb 2017 23:01:47 +0000 From: Kent Watsen To: Kent Watsen Thread-Topic: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo Thread-Index: AQHShm7DGX1TjHFotkqv+yitC/fU9qFoWKoA///awYCAAJiHAA== Date: Tue, 14 Feb 2017 23:01:47 +0000 Message-ID: <060F622D-D623-466E-B6EF-7D56D2B7500D@juniper.net> References: <20170214.120910.763903356597953031.mbj@tail-f.com> <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> In-Reply-To: <447B5293-75CE-4CE2-ADA4-D9E55EC7EA35@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:30a9QsIBqMGDnm4T3g19NaoHMDvpWO43hJid4aLbnbELQ6ToLzqLdq/oRNiMDkmTDXqefafxuTk6v7czN0gb1cedUtTOte3kGE/hAAbnMNHj8S3Q8yN/0WUmN7TkeIVUjeIBlP/nYZR0QXwCAmrVhYckR0Aoq+lCmO6aFalgXkkONoK0KRN9wOtGWFspTkY5T4Ywo+lZP7Ea8/oUj7PfKueqz5JrPka5BAgdgKV8aE0Rvh5W8JDKU/c27NyYvVwcBhIVQmy2BXHkVzN2z7AqhD3hc3zF2uo7GXgZET+WUHLK2r34jKgJtIUskA/PJxM68kKR0ZG1zZwWoZfGq2OyAR9INnQvD0x5ttQOXp7aZ8ab7hiGFonJhL8MdLjGMqzKny7u6Cc43teJApyHBjSioSNx2tnrIwZdqoH6c1V087jp6dBnzdQSMIH1/LuoNRP2qJKmrFLJr1Im92cJf9BKzybGQ0EhtT6XdrogZmSyXLkMYT9NBtg7GzvGP4MLsEnacfENvUpERAMoq+1tc4fiOw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39850400002)(39410400002)(39860400002)(39840400002)(199003)(189002)(52314003)(106116001)(53936002)(68736007)(1941001)(106356001)(305945005)(2950100002)(105586002)(6200100001)(50986999)(76176999)(54356999)(2906002)(8936002)(189998001)(389900001)(66066001)(4001350100001)(97736004)(7736002)(86362001)(101416001)(8676002)(38730400002)(81156014)(81166006)(110136004)(230783001)(77096006)(450100001)(3280700002)(6486002)(3660700001)(3846002)(33656002)(6506006)(83716003)(102836003)(82746002)(83506001)(6116002)(2473003)(6306002)(6512007)(2900100001)(25786008)(99286003)(122556002)(229853002)(6436002)(92566002)(5660300001)(36756003)(6862004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 13f66499-bb3f-4099-c060-08d4552d73cc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0218A015FA received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 14 Feb 2017 23:01:47.0149 (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: X-Mailman-Approved-At: Wed, 15 Feb 2017 01:36:39 -0800 Subject: [yang-doctors] FW: [i2rs] modeling options for draft-ietf-i2rs-yang-network-topo X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 23:01:52 -0000 RG9jdG9ycywNCg0KSSdtIHNlbmRpbmcgdGhpcyBtZXNzYWdlIGFnYWluIHRvIHRoZSBZQU5HIERv Y3RvcnMgbGlzdCBzaW5jZSBpdCB0aGUgDQpwcmV2aW91cyBlbWFpbCB3YXMgaGVsZCB1cCBieSBN YWlsbWFuLiAgDQoNCkJ1dCBub3RlIHRoYXQgdGhpcyBtZXNzYWdlIEJDQy1lZCB0aGUgeWFuZy1k b2N0b3JzIGFsaWFzLCBzbyBwbGVhc2UNCmZvbGxvdyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgSTJS UyBtYWlsaW5nIGxpc3QgaWYgaW50ZXJlc3RlZC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCi0tLS0t LS0tT1JJR0lOQUwgTWVzc2FnZS0tLS0tLS0tLQ0KDQpbbW92aW5nIHlhbmctZG9jdG9ycyB0byBC Q0NdDQoNCg0KPj4gT1BUSU9OIDE6IHNlcGFyYXRlIC9mb28gYW5kIC9mb28tc3RhdGUgdHJlZXMN Cj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiANCj4+ IFRoaXMgb3B0aW9uIHdhcy9pcyBkZXNjcmliZWQgaGVyZToNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvaTJycy9jdXJyZW50L21zZzA0MzE2Lmh0bWwuDQo+PiANCj4+ IFBST1M6DQo+PiAgIGEpIGRvZXMgTk9UIGJyZWFrIGxlZ2FjeSBjbGllbnRzIChob3cgd2UgZ290 IGhlcmUpDQo+PiAgIGIpIGNvbnNpc3RlbnQgd2l0aCBjb252ZW50aW9uIHVzZWQgaW4gbWFueSBJ RVRGIG1vZHVsZXMNCj4+ICAgYykgYWJsZSB0byBzaG93IGlmL2hvdyBvcHN0YXRlIG1heSBkaWZm ZXIgZnJvbSBjb25maWd1cmVkIHZhbHVlcw0KPj4gDQo+PiBDT05TOg0KPj4gICBhKSBxdWVzdGlv bmFibHkgdmFsaWQgWUFORyBsZWFmcmVmIHVzYWdlDQo+DQo+IFdoYXQgZG9lcyB0aGlzIG1lYW4/ DQoNCkknbSByZWZlcnJpbmcgdG8gaG93IHRoZSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgZXhwbGFp bnMgdGhhdA0KdGhlIHNlcnZlciBtYXkgbG9vayB0byBvcGVyYXRpb25hbCBzdGF0ZSBpbiBvcmRl ciB0byByZXNvbHZlDQp0aGUgbGVhZnJlZiwgd2hpY2ggaXMgdG8gcmVzdWx0IGluIGJlaGF2aW9y IHNpbWlsYXIgdG8gDQpwcmUtY29uZmlndXJhdGlvbiBpbiBSRkMgNzIyMy4NCg0KDQoNCj4+ICAg YikgY29tcGxleCBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gKHRvIGhhbmRsZSByZXF1aXJlLWluc3Rh bmNlIGZhbHNlKQ0KPg0KPkNhbiB5b3UgZWxhYm9yYXRlIG9uIHRoaXMgb25lPw0KDQpUaGlzIGlz IHByaW1hcmlseSBhIHJlZmxlY3Rpb24gb2YgdGhlIENPTiBsaXN0ZWQgYWJvdmUsIGluIHRoYXQN Cml0IHNlZW1zIHRoYXQgYSBzZXJ2ZXIgd291bGQgbmVlZCB0byBoYXZlIHNwZWNpYWwgaGFuZGxp bmcgZm9yIA0Kd2hlbiBkZXBlbmRlbmNpZXMgdHJhbnNpdGlvbiBmcm9tIGJlaW5nIHByZXNlbnQg dG8gbm90LXByZXNlbnQNCmFuZCB2aWNlIHZlcnNhLCBtdWNoIGxpa2UgdGhlIGNvZGUgdG8gaGFu ZGxlIHdoZW4gYSBwaHlzaWNhbA0KY2FyZCBpcyBwbHVnZ2VkIGluIG9yIHJlbW92ZWQuDQoNCk5v dGU6IEkgc2hvdWxkJ3ZlIGxpc3RlZCB0aGlzIGFzIGEgQ09OIGZvciBPUFRJT04gMiBhcyB3ZWxs Lg0KDQoNCg0KPj4gICBjKSBldmVudHVhbGx5IHRoZSBtb2R1bGUgd291bGQgbmVlZCB0byBtaWdy YXRlIHRvIHRoZSBsb25nLXRlcm0gDQo+PiAgICAgIHNvbHV0aW9uLCB3aGljaCB3b3VsZCByZXN1 bHQgaW4gbmVlZGluZyB0byBhbHNvIHJld3JpdGUgYWxsDQo+PiAgICAgIG1vZHVsZXMgdGhhdCBo YXZlIGF1Z21lbnRlZCBpdCAoZS5nLiwgaWV0Zi10ZS10b3BvbG9neSkuDQo+PiAgIGQpIGxlYWZy ZWYgcGF0aCBleHByZXNzaW9ucyByZWFsbHkgb25seSB3b3JrIGZvciBjb25maWd1cmF0aW9uIGRh dGEsDQo+PiAgICAgIHRob3VnaCBhIGNsZXZlciBzZXJ2ZXIgY291bGQgaGF2ZSBhIHNwZWNpYWwg YWJpbGl0eSB0byBwZWFrIGF0DQo+PiAgICAgIHRoZSBvcHN0YXRlIHZhbHVlcyB3aGVuIGRvaW5n IHZhbGlkYXRpb25zLiAgT2YgY291cnNlLCB3aXRoIA0KPj4gICAgICByZXF1aXJlLWluc3RhbmNl IGlzIGZhbHNlLCB0aGUgdmFsdWUgb2YgbGVhZnJlZiBiYXNlZCB2YWxpZGF0aW9uDQo+PiAgICAg IGNoZWNraW5nIGlzIG5lZ2F0ZWQgYW55d2F5LCBldmVuIGZvciBjb25maWcgdHJ1ZSBub2Rlcywg c28gdGhpcw0KPj4gICAgICBtYXkgbm90IG1hdHRlciBtdWNoLg0KPj4gDQo+PiANCj4+IA0KPj4g T1BUSU9OIDI6IGV4cGxpY2l0IGNsaWVudC1vcHRpb24gdG8gYWxzbyByZXR1cm4gdGFnZ2VkIG9w c3RhdGUgZGF0YQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+PiBUaGlzIG9wdGlvbiB0YWtlcyBhIGNv dXBsZSBmb3Jtcy4gIFRoZSBmaXJzdCBpcyBtb2R1bGUtc3BlY2lmaWMgYW5kDQo+PiB0aGUgc2Vj b25kIGlzIGdlbmVyaWMuICBJbiBib3RoIGNhc2VzLCB0aGUgaWRlYSBpcyBtb2RlbGVkIGFmdGVy IHRoZQ0KPj4gd2l0aC1kZWZhdWx0cyBzb2x1dGlvbiAoUkZDNjI0MyksIHdoZXJlaW4gdGhlIGNs aWVudCBwYXNzZXMgYSBzcGVjaWFsDQo+PiBmbGFnIGludG8gPGdldC1jb25maWc+IGNhdXNpbmcg dGhlIHNlcnZlciB0byBhbHNvIHJldHVybiBvcHN0YXRlIGRhdGEsDQo+PiBoYXZpbmcgYSBzcGVj aWFsIG1ldGFkYXRhIGZsYWcgc2V0LCBpbnRlcm1pbmdsZWQgd2l0aCB0aGUNCj4+IGNvbmZpZ3Vy YXRpb24NCj4+IGRhdGEuDQo+PiANCj4+IA0KPj4gMkE6IE1vZHVsZS1zcGVjaWZpYyB2ZXJzaW9u DQo+PiANCj4+ICAgIG1vZHVsZSBmb28gew0KPj4gICAgICAgaW1wb3J0IGlldGYtbmV0Y29uZiB7 IHByZWZpeCBuYzsgfQ0KPj4gICAgICAgaW1wb3J0IGlldGYteWFuZy1tZXRhZGF0YSB7IHByZWZp eCBtZDsgfQ0KPj4gICAgICAgbWQ6YW5ub3RhdGlvbiBzZXJ2ZXItcHJvdmlkZWQgew0KPj4gICAg ICAgICAgdHlwZSBib29sZWFuOw0KPj4gICAgICAgfQ0KPj4gICAgICAgY29udGFpbmVyIG5vZGVz IHsNCj4+ICAgICAgICAgIGNvbmZpZyB0cnVlOw0KPj4gICAgICAgICAgbGlzdCBub2RlIHsNCj4+ ICAgICAgICAgICAgIGtleSAibmFtZSI7DQo+PiAgICAgICAgICAgICBsZWFmIG5hbWUgeyB0eXBl IHN0cmluZzsgfQ0KPj4gICAgICAgICAgICAgbGVhZiBkZXBlbmRlbmN5IHsNCj4+ICAgICAgICAg ICAgICAgIHR5cGUgbGVhZnJlZiB7DQo+PiAgICAgICAgICAgICAgICAgIHBhdGggIi4uL25vZGUv bmFtZSINCj4+ICAgICAgICAgICAgICAgICAgcmVxdWlyZS1pbnN0YW5jZSBmYWxzZTsNCj4+ICAg ICAgICAgICAgICAgIH0NCj4+ICAgICAgICAgICAgIH0NCj4+ICAgICAgICAgIH0NCj4+ICAgICAg IH0NCj4+ICAgICAgIGF1Z21lbnQgL25jOmdldC1jb25maWcvbmM6aW5wdXQgew0KPj4gICAgICAg ICAgbGVhZiB3aXRoLXNlcnZlci1wcm92aWRlZCB7DQo+PiAgICAgICAgICAgICB0eXBlIGJvb2xl YW47DQo+PiAgICAgICAgICB9DQo+PiAgICAgICB9DQo+PiAgICB9DQo+DQo+IEkgZG9uJ3QgdGhp bmsgdGhpcyBzb2x1dGlvbiBpcyBzdWJzdGFudGlhbGx5IGRpZmZlcmVudCBmcm9tIHRoZQ0KPiBz b2x1dGlvbiBpbiBkcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8tMTAuICBZb3UgaGF2 ZSBqdXN0IG1vdmVkDQo+IGEgY29uZmlnIGZhbHNlIGxlYWYgdG8gYSBtZXRhLWRhdGEgYW5ub3Rh dGlvbi4gIFRoaXMgc29sdXRpb24gc3VmZmVycw0KPiBmcm9tIHRoZSBzYW1lIHByb2JsZW1zIGFz IHRoZSBzb2x1dGlvbiBpbg0KPiBkcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8tMTAu DQoNClRoZXJlIGFyZSB0d28gcHJpbWFyeSBkaWZmZXJlbmNlczoNCg0KMSkgSXQgZG9lc24ndCBi cmVhayBsZWdhY3kgY2xpZW50cywgYmVjYXVzZSBpdCByZXF1aXJlcyB0aGUgY2xpZW50IHRvDQog ICBleHBsaWNpdGx5IHBhc3MgYSAnd2l0aC1zZXJ2ZXItcHJvdmlkZWQnIGZsYWcgaW4gdGhlIDxn ZXQtY29uZmlnPg0KICAgcmVxdWVzdCBpbiBvcmRlciB0byBnZXQgYmFjayB0aGUgZXh0ZW5kZWQg cmVzcG9uc2UuICBMaWtld2lzZSwgaXQNCiAgIGRvZXNuJ3QgYnJlYWsgYmFja3VwL3Jlc3RvcmUg d29ya2Zsb3dzLCBhcyB0aGUgc2VydmVyIGNhbiBkaXNjYXJkDQogICBhbnkgJ3NlcnZlci1wcm92 aWRlZCcgbm9kZXMgcGFzc2VkIGluIGFuIDxlZGl0LWNvbmZpZz4gb3BlcmF0aW9uLg0KICAgTGFz dGx5LCBpdCBkb2Vzbid0IGJyZWFrIDxsb2NrPi88dW5sb2NrPiwgYXMgdGhlcmUgaXMgbm8gY29t aW5nbGluZw0KICAgb2Ygb3BzdGF0ZSBkYXRhIGluIHRoZSAncnVubmluZycgZGF0YXN0b3JlLg0K DQoyKSBJdCBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCBob3cgdGhlIG9wc3RhdGUgZGF0YSBp cyBzdG9yZWQgb24gdGhlDQogICBzZXJ2ZXIuICBUaGUgb3BzdGF0ZSBkYXRhIGlzIG5vdCBtb2Rl bGVkIGF0IGFsbC4gIFRoaXMgYXBwcm9hY2ggDQogICBvbmx5IGRlZmluZXMgYSBwcmVzZW50YXRp b24tbGF5ZXIgZm9ybWF0IGZvciBob3cgb3BzdGF0ZSBkYXRhIGNhbg0KICAgYmUgcmV0dXJuZWQg dmlhIGFuIFJQQy4gIFRoZSBzZXJ2ZXIgaXMgZnJlZSB0byBwZXJzaXN0IHRoZSBvcHN0YXRlDQog ICBkYXRhIGFueXdheSBpdCB3YW50cywgcGVyaGFwcyBpbiBhbiBpbnRlcm5hbCBkYXRhc3RvcmUg Y2FsbGVkIA0KICAgJ29wZXJhdGlvbmFsLXN0YXRlJyBvciBpbiBhbiB1YmVyLWRhdGFzdG9yZSB3 aXRoIHRoZSBvcHN0YXRlIGRhdGENCiAgIGZsYWdnZWQgd2l0aCBhIGRhdGFzdG9yZT0nb3Blci1z dGF0ZScgYXR0cmlidXRlLiAgUmVnYXJkbGVzcywgaXQncw0KICAgYW4gaW1wbGVtZW50YXRpb24g ZGV0YWlsLCBhbmQgdGhlIGNvbmNlcHR1YWwgZGF0YXN0b3JlIG1vZGVsIGlzDQogICBwcmVzZXJ2 ZWQuDQoNCg0KDQo+IC9tYXJ0aW4NCg0KS2VudA0KDQoNCg0KDQo+PiANCj4+IEZvciBpbnN0YW5j ZToNCj4+IA0KPj4gICA8Z2V0LWNvbmZpZz4NCj4+ICAgICA8c291cmNlPg0KPj4gICAgICAgPHJ1 bm5pbmcvPg0KPj4gICAgIDwvc291cmNlPg0KPj4gICAgIDx3aXRoLXNlcnZlci1wcm92aWRlZC8+ DQo+PiAgICA8L2dldC1jb25maWc+DQo+PiANCj4+ICAgIDxkYXRhPg0KPj4gICAgICA8bm9kZXM+ DQo+PiAgICAgICAgPG5vZGU+DQo+PiAgICAgICAgICA8bmFtZT5vdmVybGF5LW5vZGU8L25hbWU+ DQo+PiAgICAgICAgICA8ZGVwZW5kZW5jeT51bmRlcmxheS1ub2RlPC9kZXBlbmRlbmN5Pg0KPj4g ICAgICAgIDwvbm9kZT4NCj4+ICAgICAgICA8bm9kZSBmb286c2VydmVyLXByb3ZpZGVkPSd0cnVl Jz4NCj4+ICAgICAgICAgIDxuYW1lPnVuZGVybGF5LW5vZGU8L25hbWU+DQo+PiAgICAgICAgPC9u b2RlPg0KPj4gICAgICA8L25vZGVzPg0KPj4gICAgPC9kYXRhPg0KPj4gDQo+PiBQUk9TOg0KPj4g ICBhKSBkb2VzIE5PVCBicmVhayBsZWdhY3kgY2xpZW50cyAoaG93IHdlIGdvdCBoZXJlKQ0KPj4g ICBiKSBoYXZpbmcgYWxsIGRhdGEgaW4gb25lIG1lcmdlZCB0cmVlIGlzIHNpbXBsZXIgdG8gcHJv Y2VzcyANCj4+ICAgICAgdGhhbiB0d28gc2VwYXJhdGUgcXVlcmllcy4NCj4+ICAgYykgbW9kdWxl IGRvZXNuJ3QgaGF2ZSB0byBiZSByZXdyaXR0ZW4gZm9yIHJldmlzZWQtZGF0YXN0b3JlczsNCj4+ ICAgICAgdGhlICd3aXRoLXNlcnZlci1wcm92aWRlZCcgc3dpdGNoIHdvdWxkIGp1c3Qgbm90IGJl IHBhc3NlZA0KPj4gICAgICBieSBuZXcgb3BzdGF0ZS1hd2FyZSBjbGllbnRzLg0KPj4gDQo+PiBD T05TOg0KPj4gICBhKSBpbmNvbnNpc3RlbnQgd2l0aCBjb252ZW50aW9uIHVzZWQgaW4gbWFueSBJ RVRGIG1vZHVsZXMNCj4+ICAgYikgdW5jbGVhciBob3cgdG8gbW9kZWwgJ3dpdGgtc2VydmVyLXBy b3ZpZGVkJyBmb3IgUkVTVENPTkYNCj4+ICAgICAgKGp1c3QgdXNlIGEgZGVzY3JpcHRpb24gc3Rh dGVtZW50IHRvIGRlZmluZSBhIHF1ZXJ5IHBhcmFtPykNCj4+ICAgYykgdW5hYmxlIHRvIHJldHVy biB0aGUgb3BzdGF0ZSB2YWx1ZSBmb3IgYW55IGNvbmZpZ3VyZWQgbm9kZQ0KPj4gICAgICAoaXMg aXQgbmVlZGVkIGhlcmU/KQ0KPj4gICBkKSByZXF1aXJlcyBzZXJ2ZXIgdG8gc3VwcG9ydCBtZXRh ZGF0YSwgd2hpY2ggaXMgYSByZWxhdGl2ZWx5DQo+PiAgICAgIG5ldyBjb25jZXB0IGFuZCBtYXli ZSBub3Qgd2VsbCBzdXBwb3J0ZWQgYnkgc2VydmVycy4NCj4+ICAgZSkgb25seSBjaGFuZ2VzIHBy ZXNlbnRhdGlvbi1sYXllciAoZG9lc24ndCBjaGFuZ2UgdGhlIGZhY3QgDQo+PiAgICAgIHRoYXQg J3NlcnZlci1wcm92aWRlZCcgZGF0YSBpcyBub3QgY29uZmlndXJhdGlvbiksIHRodXMgdGhlDQo+ PiAgICAgIGxlYWZyZWYgcGF0aCBleHByZXNzaW9ucyBzdGlsbCBkb24ndCB3b3JrIHF1aXRlIHRo ZSB3YXkgYXMNCj4+ICAgICAgZGVzaXJlZCwgdGhvdWdoIGEgY2xldmVyIHNlcnZlciBjb3VsZCBo YXZlIGEgc3BlY2lhbCBhYmlsaXR5DQo+PiAgICAgIHRvIHBlYWsgYXQgdGhlIG9wc3RhdGUgdmFs dWVzIHdoZW4gZG9pbmcgdmFsaWRhdGlvbnMuIE9mIA0KPj4gICAgICBjb3Vyc2UsIHdpdGggcmVx dWlyZS1pbnN0YW5jZSBpcyBmYWxzZSwgdGhlIHZhbHVlIG9mIGxlYWZyZWYNCj4+ICAgICAgYmFz ZWQgdmFsaWRhdGlvbiBjaGVja2luZyBpcyBuZWdhdGVkIGFueXdheSwgZXZlbiBmb3IgY29uZmln DQo+PiAgICAgIHRydWUgbm9kZXMsIHNvIHRoaXMgbWF5IG5vdCBtYXR0ZXIgbXVjaC4NCj4+IA0K Pj4gDQo+PiANCj4+IA0KPj4gMkI6IEdlbmVyaWMgdmVyc2lvbg0KPj4gDQo+PiBUaGUgZ2VuZXJp YyB2ZXJzaW9uIGlzIG11Y2ggdGhlIHNhbWUsIGJ1dCByYXRoZXIgdGhhbiBsZXR0aW5nIHRoZQ0K Pj4gc29sdXRpb24gYmUgbGltaXRlZCB0byB0aGlzIG9uZSBtb2R1bGUsIHRoZSBpZGVhIGlzIHRv IGdlbmVyYWxpemUNCj4+IGl0IHNvIGl0IGNvdWxkIGJlIGEgc2VydmVyLWxldmVsIGZlYXR1cmUu ICBIYXZpbmcgYSBnZW5lcmljIFJQQyB0bw0KPj4gcmV0dXJuIGRhdGEgZnJvbSBtb3JlIHRoYW4g b25lIERTIGF0IGEgdGltZSB3YXMgc29tZXRoaW5nIHRoYXQgd2FzDQo+PiBkaXNjdXNzZWQgfjEu NSB5ZWFycyBhZ28gd2hlbiB3ZSB3ZXJlIGtpY2tpbmcgb2ZmIHRoZSBvcHN0YXRlIGVmZm9ydC4N Cj4+IA0KPj4gVGhlIFBST1MgYW5kIENPTlMgYXJlIHNpbWlsYXIsIGJ1dCB0aGVyZSBhcmUgYWRk aXRpb25hbCBDT05TIGluIHRoZQ0KPj4gZ2VuZXJpYyBjYXNlLiAgVGhlIG1haW4gb25lcyBiZWlu ZyAxKSBob3cgdG8gc2ltdWx0YW5lb3VzbHkgcmV0dXJuIA0KPj4gYm90aCB0aGUgY29uZmlnIGFu ZCBvcHN0YXRlIHZhbHVlcyBmb3IgYSBub2RlIChzcGxpdCBhdCB0aGUgbGVhdmVzKQ0KPj4gYW5k IDIpIGhvdyB0byBoYW5kbGUgc29tZSBZQU5HIHN0YXRlbWVudHMgc3VjaCBhcyBwcmVzZW5jZSBj b250YWluZXJzDQo+PiBhbmQgY2hvaWNlIG5vZGVzLiAgRm9yIHRoaXMgcmVhc29uLCAoMkIpIGlz IE5PVCBjb25zaWRlcmVkIGEgdmlhYmxlDQo+PiBzb2x1dGlvbiBhbmQgaXMgb25seSBoZXJlIHNv IHRoYXQgaXQncyBjbGVhciB0aGF0IGl0IHdhcyBkaXNjdXNzZWQuDQo+PiANCj4+IA0KPj4gDQo+ PiBJZiB0aGVyZSBhcmUgYW55IG90aGVyIG9wdGlvbnMgcGVvcGxlIHdhbnQgdG8gc3VnZ2VzdCwg cGxlYXNlIGRvIHNvDQo+PiBub3chDQo+PiANCj4+IFRoYW5rcywNCj4+IEtlbnQNCj4+IA0KDQoN Cg0KDQo= From nobody Wed Feb 15 01:36:44 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00251294CD for ; Wed, 15 Feb 2017 01:22:23 -0800 (PST) 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 6nNjklYsNdRA for ; Wed, 15 Feb 2017 01:22:21 -0800 (PST) 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 F14AC128AC9 for ; Wed, 15 Feb 2017 01:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34382; q=dns/txt; s=iport; t=1487150541; x=1488360141; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=oCuUWa8+BJJwOCEKWJhDiV/VqeEBpIWFwiDcZCBE4AA=; b=LZsyoquZaOzj+xNyq5UHykFGaOkIaAuBoSxgR/yNPtx1Snkigolaji7c Zfh35BGgvKUJfPcuhQjrzbeUEoPwSGKBMde1NXc8GJdDx27mJxm8IZpbg dYtSmq3NHQF4w1qFm5MytMNY4d0jFVoTSRKF5qzWvd/50sSAiHnZSWLKw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgAQAQHaRY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BRAOBBo1hcpEeiAyLG4IPggwqhXgCgkcYAQIBAQEBAQEBYii?= =?us-ascii?q?EcAEBAQQnBkwQCxABBAEBASABBgchJQkIBgEMBgIBAYlPAxUOsUM6K4cXDYQXA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYZNggWCaoJRgUpvhRAfAQSJBogEhEuFZjq?= =?us-ascii?q?Gb4cMhBmKP4ZHijZbg2uEGh84gQAgFAgVFYUCHYFiPzUBh0wrgg8BAQE?= X-IronPort-AV: E=Sophos;i="5.35,165,1484006400"; d="scan'208,217";a="692216763" 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; 15 Feb 2017 09:22:18 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1F9MHnu009034; Wed, 15 Feb 2017 09:22:17 GMT To: "Holness, Marc" , Juergen Schoenwaelder , Janos Farkas References: <7d4dc69f-ed12-26e7-8d9d-0753615f45f7@ericsson.com> <20170214102048.GA12861@elstar.local> <3cfbc431-cb44-ceaa-9a1b-e25cb930daef@cisco.com> From: Benoit Claise Message-ID: <14fe6515-a749-83cd-e5ff-4950e2f88448@cisco.com> Date: Wed, 15 Feb 2017 10:22:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1CCECBD465CEA041416875DF" Archived-At: X-Mailman-Approved-At: Wed, 15 Feb 2017 01:36:39 -0800 Cc: John Messenger , YANG Doctors , Dan Romascanu Subject: Re: [yang-doctors] IEEE YANG module validation and YANG doctor review X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 09:22:24 -0000 This is a multi-part message in MIME format. --------------1CCECBD465CEA041416875DF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Mark, [copying the YANG doctors as it might be of general interest] I basically investigated the first YANG module at http://www.claise.be/IEEEStandardYANGPageCompilation.html From the page first line, you can see where those YANG modules come from: https://github.com/YangModels/yang/tree/master/standard/ieee Note that I also compile http://www.claise.be/IEEEExperimentalYANGPageCompilation.html All info at http://www.claise.be/2016/07/ietf-yang-modules-statistiques/ IEEE (updated daily) * All_YANG data modules for PAR-related projects_ , with compilation errors * All _YANG data modules for non PAR-related projects_ , with compilation errors And at http://www.claise.be/YANGPageMain.html * IEEEStandard YANG MODELS * Number of YANG data models from IEEEStandard that passed compilation: 2/8 * Number of YANG data models from IEEEStandard that passed compilation with warnings: 0/8 * Number of YANG data models from IEEEStandard that failed compilation: 6/8 * Generated on 15/02/2017 by Benoit Claise * IEEEExperimental YANG MODELS * Number of YANG data models from IEEEExperimental that passed compilation: 1/5 * Number of YANG data models from IEEEExperimental that passed compilation with warnings: 0/5 * Number of YANG data models from IEEEExperimental that failed compilation: 4/5 * Generated on 15/02/2017 by Benoit Claise regarding the specific modules mentioned below: ieee802-types.yang => PASSED ieee802-dot1q-types.yang => PASSED ieee802-dot1q-bridge.yang => FAILED ieee802-dot1q-tpmr.yang => FAILED ieee802-dot1q-vlan-bridge.yang => FAILED ieee802-dot1q-pb.yang => FAILED Ieee802-dot1x.yang => FAILED I understand that you ask the YANG doctors to review the following YANG modules These ones are part of the P802.1Qcp project: +--> standard | +--> 802.1 | | +--> draft | | +--> ieee-dot1q-bridge.yang | | +--> ieee-dot1q-pb.yang | | +--> ieee-dot1q-tpmr.yang | | +--> ieee-dot1q-types.yang | | +--> ieee-dot1q-vlan-bridge.yang This is the P802.1Xck project: +--> standard | +--> 802.1 | | +--> draft | | +--> ieee-dot1x.yang It makes sense to resolve the validation errors before Jrgen starts his YANG doctor review. The best way is to post the new YANG modules in github. From there, I'll run my scripts. Regards, Benoit > Hi Benoit and all, > Thanks for this. I would like to provide a bit of clarity on the YANG > modules that are a part of the current IEEE 802.1 YANG active projects > (i.e., 802.1Qcp and 802.1Xck). > _General IEEE 802 Types_ > *i**eee802-types.yang* - Generic IEEE 802 type definitions > _IEEE 802.1 Types_ > *i**eee802-dot1q-types.yang* - IEEE 802.1 type specific definitions > _IEEE 802.1Qcp____(Bridges and Bridged Networks Amendment: YANG Data > Model)_ > *i**eee802-dot1q-bridge.yang* - Main IEEE 802.1Q bridging YANG modules > which is augmented by specific bridge models. The general structure is > shown below. > > *i**eee802-dot1q-tpmr.yang* - Two Port MAC Relay Bridge YANG module > *i**eee802-dot1q-vlan-bridge.yang* - Customer VLAN Bridge YANG module > *i**eee802-dot1q-pb.yang* - Provider Bridge YANG module > _IEEE __802.1Xck __(Port-Based Network Access Control __- __Amendment > 2: YANG Data Model)_ > *Ieee802-dot1x.yang* - IEEE 802.1X (Port-based network access control) > YANG module > The *ieee80**2-dot1ax.yang* module is _not_ currently in scope. That > being said however, yes, I do need to make the changes to this module > over time. It is still very draft, and not ready for prime time yet. > Regards, > Marc. > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Tuesday, February 14, 2017 6:43 AM > *To:* Juergen Schoenwaelder ; > Janos Farkas > *Cc:* Dan Romascanu ; Mehmet ; > Holness, Marc ; Martin Bjorklund ; > Andy Bierman ; rkrejci@cesnet.cz; Benoit Claise > ; John Messenger > *Subject:* IEEE YANG module validation and YANG doctor review (was: > Re: [802.1 - 12074] Working Group ballot of P802.1Qcp/D1.0 - Bridges > and Bridged Networks Amendment: YANG Data Model > Dear all, > > _http://www.claise.be/IEEEStandardYANGPageCompilation.html_ is now fixed. > > I looked at the first YANG module: ieee802-dot1ax.yang, which fails > validation for 3 validators out of 4. Pyang is the exception, but > pyang doesn't have a xpath validation for now. > > For example, in yangdump-pro, it shows: > *** Generated by yangdump-pro 16.10-4 > *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. > *** Copyright (c) 2012-2017, YumaWorks, Inc., All Rights Reserved. > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:87.11: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:87.47: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:87.84: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:187.11: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:187.47: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:187.84: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:529.11: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:529.48: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:757.11: warning(1032): no child node available > > Warning: no child node 'ietf-interfaces:type' found for parent > 'yuma-ncx:root' > XPath: /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge' > ieee802-dot1ax.yang:757.48: warning(1032): no child node available > > Warning: Module 'iana-if-type' not used > ieee802-dot1ax.yang:9.3: warning(1015): import not used > > *** > *** 0 Errors, 11 Warnings > The issue is (mutltiple times the same issue btw). > OLD: > augment "/if:interfaces/if:interface" { > when "/if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge'" { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } > > NEW: > augment "/if:interfaces/if:interface" { > when "/if:interfaces/if:interface/if:type = 'ianaif:ieee8023adLag' or > /if:interfaces/if:interface/if:type = 'ianaif:ethernetCsmacd' or > /if:interfaces/if:interface/if:type = 'ianaif:bridge'" { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } > > I'll surely stand corrected by the YANG doctors if this is not the issue. > > Attached is a working copy of the YANG model, which passes yangdumpro > and confdc. > There is a warning with yanglint (Radek is copied). > > yanglint -V -p /home/bclaise/yang/modules/ ieee802-dot1ax.yang > warn: Schema node "ietf-interfaces:interfaces-state" not found > (/ietf-interfaces:interfaces-state). > warn: Resolving when condition > "/ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces:type > = 'iana-if-type:ethernetCsmacd' or > /ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces:type > = 'iana-if-type:bridge'" failed. > (/ieee802-dot1ax:/ietf-interfaces:interfaces/ietf-interfaces:interface) > > As Jrgenmentioned, I propose that IEEE fixes the errors/warnings seen > at _http://www.claise.be/IEEEStandardYANGPageCompilation.html_ before > we proceed with the YANG doctor review. > A very quick look through the rest of the errors tends to show the > same error type. > > Regards, Benoit > On 2/14/2017 11:29 AM, Benoit Claise wrote: > On 2/14/2017 11:20 AM, Juergen Schoenwaelder wrote: > On Tue, Feb 14, 2017 at 09:54:31AM +0000, Janos Farkas wrote: > ps: > This is the P802.1Xck project: > +--> standard > | +--> 802.1 > | | +--> draft > | | +--> ieee-dot1x.yang > > > The P802.1Xck WG ballot closes tomorrow. > So what does that ballot closing event tell me? Where exactly do I > find the YANG modules that have been used in the .pdf file? By when do > you need a review? Did Benoit run his tools on the correct documents > or not? > Janos, > > _http://www.claise.be/IEEEStandardYANGPageCompilation.html_ > Note that I made some changes this morning and screwed up a few things. > That leads to some compilation issues. > Let me solve this first. > > Regards, B. > > Regards, Benoit > If so, perhaps it makes sense to fix the compilation issues > before I do my review, no? > > /js > > . --------------1CCECBD465CEA041416875DF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Mark,

[copying the YANG doctors as it might be of general interest]

I basically investigated the first YANG module at http://www.claise.be/IEEEStandardYANGPageCompilation.html
From the page first line, you can see where those YANG modules come from: https://github.com/YangModels/yang/tree/master/standard/ieee
Note that I also compile http://www.claise.be/IEEEExperimentalYANGPageCompilation.html

All info at http://www.claise.be/2016/07/ietf-yang-modules-statistiques/
IEEE (updated daily)

And at http://www.claise.be/YANGPageMain.html

  • IEEEStandard YANG MODELS
  • Number of YANG data models from IEEEStandard that passed compilation: 2/8
  • Number of YANG data models from IEEEStandard that passed compilation with warnings: 0/8
  • Number of YANG data models from IEEEStandard that failed compilation: 6/8
  • Generated on 15/02/2017 by Benoit Claise
  • IEEEExperimental YANG MODELS
  • Number of YANG data models from IEEEExperimental that passed compilation: 1/5
  • Number of YANG data models from IEEEExperimental that passed compilation with warnings: 0/5
  • Number of YANG data models from IEEEExperimental that failed compilation: 4/5
  • Generated on 15/02/2017 by Benoit Claise

regarding the specific modules mentioned below:
ieee802-types.yang => PASSED
ieee802-dot1q-types.yang => PASSED
ieee802-dot1q-bridge.yang => FAILED
ieee802-dot1q-tpmr.yang => FAILED
ieee802-dot1q-vlan-bridge.yang => FAILED
ieee802-dot1q-pb.yang => FAILED
Ieee802-dot1x.yang => FAILED


I understand that you ask the YANG doctors to review the following YANG modules
These ones are part of the P802.1Qcp project:

+--> standard

| +--> 802.1

| | +--> draft

| | +--> ieee-dot1q-bridge.yang

| | +--> ieee-dot1q-pb.yang

| | +--> ieee-dot1q-tpmr.yang

| | +--> ieee-dot1q-types.yang

| | +--> ieee-dot1q-vlan-bridge.yang


This is the P802.1Xck project:

+--> standard

| +--> 802.1

| | +--> draft

| | +--> ieee-dot1x.yang


It makes sense to resolve the validation errors before Jrgen starts his YANG doctor review.
The best way is to post the new YANG modules in github. From there, I'll run my scripts.

Regards, Benoit
Hi Benoit and all,
Thanks for this. I would like to provide a bit of clarity on the YANG modules that are a part of the current IEEE 802.1 YANG active projects (i.e., 802.1Qcp and 802.1Xck).
General IEEE 802 Types
ieee802-types.yang - Generic IEEE 802 type definitions
IEEE 802.1 Types
ieee802-dot1q-types.yang - IEEE 802.1 type specific definitions
IEEE 802.1Qcp (Bridges and Bridged Networks Amendment: YANG Data Model)
ieee802-dot1q-bridge.yang - Main IEEE 802.1Q bridging YANG modules which is augmented by specific bridge models. The general structure is shown below.

ieee802-dot1q-tpmr.yang - Two Port MAC Relay Bridge YANG module
ieee802-dot1q-vlan-bridge.yang - Customer VLAN Bridge YANG module
ieee802-dot1q-pb.yang - Provider Bridge YANG module
IEEE 802.1Xck (Port-Based Network Access Control - Amendment 2: YANG Data Model)
Ieee802-dot1x.yang - IEEE 802.1X (Port-based network access control) YANG module
The ieee802-dot1ax.yang module is not currently in scope. That being said however, yes, I do need to make the changes to this module over time. It is still very draft, and not ready for prime time yet.
Regards,
Marc.
From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, February 14, 2017 6:43 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Janos Farkas <Janos.Farkas@ericsson.com>
Cc: Dan Romascanu <dromasca@gmail.com>; Mehmet <mersue@gmail.com>; Holness, Marc <mholness@ciena.com>; Martin Bjorklund <mbj@tail-f.com>; Andy Bierman <andy@yumaworks.com>; rkrejci@cesnet.cz; Benoit Claise <bclaise@cisco.com>; John Messenger <jmessenger@advaoptical.com>
Subject: IEEE YANG module validation and YANG doctor review (was: Re: [802.1 - 12074] Working Group ballot of P802.1Qcp/D1.0 - Bridges and Bridged Networks Amendment: YANG Data Model
Dear all,

http://www.claise.be/IEEEStandardYANGPageCompilation.html is now fixed.

I looked at the first YANG module: ieee802-dot1ax.yang, which fails validation for 3 validators out of 4. Pyang is the exception, but pyang doesn't have a xpath validation for now.

For example, in yangdump-pro, it shows:
*** Generated by yangdump-pro 16.10-4
*** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved.
*** Copyright (c) 2012-2017, YumaWorks, Inc., All Rights Reserved.

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:87.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:87.47: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:87.84: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:187.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:187.47: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:187.84: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:529.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:529.48: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:757.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:root'
XPath: /if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'
ieee802-dot1ax.yang:757.48: warning(1032): no child node available

Warning: Module 'iana-if-type' not used
ieee802-dot1ax.yang:9.3: warning(1015): import not used

***
*** 0 Errors, 11 Warnings
The issue is (mutltiple times the same issue btw).
OLD:
augment "/if:interfaces/if:interface" {
when "/if:type = 'ianaif:ieee8023adLag' or
/if:type = 'ianaif:ethernetCsmacd' or
/if:type = 'ianaif:bridge'" {
description
"Applies to Ethernet interfaces or Bridge Ports.";
}

NEW:
augment "/if:interfaces/if:interface" {
when "/if:interfaces/if:interface/if:type = 'ianaif:ieee8023adLag' or
/if:interfaces/if:interface/if:type = 'ianaif:ethernetCsmacd' or
/if:interfaces/if:interface/if:type = 'ianaif:bridge'" {
description
"Applies to Ethernet interfaces or Bridge Ports.";
}

I'll surely stand corrected by the YANG doctors if this is not the issue.

Attached is a working copy of the YANG model, which passes yangdumpro and confdc.
There is a warning with yanglint (Radek is copied).

yanglint -V -p /home/bclaise/yang/modules/ ieee802-dot1ax.yang
warn: Schema node "ietf-interfaces:interfaces-state" not found (/ietf-interfaces:interfaces-state).
warn: Resolving when condition "/ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces:type = 'iana-if-type:ethernetCsmacd' or
/ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces:type = 'iana-if-type:bridge'" failed. (/ieee802-dot1ax:/ietf-interfaces:interfaces/ietf-interfaces:interface)

As Jrgenmentioned, I propose that IEEE fixes the errors/warnings seen at http://www.claise.be/IEEEStandardYANGPageCompilation.html before we proceed with the YANG doctor review.
A very quick look through the rest of the errors tends to show the same error type.

Regards, Benoit
On 2/14/2017 11:29 AM, Benoit Claise wrote:
On 2/14/2017 11:20 AM, Juergen Schoenwaelder wrote:
On Tue, Feb 14, 2017 at 09:54:31AM +0000, Janos Farkas wrote:
ps:
This is the P802.1Xck project:
+--> standard
| +--> 802.1
| | +--> draft
| | +--> ieee-dot1x.yang


The P802.1Xck WG ballot closes tomorrow.
So what does that ballot closing event tell me? Where exactly do I
find the YANG modules that have been used in the .pdf file? By when do
you need a review? Did Benoit run his tools on the correct documents
or not?
Note that I made some changes this morning and screwed up a few things.
That leads to some compilation issues.
Let me solve this first.

Regards, B.

Regards, Benoit
If so, perhaps it makes sense to fix the compilation issues
before I do my review, no?

/js

.

--------------1CCECBD465CEA041416875DF-- From nobody Wed Feb 15 09:11:22 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91A1296AA for ; Wed, 15 Feb 2017 09:11:20 -0800 (PST) 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 P3Inmfud8ab4 for ; Wed, 15 Feb 2017 09:11:17 -0800 (PST) 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 5C21912966D for ; Wed, 15 Feb 2017 09:11:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 034BC6CF; Wed, 15 Feb 2017 18:11:16 +0100 (CET) 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 R--TVVxUMOKy; Wed, 15 Feb 2017 18:11:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 15 Feb 2017 18:11:15 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 990EB200C5; Wed, 15 Feb 2017 18:11:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id AlVRm5cJSXuZ; Wed, 15 Feb 2017 18:11:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4C64200C3; Wed, 15 Feb 2017 18:11:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9E04C3E7807B; Wed, 15 Feb 2017 18:11:17 +0100 (CET) Date: Wed, 15 Feb 2017 18:11:17 +0100 From: Juergen Schoenwaelder To: "Holness, Marc" Message-ID: <20170215171117.GA16829@elstar.local> Mail-Followup-To: "Holness, Marc" , Benoit Claise , Janos Farkas , Dan Romascanu , Mehmet , Martin Bjorklund , Andy Bierman , "rkrejci@cesnet.cz" , John Messenger , YANG Doctors References: <20170214102048.GA12861@elstar.local> <3cfbc431-cb44-ceaa-9a1b-e25cb930daef@cisco.com> <14fe6515-a749-83cd-e5ff-4950e2f88448@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: Cc: John Messenger , Janos Farkas , YANG Doctors , Dan Romascanu Subject: Re: [yang-doctors] IEEE YANG module validation and YANG doctor review X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:11:20 -0000 On Wed, Feb 15, 2017 at 04:33:36PM +0000, Holness, Marc wrote: > > Thanks Benoit. > > It seems all the warnings are the same. Based upon the guidance provided in the thread below, it seems I should change all occurrences of the form ... > > augment "/if:interfaces/if:interface" { > when "/if:type = 'ianaif:ieee8023adLag' or > /if:type = 'ianaif:ethernetCsmacd' or > /if:type = 'ianaif:bridge'" { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } > > ... to something like what is shown below. > > augment "/if:interfaces/if:interface" { > when "/if:interfaces/if:interface/if:type = 'ianaif:ieee8023adLag' or > /if:interfaces/if:interface/if:type = 'ianaif:ethernetCsmacd' or > /if:interfaces/if:interface/if:type = 'ianaif:bridge'" { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } > > Is this correct? No, this is not correct. See Martin's answer. The correct fix is to replace /if:type with if:type in the when expression: augment "/if:interfaces/if:interface" { when "if:type = 'ianaif:ieee8023adLag' or if:type = 'ianaif:ethernetCsmacd' or if:type = 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } > BTW ... The examples shown in RFC6020, section 7.15.3 "Usage Example" and RFC 7950, section 7.17.3 "Usage Example" seems to be misleading. Am I misinterpreting things? > > import interface-module { > prefix "if"; > } > > augment "/if:interfaces/if:ifEntry" { > when "if:ifType='ds0'"; > leaf ds0ChannelNumber { > type ChannelNumber; > } > } > These examples are fine. The problem is that you were not following them closely enough. ;-) /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 Feb 15 09:16:08 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7790012966D for ; Wed, 15 Feb 2017 09:16:06 -0800 (PST) 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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 aK0WXZwSML_t for ; Wed, 15 Feb 2017 09:16:04 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0089.outbound.protection.outlook.com [104.47.42.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FDD129653 for ; Wed, 15 Feb 2017 09:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QQLswuPdsQPgLpJ6PrdyGi5/jrguCbwzgsqikDXrVzo=; b=f4sS9O79x7lwBSjfZL52XD0LcB4dtBjVg6Q0iEc2JrBoCFjvQbv0iq0WBgsMwh48RJZng5AkaJIrTPuTP13ZOhYK+y0U6yvf9nT/frM3SFOjaBP/NkJp+SacwRAKrp98A5tR29SmrviUV8UN8LKWwVnt/kpuaGeiKVCXht+SMpQ= Received: from CO2PR04MB746.namprd04.prod.outlook.com (10.141.228.144) by CO2PR04MB746.namprd04.prod.outlook.com (10.141.228.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 17:15:58 +0000 Received: from CO2PR04MB746.namprd04.prod.outlook.com ([10.141.228.144]) by CO2PR04MB746.namprd04.prod.outlook.com ([10.141.228.144]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 17:15:58 +0000 From: "Holness, Marc" To: Juergen Schoenwaelder Thread-Topic: IEEE YANG module validation and YANG doctor review Thread-Index: AQHSh20dAJgG5ohDdkCfRRRN9j0/YaFqQSgwgAANB4CAAADW0A== Date: Wed, 15 Feb 2017 17:15:57 +0000 Message-ID: References: <20170214102048.GA12861@elstar.local> <3cfbc431-cb44-ceaa-9a1b-e25cb930daef@cisco.com> <14fe6515-a749-83cd-e5ff-4950e2f88448@cisco.com> <20170215171117.GA16829@elstar.local> In-Reply-To: <20170215171117.GA16829@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mholness@ciena.com; x-originating-ip: [205.150.10.69] x-ms-office365-filtering-correlation-id: e803b4c0-0095-42a5-f6d3-08d455c64ece x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR04MB746; x-microsoft-exchange-diagnostics: 1; CO2PR04MB746; 7:shn6reaVf7lV/XlL6iXqgtEqfTauTZib2U+FwxtARrYBXP2sjHWUqgkXrOFDOSRsAUw+YHKGSx3H5p140kixhnsVtsUzMwlt0HFf6OwZCldnTEEUULHk6XtSmbRMGcSz03oBL/RdLvchJk94tytmBuF7M7ZUfE5IWeghu87B0DukU4kK4dWOipuxogc74cIgfQisPSCoE3R75SQMvJCdGTb3DMcl1BO45tKvqr7A1GViiwIKbD+0/HOQAerZzsUeHlqTP/DSm5fh7dPBOE+8tf+6hvQhlYmFQ+om7rHXywtXwHHSi202Nq7OsfpvpzoMNIPecWFJfvf1bHB2Lua6kxaJ6NEfJ9JyzBamnE8YWAqCanuHP8/GPslUED5/2yxlajiT8A65MCaosY5F9nCYWEjWy935iRD+iGg8MD73GwBOs3YSIHDaO67EUvZcGBVejN1TWofb16VdD2t1kQ5JeNqqJX8PzYXYfyQ8DJ24spJkx1hxuxXKQtuURlv9LHtI7lU2xOa05fLq0VxU0MQ8Qg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(788757137089)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CO2PR04MB746; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB746; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(13464003)(24454002)(377454003)(199003)(92566002)(81166006)(122556002)(8936002)(2906002)(2900100001)(4326007)(575784001)(81156014)(8676002)(6916009)(5660300001)(2950100002)(39060400002)(3280700002)(7416002)(55016002)(7696004)(68736007)(53936002)(305945005)(7736002)(66066001)(33656002)(77096006)(74316002)(110136004)(3660700001)(6246003)(38730400002)(50986999)(54356999)(6116002)(229853002)(102836003)(76176999)(3846002)(97736004)(86362001)(105586002)(6506006)(106116001)(93886004)(25786008)(9686003)(54906002)(106356001)(189998001)(101416001)(99286003)(6436002)(6306002)(389900002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR04MB746; H:CO2PR04MB746.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 17:15:57.8748 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB746 Archived-At: Cc: John Messenger , Janos Farkas , YANG Doctors , Dan Romascanu Subject: Re: [yang-doctors] IEEE YANG module validation and YANG doctor review X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:16:06 -0000 Ahhh ... I see. Sorry about that.=20 Thanks! I'm making the changes now. Marc. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, February 15, 2017 12:11 PM To: Holness, Marc Cc: Benoit Claise ; Janos Farkas ; Dan Romascanu ; Mehmet ; Martin= Bjorklund ; Andy Bierman ; rkrejci@ces= net.cz; John Messenger ; YANG Doctors Subject: Re: IEEE YANG module validation and YANG doctor review On Wed, Feb 15, 2017 at 04:33:36PM +0000, Holness, Marc wrote: >=20 > Thanks Benoit. >=20 > It seems all the warnings are the same. Based upon the guidance provided = in the thread below, it seems I should change all occurrences of the form .= .. >=20 > augment "/if:interfaces/if:interface" { > when "/if:type =3D 'ianaif:ieee8023adLag' or > /if:type =3D 'ianaif:ethernetCsmacd' or > /if:type =3D 'ianaif:bridge'" { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } >=20 > ... to something like what is shown below. >=20 > augment "/if:interfaces/if:interface" { > when "/if:interfaces/if:interface/if:type =3D 'ianaif:ieee8023adLag' = or > /if:interfaces/if:interface/if:type =3D 'ianaif:ethernetC= smacd' or > /if:interfaces/if:interface/if:type =3D 'ianaif:bridge'" = { > description > "Applies to Ethernet interfaces or Bridge Ports."; > } >=20 > Is this correct? No, this is not correct. See Martin's answer. The correct fix is to replace= /if:type with if:type in the when expression: =20 augment "/if:interfaces/if:interface" { when "if:type =3D 'ianaif:ieee8023adLag' or if:type =3D 'ianaif:ethernetCsmacd' or if:type =3D 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } > BTW ... The examples shown in RFC6020, section 7.15.3 "Usage Example" and= RFC 7950, section 7.17.3 "Usage Example" seems to be misleading. Am I misi= nterpreting things? >=20 > import interface-module { > prefix "if"; > } >=20 > augment "/if:interfaces/if:ifEntry" { > when "if:ifType=3D'ds0'"; > leaf ds0ChannelNumber { > type ChannelNumber; > } > } >=20 These examples are fine. The problem is that you were not following them cl= osely enough. ;-) /js --=20 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 Feb 15 09:45:15 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873971295F0; Wed, 15 Feb 2017 09:45:14 -0800 (PST) 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 rdO24ccGMQYZ; Wed, 15 Feb 2017 09:45:13 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD0A129545; Wed, 15 Feb 2017 09:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4127; q=dns/txt; s=iport; t=1487180713; x=1488390313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=98rHeKchDPpaeTeyPNmre7z36ksFSDv1j/YktZcw2wg=; b=fEw3d1dK63J7PDu6Td4sCTPyHUHaDGAmLKIBVSojkaxF+QG2IW8vmZGw E/9Oj20KlBXVPdbfvljXTsDtEeV8B3vluYNOyMjPat1Eo9Y/Cz4jYTUOA P29qWUTkSH59JfypmmLoG4xk0bSKG6wek8oSclCjqFUa/Ljb4CA1yPNiZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAQCUkqRY/5BdJa1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1KBageNWpIQkyeCD4IMhiICghQ/GAECAQEBAQEBAWIohHEBBAF5EAI?= =?us-ascii?q?BCEYyJQIEAQ0FiWMIskuLOAEBAQEBAQEBAQEBAQEBAQEBAQEfizyKGh8BBJAEh?= =?us-ascii?q?VGGIgGSE5EGkxYBHziBAFEVhQEegWF1iUWBDAEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="211987722" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2017 17:45:11 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v1FHjASn024645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 17:45:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 15 Feb 2017 12:45:10 -0500 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; Wed, 15 Feb 2017 12:45:10 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFqWnkA Date: Wed, 15 Feb 2017 17:45:10 +0000 Message-ID: References: In-Reply-To: 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.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:45:14 -0000 Hi Lada,=20 I=B9ve discussed your comments with my co-authors and we are incorporating most of them. See inline. On 2/13/17, 9:01 AM, "Ladislav Lhotka" wrote: >Hi, > >I was assigned to be the YANG doctor for this document. Here is my >review: > >**** General comments > >***** Configuration and state data >=20 > The module "ietf-key-chain" represents state data in a way that > departs from the convention that has been used so far in most > IETF modules, i.e. separate configuration and state data > trees. I know this is a controversial topic but I also won't > hide that I prefer the "traditional" arrangement. In any case, > this data model organization clutters the output of the NETCONF > "get" operation. I assume in most (all?) cases the "*-state" > parameters will be the same as the configured value. Already discussed.=20 > >***** Cryptographic algorithm types > > What is the reason for representing these as a YANG choice with > empty leaves? I think it would be more natural to use a single > leaf, either an enumeration or (if extensibility is important) > identityref. We are moving to identities. > >***** Reusability > > The module defines key-chain as a grouping with the aim of > making it reusable in other modules. However, this approach has > known problems that are discussed in > draft-ietf-netmod-schema-mount. I am not sure how relevant they > are in this case but, for one, the "key-chain-ref" > type is not applicable if the "key-chain" grouping is used in > another module. An alternative is not to use the grouping and > rely on schema mount. We will collapse unneeded levels of grouping. However, note that using grouping is a common YANG model practice (e.g., RFC 8022). We=B9ll also remove the statement regarding the top level usage of key-chain from the text. > >***** Key string style > > The difference between ASCII and hexadecimal > formats of key strings should be explained. I understand that > the latter is a hash of the key and, if so, I'd suggest to > include "hexadecimal-string" also in state data. The hexadecimal option is not a hash. Rather, it a specification option that allows more entropy (256 hex unique hex digits versus printable ASCII characters). We=B9ll explain this in the text. > > Also, I believe that storing clear-text key in configuration is > insecure and Security Considerations should warn against it. I=B9ll add this.=20 > >***** Example > > It might be useful to include an appendix with example instance >data. Helen has provided some examples. > >**** Specific comments > =20 >***** Sec. 2 > > - paragraph 2: s/where ever/wherever/ Fixed.=20 > >***** Sec. 3 > > - paragraph 1: replace both Key-Id a Key-ID with Key ID (the > latter is used in other places of the text). Fixed.=20 > > - paragraph 2: the suggested way of supporting assymetric keys > looks like a hack, I would suggest a more explicit > representation, e.g. using a choice. I hate to add multiple ways to do the same thing - especially when the more general specification has been in use for 15-20 years. > >***** Sec. 4 > > - The module has inconsistent indentation: up to "grouping > crypto-algorithm-types", top-level statements are indented with > four spaces, the subsequent ones with five spaces. We will fix.=20 > >***** Sec. 6 > > - The statement "Given that the key chains themselves are > sensitive data, it is RECOMMENDED that the NETCONF > communication channel be encrypted." is misleading because RFC > 6241 requires that transport protocols for NETCONF guarantee > confidentiality (and RFC 8040 does the same for RESTCONF). We will rewrite since NETCONF is always encrypted. Thanks, Acee=20 > >Lada > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 15 09:49:38 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBD6129B07; Wed, 15 Feb 2017 09:49:36 -0800 (PST) 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, 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 oSO2WUpH6gQx; Wed, 15 Feb 2017 09:49:35 -0800 (PST) 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 53853129B05; Wed, 15 Feb 2017 09:49:35 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r141so46710530wmg.1; Wed, 15 Feb 2017 09:49:35 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=NSMKwr3GTdewU014sG5wxD9Vn75MLm8IJgqGraTc1Cc=; b=quyLxt4X6z/jdZYmI7iV9Fxy2eduBDpSozCGziLGi/2gVctxYTjg3GjOFDuS5wIubI dEEbuFmK8Tp/lYp2KmWlBXDPu+1enSWIUa4nELzM1iLnjpxSiifqt3O7MPQ18UE3Eq1I gjpNHqtYUHmKFbKdcHZqvbvJw35G7wIirafJRxEgyISxV7PZft6JFtQCYNTleThd1Xf9 z3wr6BlqWScLB7hCBi/P+EffGy08HWEfivsnEA7jIO1oLO8PbrSDVn01xU7y4RfU/Chd I/A6BoQBMLNCcViUI0rHObEdcfF52Enx76avyUfYCR4W+6O5PNJDTRScFITRyDvfqo8M //RA== 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 :content-transfer-encoding:message-id:references:to; bh=NSMKwr3GTdewU014sG5wxD9Vn75MLm8IJgqGraTc1Cc=; b=OOYDraqbeo8eVh7BTQUYz9VlKT2K6h/I3aL/NuB77oTghQ5RA+Qt7YBnJOhwY8BkUu 2MZzBvnvgCjqy1/EhC5dCHCF17tRAMpTtBiRfkUDDwJO2R9H00ewgk4Mc4g/fuQOj9pK P5WhVxPOoKzgCPqXmpdOJABjY4LPPDHgbDPQArCa8JNlvlOUSuix/Zei5XZXLldL6JvA NR3u7Wz3DKrCymZUi8mYg3jeXdkH/O6o9qu48Cfr2C1QOs8LPbhpkfcH+ddGzcZIMblR sZaDkB46rSZaq+4q+5jAkxXogiMjJzA/z8glVwke0dxsnQqMXaR3dxzFrmslseYqvayg 2kgQ== X-Gm-Message-State: AMke39lASXRl/Gu+99Wd/I8zFCqgYv+YC7NmnbtW9XskEsmrS9wBKtmntSgccfvhsGJJYQ== X-Received: by 10.28.62.144 with SMTP id l138mr8960322wma.50.1487180973818; Wed, 15 Feb 2017 09:49:33 -0800 (PST) Received: from [10.228.6.141] ([94.119.142.194]) by smtp.gmail.com with ESMTPSA id j18sm5728198wrb.33.2017.02.15.09.49.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 09:49:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Wed, 15 Feb 2017 17:49:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Acee Lindem (acee)" Archived-At: Cc: "yang-doctors@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 17:49:37 -0000 Fantastic! Thanks both Lada and Acee for quick resolution! Regards, Jeff > On Feb 15, 2017, at 17:45, Acee Lindem (acee) wrote: >=20 > Hi Lada,=20 >=20 > I=C2=B9ve discussed your comments with my co-authors and we are incorporat= ing > most of them. See inline. >=20 >> On 2/13/17, 9:01 AM, "Ladislav Lhotka" wrote: >>=20 >> Hi, >>=20 >> I was assigned to be the YANG doctor for this document. Here is my >> review: >>=20 >> **** General comments >>=20 >> ***** Configuration and state data >>=20 >> The module "ietf-key-chain" represents state data in a way that >> departs from the convention that has been used so far in most >> IETF modules, i.e. separate configuration and state data >> trees. I know this is a controversial topic but I also won't >> hide that I prefer the "traditional" arrangement. In any case, >> this data model organization clutters the output of the NETCONF >> "get" operation. I assume in most (all?) cases the "*-state" >> parameters will be the same as the configured value. >=20 > Already discussed.=20 >=20 >>=20 >> ***** Cryptographic algorithm types >>=20 >> What is the reason for representing these as a YANG choice with >> empty leaves? I think it would be more natural to use a single >> leaf, either an enumeration or (if extensibility is important) >> identityref. >=20 > We are moving to identities. >=20 >>=20 >> ***** Reusability >>=20 >> The module defines key-chain as a grouping with the aim of >> making it reusable in other modules. However, this approach has >> known problems that are discussed in >> draft-ietf-netmod-schema-mount. I am not sure how relevant they >> are in this case but, for one, the "key-chain-ref" >> type is not applicable if the "key-chain" grouping is used in >> another module. An alternative is not to use the grouping and >> rely on schema mount. >=20 > We will collapse unneeded levels of grouping. However, note that using > grouping is a common YANG model practice (e.g., RFC 8022). We=C2=B9ll also= > remove the statement regarding the top level usage of key-chain > from the text. >=20 >>=20 >> ***** Key string style >>=20 >> The difference between ASCII and hexadecimal >> formats of key strings should be explained. I understand that >> the latter is a hash of the key and, if so, I'd suggest to >> include "hexadecimal-string" also in state data. >=20 > The hexadecimal option is not a hash. Rather, it a specification option > that allows more entropy (256 hex unique hex digits versus printable ASCII= > characters). We=C2=B9ll explain this in the text. >=20 >>=20 >> Also, I believe that storing clear-text key in configuration is >> insecure and Security Considerations should warn against it. >=20 > I=C2=B9ll add this.=20 >=20 >>=20 >> ***** Example >>=20 >> It might be useful to include an appendix with example instance >> data. >=20 > Helen has provided some examples. >=20 >=20 >>=20 >> **** Specific comments >>=20 >> ***** Sec. 2 >>=20 >> - paragraph 2: s/where ever/wherever/ >=20 > Fixed.=20 >=20 >>=20 >> ***** Sec. 3 >>=20 >> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the >> latter is used in other places of the text). >=20 > Fixed.=20 >=20 >>=20 >> - paragraph 2: the suggested way of supporting assymetric keys >> looks like a hack, I would suggest a more explicit >> representation, e.g. using a choice. >=20 > I hate to add multiple ways to do the same thing - especially when the > more general specification has been in use for 15-20 years. >=20 >=20 >>=20 >> ***** Sec. 4 >>=20 >> - The module has inconsistent indentation: up to "grouping >> crypto-algorithm-types", top-level statements are indented with >> four spaces, the subsequent ones with five spaces. >=20 > We will fix.=20 >=20 >=20 >>=20 >> ***** Sec. 6 >>=20 >> - The statement "Given that the key chains themselves are >> sensitive data, it is RECOMMENDED that the NETCONF >> communication channel be encrypted." is misleading because RFC >> 6241 requires that transport protocols for NETCONF guarantee >> confidentiality (and RFC 8040 does the same for RESTCONF). >=20 >=20 > We will rewrite since NETCONF is always encrypted. >=20 > Thanks, > Acee=20 >=20 >=20 >=20 >>=20 >> Lada >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >=20 From nobody Wed Feb 15 12:48:05 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850091297CD; Wed, 15 Feb 2017 12:48:03 -0800 (PST) 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 t8M1WIL7YsP5; Wed, 15 Feb 2017 12:48:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79E1129785; Wed, 15 Feb 2017 12:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3591; q=dns/txt; s=iport; t=1487191681; x=1488401281; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8FPyz2u0u0KOda+7gc4e1DXML4kFmBYGvossGmEG3Og=; b=U/27dwCSYXw0nm19vpJC6x6WNOypgeHwMnibEainvrq8hPaWq92aGsYD QujyxrwVSIl21toyFJug4F62Ow8otmRnHF1jZmoN9lioBpyfO+OVbjGdr cXgRSSvbTFFZp82BE0tppikDw2UmWY5HWwzFj3Bd4vgI3ljvRPMi1Zwlx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqAQCtvaRY/4YNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1KBageNWpIQkyeCD4IMhiICghQ/GAECAQEBAQEBAWIohHABAQEDAXQ?= =?us-ascii?q?FEAIBCBguMiUCBAENBYljCLJZizUBAQEBAQEBAQEBAQEBAQEBAQEBH4s8ihofB?= =?us-ascii?q?ZAEhVGGIgGSE4F7hReDUIYkkxYBHziBAFEVPYZDdYlFgQwBAQE?= X-IronPort-AV: E=Sophos;i="5.35,166,1484006400"; d="scan'208";a="209048006" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Feb 2017 20:48:00 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1FKm0di007679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Feb 2017 20:48:00 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; Wed, 15 Feb 2017 15:48:00 -0500 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; Wed, 15 Feb 2017 15:48:00 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , =?iso-8859-1?Q?Martin_Bj=F6rklund?= Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4g== Date: Wed, 15 Feb 2017 20:48:00 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> In-Reply-To: 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.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:48:03 -0000 Hi Martin,=20 On 2/13/17, 10:07 AM, "Ladislav Lhotka" wrote: > >> On 13 Feb 2017, at 15:33, Martin Bjorklund wrote: >>=20 >> Hi, >>=20 >> I had reasons to read this document the other day, and I have some >> additional comments: >>=20 >> o The revision history should be trimmed to just a single entry. The >> idea is to only keep revision only for published versions (in this >> case RFC versions). > >I think that at least in some cases, e.g. if a module stays relatively >long in the draft stage, it makes sense to record all revisions so as to >be able to tell them apart. > >6087bis says: > > It is not required to keep the full revision history of draft > versions (e.g., modules contained within Internet-Drafts). That is, > within a sequence of draft versions, only the most recent revision > need be recorded in the module. > >So it doesn't preclude recording "intermediate" revisions. I would >personally leave it to each author's discretion. I think now that we are close to publication, removing them is a good idea.=20 > >>=20 >> o Lists should be named with the singular form, so "list >> key-chain-entries" should be "key-chain-entry". Ok.=20 >> But I wonder about >> the terminolgy; the draft text says: >>=20 >> A key chain is a list of elements each containing a key >>=20 >> so I think the YANG names should reflect this terminology. Thus I >> suggest that "key-chain-list" is renamed to "key-chain" and >> "key-chain-entry" to "key". You need to read the rest of the sentence to see that there is a list of associated items in the key-chain-entry. It would incorrect to refer to the aggregate as simply a key. >>If you agree, the top-level container >> should probably be renamed to "key-chains" (and "key-chains-state") >> also. I have made this change. Thanks Acee=20 > >I agree. > >>=20 >>=20 >> Ladislav Lhotka wrote: >>> Hi, >>>=20 >>> I was assigned to be the YANG doctor for this document. Here is my >>> review: >>>=20 >>> **** General comments >>>=20 >>> ***** Configuration and state data >>>=20 >>> The module "ietf-key-chain" represents state data in a way that >>> departs from the convention that has been used so far in most >>> IETF modules, i.e. separate configuration and state data >>> trees. I know this is a controversial topic but I also won't >>> hide that I prefer the "traditional" arrangement. In any case, >>> this data model organization clutters the output of the NETCONF >>> "get" operation. I assume in most (all?) cases the "*-state" >>> parameters will be the same as the configured value. >>=20 >> But this module does have two separate top-level trees, /key-chain and >> /key-chain-state. What do I miss? > >Hmm, I don't know what I saw, maybe I got confused by the groupings. I am >sorry for the noise, please ignore this item. > >Thanks, Lada > >>=20 >>> ***** Sec. 4 >>>=20 >>> - The module has inconsistent indentation: up to "grouping >>> crypto-algorithm-types", top-level statements are indented with >>> four spaces, the subsequent ones with five spaces. >>=20 >> I suggest you run "pyang -f yang --yang-canonical" on your module. It >> will produce a module that is consistent with our IETF modules in >> terms of indentation and module layout. >>=20 >>=20 >>=20 >> /martin > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Feb 15 23:58:56 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A56B1299D4; Wed, 15 Feb 2017 23:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1JvOxmTxkMsz; Wed, 15 Feb 2017 23:58:53 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A4BA11299D1; Wed, 15 Feb 2017 23:58:53 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2B8EE1820009; Thu, 16 Feb 2017 08:57:58 +0100 (CET) From: Ladislav Lhotka To: "Acee Lindem \(acee\)" , "draft-ietf-rtgwg-yang-key-chain.all\@ietf.org" In-Reply-To: References: Date: Thu, 16 Feb 2017 08:58:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 07:58:55 -0000 Hi Acee, with the indicated changes, I believe the document is ready to be published. A few comments are inline. "Acee Lindem (acee)" writes: >>***** Reusability >> >> The module defines key-chain as a grouping with the aim of >> making it reusable in other modules. However, this approach has >> known problems that are discussed in >> draft-ietf-netmod-schema-mount. I am not sure how relevant they >> are in this case but, for one, the "key-chain-ref" >> type is not applicable if the "key-chain" grouping is used in >> another module. An alternative is not to use the grouping and >> rely on schema mount. > > We will collapse unneeded levels of grouping. However, note that using > grouping is a common YANG model practice (e.g., RFC 8022). We=C2=B9ll also > remove the statement regarding the top level usage of key-chain > from the text. Groupings are good for relatively small sets of reusable parameters but not so much for making the whole module "relocatable". And, of course, they make the data model more difficult to read. > >> >>***** Key string style >> >> The difference between ASCII and hexadecimal >> formats of key strings should be explained. I understand that >> the latter is a hash of the key and, if so, I'd suggest to >> include "hexadecimal-string" also in state data. > > The hexadecimal option is not a hash. Rather, it a specification option > that allows more entropy (256 hex unique hex digits versus printable ASCII > characters). We=C2=B9ll explain this in the text. I see, but you don't have any length restriction on either keystring or hexadecimal-string, so both can be made arbitrarily strong, no? >> >> - paragraph 2: the suggested way of supporting assymetric keys >> looks like a hack, I would suggest a more explicit >> representation, e.g. using a choice. > > I hate to add multiple ways to do the same thing - especially when the > more general specification has been in use for 15-20 years. It is up to you to decide, I just find it cleaner to say explicitly that a key is not to be used for sending rather than make the send-lifetime interval empty. But I know from another context (DNS) that admins are often fond of peculiar hacks they have been using for ages, and reluctant to abandon them even if the new solution is arguably better. Thanks, Lada --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 15 23:59:32 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1951299D5; Wed, 15 Feb 2017 23:59:31 -0800 (PST) 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 Ns0nxWQaVj73; Wed, 15 Feb 2017 23:59:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E0B731299D1; Wed, 15 Feb 2017 23:59:29 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 52E701AE033A; Thu, 16 Feb 2017 08:59:28 +0100 (CET) Date: Thu, 16 Feb 2017 08:59:28 +0100 (CET) Message-Id: <20170216.085928.1948519631339286112.mbj@tail-f.com> To: acee@cisco.com From: Martin Bjorklund In-Reply-To: References: <20170213.153306.1164034975842789777.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: Cc: yang-doctors@ietf.org, draft-ietf-rtgwg-yang-key-chain.all@ietf.org Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 07:59:31 -0000 Hi Acee, I saw the new revision, thank you for addressing my comments. One comment inline. "Acee Lindem (acee)" wrote: > Hi Martin, > > On 2/13/17, 10:07 AM, "Ladislav Lhotka" wrote: > > > > >> On 13 Feb 2017, at 15:33, Martin Bjorklund wrote: [...] > >> But I wonder about > >> the terminolgy; the draft text says: > >> > >> A key chain is a list of elements each containing a key > >> > >> so I think the YANG names should reflect this terminology. Thus I > >> suggest that "key-chain-list" is renamed to "key-chain" and > >> "key-chain-entry" to "key". > > You need to read the rest of the sentence to see that there is a list of > associated items in the key-chain-entry. It would incorrect to refer to > the aggregate as simply a key. Ok, this makes sense. The YANG module now uses the term "key entry" for this. > >>If you agree, the top-level container > >> should probably be renamed to "key-chains" (and "key-chains-state") > >> also. > > I have made this change. For consistency with other models, and maybe simpler mapping between the config and state, you may want to remove the "-state" suffix on the descendant nodes from "key-chains-state". Specifically, change: list key-chain-state to list key-chain and list key-entry-state to list key-entry Then we can talk about a configured "key chain" vs the operationally uses "key chain". /martin From nobody Thu Feb 16 07:42:50 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5F129D1C; Thu, 16 Feb 2017 07:42:48 -0800 (PST) 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 dCHL8RNiH4Xl; Thu, 16 Feb 2017 07:42:47 -0800 (PST) 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 C70F7129D1A; Thu, 16 Feb 2017 07:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1995; q=dns/txt; s=iport; t=1487259766; x=1488469366; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E+PQSNQaUY9IXbyKIfedigEJT3aJ4nsWtEWgotBOyQQ=; b=inNhPaJulUtNoDNpNh6MiW9Q0ePsQO9RJQk7Ril8eAzX0C/McE19NK/f Z1oyXMY2o1otYM6ZVBVgqjp4XsWaQIfkTV5oO8JR0VEWSB5jTegvKZUMM f5NeDwSKnYDfZgB782Tv8gE7jbUVqwoYrSqFeAq/lL3ctSFep/fvxQiGd I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQA1x6VY/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBageNWpIQkySCD4IMhiICggo/GAECAQEBAQEBAWIohHEBBXk?= =?us-ascii?q?QAgEIDgouMiUCBA4FiWyydos7AQEBAQEBAQMBAQEBAQEBIYs7hFSFRh8BBJAGi?= =?us-ascii?q?3kBkhaBe4hnhiSTFwEfOIEAURU9hkR1iSqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="386352640" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 15:42:46 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1GFgjBA000864 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 15:42:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 10:42:45 -0500 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; Thu, 16 Feb 2017 10:42:45 -0500 From: "Acee Lindem (acee)" To: Martin Bjorklund Thread-Topic: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFrnP8AgAAtm4A= Date: Thu, 16 Feb 2017 15:42:45 +0000 Message-ID: References: <20170213.153306.1164034975842789777.mbj@tail-f.com> <20170216.085928.1948519631339286112.mbj@tail-f.com> In-Reply-To: <20170216.085928.1948519631339286112.mbj@tail-f.com> 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.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "yang-doctors@ietf.org" , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:42:49 -0000 Hi Martin,=20 On 2/16/17, 2:59 AM, "Martin Bjorklund" wrote: >Hi Acee, > >I saw the new revision, thank you for addressing my comments. > >One comment inline. > >"Acee Lindem (acee)" wrote: >> Hi Martin,=20 >>=20 >> On 2/13/17, 10:07 AM, "Ladislav Lhotka" wrote: >>=20 >> > >> >> On 13 Feb 2017, at 15:33, Martin Bjorklund wrote: > >[...] > >> >> But I wonder about >> >> the terminolgy; the draft text says: >> >>=20 >> >> A key chain is a list of elements each containing a key >> >>=20 >> >> so I think the YANG names should reflect this terminology. Thus I >> >> suggest that "key-chain-list" is renamed to "key-chain" and >> >> "key-chain-entry" to "key". >>=20 >> You need to read the rest of the sentence to see that there is a list of >> associated items in the key-chain-entry. It would incorrect to refer to >> the aggregate as simply a key. > >Ok, this makes sense. The YANG module now uses the term "key entry" >for this. Actually, I reversed this and went with the shorter identifier since it is unambiguous. I also went through the text and changed to this terminology. > >> >>If you agree, the top-level container >> >> should probably be renamed to "key-chains" (and "key-chains-state") >> >> also. >>=20 >> I have made this change. > >For consistency with other models, and maybe simpler mapping between >the config and state, you may want to remove the "-state" suffix on >the descendant nodes from "key-chains-state". Specifically, change: > > list key-chain-state > >to > > list key-chain > >and > > list key-entry-state > >to > > list key-entry I made this change as well. The only place the =B3-state=B2 suffix is prese= nt is at the top level keychains-state. Thanks, Acee=20 > > >Then we can talk about a configured "key chain" vs the operationally >uses "key chain". > > > > >/martin From nobody Thu Feb 16 07:50:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0218712944D for ; Thu, 16 Feb 2017 07:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 s5Tb8q0NaPxr for ; Thu, 16 Feb 2017 07:50:20 -0800 (PST) Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (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 63101128AC9 for ; Thu, 16 Feb 2017 07:50:20 -0800 (PST) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v1GFoHM5054584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2017 09:50:17 -0600 Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 566D01E0088; Thu, 16 Feb 2017 08:50:12 -0700 (MST) Received: from lxdnp32k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 238F61E006F; Thu, 16 Feb 2017 08:50:12 -0700 (MST) Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v1GFoBn7056457; Thu, 16 Feb 2017 08:50:11 -0700 Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v1GFoB9m056436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Feb 2017 08:50:11 -0700 Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Thu, 16 Feb 2017 09:50:11 -0600 From: "Bugenhagen, Michael K" To: "yang-doctors@ietf.org" Thread-Topic: Cloud portal telemetry alignment with - does YANG have model the hierarchy to support cloud portal telemetry? Thread-Index: AQHSiGxaYYR3xNkK2Uys2mXL/81beQ== Date: Thu, 16 Feb 2017 15:50:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [155.70.16.191] Content-Type: multipart/alternative; boundary="_000_F9CE4726790142F3A357A865368F13D5centurylinkcom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "lberger@labn.net" , "db3546@att.com" Subject: [yang-doctors] Cloud portal telemetry alignment with - does YANG have model the hierarchy to support cloud portal telemetry? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:50:22 -0000 --_000_F9CE4726790142F3A357A865368F13D5centurylinkcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCiAgICAgSeKAmW0gd29ya2luZyBzb21lIHByb3ZpZGVyIGJ1c2luZXNzIHByb2pl Y3RzIHdpdGggb3RoZXIgY2FycmllcnMgYW5kIHdl4oCZbGwgYmUgY3JhZnRpbmcgYSBzdGFuZGFy ZCBuZXR3b3JrIHRlbGVtZXRyeSBBUEkgZnJhbWV3b3JrIHRoYXQgd2lsbCBzdXBwb3J0IHRlbGVt ZXRyeSBmb3IgQ2xvdWQgcG9ydGFscy4NCg0KQ2xvdWQgcG9ydGFscyB1c2UgYSB2ZXJ5IHNwZWNp ZmljIG1vZGVsIGRyaXZlbiBoaWVyYXJjaHkgdXNpbmcgdGhlIOKAnGNsb3VkIHRyYW5zcGFyZW5j eeKAnSBwcmluY2lwbGUgb2YgZXhwb3NpbmcgcmVzb3VyY2UgdGVsZW1ldHJ5Lg0KU3BlY2lmaWNh bGx5LCBpZiB3ZSBjYW7igJl0IG1hcCB0aGF0IHRlbGVtZXRyeSB0byB0aGUgbWF0Y2hpbmcgcmVz b3VyY2UgbGV2ZWxzIHRoZW4gdGhhdCB0ZWxlbWV0cnkgaXMgdW5maXQgZm9yIGNsb3VkIHBvcnRh bCBkaXNwbGF5IChpdOKAmXMgYnJva2VuKS4NCg0KQ2xvdWQgcG9ydGFscyByZXByZXNlbnQgcmVz b3VyY2VzIGluIHRoaXMgaGllcmFyY2h5DQoNCiAgICAgICAgICAgICAgICBBdG9taWMsIENvbXBv c2l0ZSwgQ2x1c3RlciwgQ2xvdWQgICAgIC0NCg0KVGhpcyBtb2RlbCBpcyB0aGUgY3Jvc3Mgb3Zl ciBwb2ludCBiZXR3ZWVuIOKAnE1lbnUgb3JpZW50ZWQgb3JkZXJpbmcgTW9kZWzigJ0gcG9ydGFs cywgYW5kIENsb3VkIHRoYXQgZW5hYmxlZCB0aGVtIHRvIGhhdmUgY3VzdG9tZXIgY2xvdWQgcG9y dGFscy4NCkFsbCBvcmRlcmluZyAoZXZlbiBNY0RvbmFsZHMpIHVzZXMgdGhlIHBpY2tsZXMsIGhh bWJ1cmdlciwgaGFwcHkgbWVhbCwg4oCmLA0KQ2xvdWQgdXNlcyDigJxDUFUsIE1lbW9yeSwgY29t cG9zaXRlID0gVk0sIENsdXN0ZXIgPSBzdG9yYWdlIGNsdXN0ZXIsIGdyb3VwIG9mIHNlcnZlcnMs ICAuLiAgIGFuZCBvZiBjb3Vyc2UsIGEgVmlydHVhbCBEYXRhIENlbnRlciA9IENsb3VkDQpFYWNo IGxldmVsIGJlaW5nIGEgY29tcG9zaXRlIG9mIHRoZSBsb3dlciBtb2RlbHMgc28gdGhhdCBvbmNl IGNhbiDigJxjbGljayBkb3du4oCdIGludG8gdGhlIGxvd2VyIGxldmVsIHJlc291cmNlcyB0byBk aXNwbGF5IHRoZSB0ZWxlbWV0cnkuDQoNCkhvd2V2ZXIsIHJpZ2h0IG5vdyBZYW5nIGlzIHdpdGhv dXQgYW55IHN1Y2gg4oCcbW9kZWwgZHJpdmVuIGNvbnN0cnVjdOKAnSB0aGF0IEkgY2FuIGZpbmQg 4oCTIGl04oCZcyBidWlsZCBmb3IgU0ROLCBhbmQgT3JjaGVzdHJhdGlvbiDigJMgYnV0IG5vdCB0 aGUgcG9ydGFsLg0KDQoqKiBNeSBxdWVzdGlvbihzKQ0KDQphKSAgICAgICBIYXZlIHRoZSBZQU5H IC8gTkVUQ09ORiBncm91cHMgY29uc2lkZXJlZCB0aGlzIGhpZXJhcmNoeSDigKYNClRvIGJlIHN1 aXRhYmxlIGZvciBjbG91ZCBwb3J0YWwgdGVsZW1ldHJ5IHdlIHdvdWxkIG5lZWQgYSDigJxtb2Rl bCBkcml2ZW7igJ0gZnJhbWV3b3JrIHRoYXQgcHJvdmlkZWQgdGhpcyBzZXQgb2YgWUFORyBtb2Rl bHMsIHdpdGggYSBrbm93biBoaWVyYXJjaHkuDQoNCg0KDQppZS4gIC0tIGVhY2ggZW50aXR5IGxl dmVsIHdvdWxkIGhhdmUgYSBzZXQgb2Ygc3RhbmRhcmQgcmVzb3VyY2UgQ0lN4oCZcyB0byBzdXBw b3J0IHRoZSBwb3J0YWwuIChBdG9taWMsIENvbXBvc2l0ZSwg4oCmKQ0KDQpDdXJyZW50bHksIEni gJltIHRoaW5raW5nIGFib3V0IGhhdmluZyA0IHN0YW5kYXJkIHlhbmcgbW9kZWxzIHRoYXQgY291 bGQgYmUgZXN0YWJsaXNoZWQgZm9yIGFueSBvbmUgcmVzb3VyY2UgZm9yIGRpc3BsYXkgaW4gYSBj bG91ZCBwb3J0YWwuDQoNCg0KYSkgICAgICAgUmVzb3VyY2UgLyBTZXJ2aWNlIGF0dHJpYnV0ZQ0K DQpiKSAgICAgICBQTQ0KDQpjKSAgICAgICBGTQ0KDQpkKSAgICAgICBBbGxvd2FibGUgc3RhdGVz DQoNClRoaXMgd2F5IGFueW9uZSBjb3VsZCBtYWtlIGEg4oCcbW9kZWzigJ0gb2YgdGhhdCByZXNv dXJjZSBmb3IgZGlzcGxheSBpbnRvIGEgY2xvdWQgcG9ydGFsIC0NCg0KKiogVGhpcyB3b3Jr4oCZ cyBnb2luZyB0byBtb3ZlIGZvcndhcmQgdG8gY3JlYXRlIGEgc3RhbmRhcmQgTmV0d29yayBBUEkg Zm9yIGNsb3VkIHRlbGVtZXRyeSAoSeKAmW0gb25seSBzaG93aW5nIG9uZSBwaWVjZSBvZiB0aGUg cHJvYmxlbSBoZXJlIOKAkyB0aGUgcmVzdCB3aWxsIGJlIGFkZHJlc3NlZCBpbiBvdGhlciBhcmVh cykuICBIb3dldmVyLCBJIHRoaW5rIHdl4oCZbGwgYmUgY29taW5nIGFyb3VuZCB0byBkaXNjdXNz IHRoaXMgd2l0aCB0aGUgSUVURiBzbyBJIHdhbnRlZCB0byBwaW5nIHlvdXIgdGVhbS4NCg0KVGhh bmtzLA0KTWljaGFlbCBCdWdlbmhhZ2VuDQpDZW50dXJ5TGluaw0KTkZWIENoaWVmIEFyY2hpdGVj dCwgRWNvLVN5c3RlbSBTdHJhdGVneSAmIERldi4NCg0KDQpUaGlzIGNvbW11bmljYXRpb24gaXMg dGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVkIHVzZSBvZiB0aGlzIGNvbW11 bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l ZGlhdGVseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwgYW5kIGRlc3Ryb3kgYWxs IGNvcGllcyBvZiB0aGUgY29tbXVuaWNhdGlvbiBhbmQgYW55IGF0dGFjaG1lbnRzLg0K --_000_F9CE4726790142F3A357A865368F13D5centurylinkcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5FF4587FA4508F4E9C37EA2267BD59F8@centurylink.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3Nl Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lu cw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjA4MzQy MjQ4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQ1 OTA3NTEyNCA2NzY5ODcxMSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCki Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTkwODE1NDUwOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTA2ODA4MDIyIDY3Njk4NzExIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMTE0 NzE1ODI1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot Mjg0NjQ1MTc4IDY3Njk4NzExIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiJTFc KSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhl bGxvLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJ4oCZbSB3b3JraW5nIHNvbWUgcHJvdmlkZXIgYnVzaW5lc3MgcHJv amVjdHMgd2l0aCBvdGhlciBjYXJyaWVycyBhbmQgd2XigJlsbCBiZSBjcmFmdGluZyBhIHN0YW5k YXJkIG5ldHdvcmsgdGVsZW1ldHJ5IEFQSSBmcmFtZXdvcmsgdGhhdCB3aWxsIHN1cHBvcnQgdGVs ZW1ldHJ5IGZvciBDbG91ZCBwb3J0YWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Q2xvdWQgcG9ydGFscyB1c2UgYSB2ZXJ5IHNwZWNpZmljIG1vZGVsIGRyaXZl biBoaWVyYXJjaHkgdXNpbmcgdGhlIOKAnGNsb3VkIHRyYW5zcGFyZW5jeeKAnSBwcmluY2lwbGUg b2YgZXhwb3NpbmcgcmVzb3VyY2UgdGVsZW1ldHJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TcGVjaWZp Y2FsbHksIGlmIHdlIGNhbuKAmXQgbWFwIHRoYXQgdGVsZW1ldHJ5IHRvIHRoZSBtYXRjaGluZyBy ZXNvdXJjZSBsZXZlbHMgdGhlbiB0aGF0IHRlbGVtZXRyeSBpcyB1bmZpdCBmb3IgY2xvdWQgcG9y dGFsIGRpc3BsYXkgKGl04oCZcyBicm9rZW4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Q2xvdWQgcG9ydGFscyByZXByZXNlbnQgcmVzb3VyY2VzIGluIHRoaXMg aGllcmFyY2h5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEF0b21pYywgQ29tcG9zaXRlLCBDbHVzdGVyLCBDbG91ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGlzIG1vZGVs IGlzIHRoZSBjcm9zcyBvdmVyIHBvaW50IGJldHdlZW4g4oCcTWVudSBvcmllbnRlZCBvcmRlcmlu ZyBNb2RlbOKAnSBwb3J0YWxzLCBhbmQgQ2xvdWQgdGhhdCBlbmFibGVkIHRoZW0gdG8gaGF2ZSBj dXN0b21lciBjbG91ZCBwb3J0YWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbGwgb3JkZXJpbmcgKGV2 ZW4gTWNEb25hbGRzKSB1c2VzIHRoZSBwaWNrbGVzLCBoYW1idXJnZXIsIGhhcHB5IG1lYWwsIOKA piwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DbG91ZCB1c2VzIOKAnENQVSwgTWVtb3J5LCBjb21wb3Np dGUgPSBWTSwgQ2x1c3RlciA9IHN0b3JhZ2UgY2x1c3RlciwgZ3JvdXAgb2Ygc2VydmVycywmbmJz cDsgLi4mbmJzcDsmbmJzcDsgYW5kIG9mIGNvdXJzZSwgYSBWaXJ0dWFsIERhdGEgQ2VudGVyID0g Q2xvdWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+RWFjaCBsZXZlbCBiZWluZyBhIGNvbXBvc2l0ZSBvZiB0 aGUgbG93ZXIgbW9kZWxzIHNvIHRoYXQgb25jZSBjYW4g4oCcY2xpY2sgZG93buKAnSBpbnRvIHRo ZSBsb3dlciBsZXZlbCByZXNvdXJjZXMgdG8gZGlzcGxheSB0aGUgdGVsZW1ldHJ5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SG93ZXZlciwgcmlnaHQgbm93IFlh bmcgaXMgd2l0aG91dCBhbnkgc3VjaCDigJxtb2RlbCBkcml2ZW4gY29uc3RydWN04oCdIHRoYXQg SSBjYW4gZmluZCDigJMgaXTigJlzIGJ1aWxkIGZvciBTRE4sIGFuZCBPcmNoZXN0cmF0aW9uIOKA kyBidXQgbm90IHRoZSBwb3J0YWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxicj4NCioqIE15IHF1ZXN0 aW9uKHMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkhhdmUgdGhlIFlBTkcgLyBORVRDT05GIGdyb3VwcyBjb25zaWRlcmVkIHRoaXMgaGllcmFy Y2h5IOKApiZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvIGJlIHN1aXRhYmxlIGZv ciBjbG91ZCBwb3J0YWwgdGVsZW1ldHJ5IHdlIHdvdWxkIG5lZWQgYSDigJxtb2RlbCBkcml2ZW7i gJ0gZnJhbWV3b3JrIHRoYXQgcHJvdmlkZWQgdGhpcyBzZXQgb2YgWUFORyBtb2RlbHMsIHdpdGgg YSBrbm93biBoaWVyYXJjaHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmll LiZuYnNwOyAtLSBlYWNoIGVudGl0eSBsZXZlbCB3b3VsZCBoYXZlIGEgc2V0IG9mIHN0YW5kYXJk IHJlc291cmNlIENJTeKAmXMgdG8gc3VwcG9ydCB0aGUgcG9ydGFsLiAoQXRvbWljLCBDb21wb3Np dGUsIOKApik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkN1cnJl bnRseSwgSeKAmW0gdGhpbmtpbmcgYWJvdXQgaGF2aW5nIDQgc3RhbmRhcmQgeWFuZyBtb2RlbHMg dGhhdCBjb3VsZCBiZSBlc3RhYmxpc2hlZCBmb3IgYW55IG9uZSByZXNvdXJjZSBmb3IgZGlzcGxh eSBpbiBhIGNsb3VkIHBvcnRhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij5hKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlc291cmNlIC8gU2Vy dmljZSBhdHRyaWJ1dGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+UE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmMpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Rk08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZv MSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPmQpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+QWxsb3dhYmxlIHN0YXRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+VGhpcyB3YXkgYW55b25lIGNvdWxkIG1ha2UgYSDigJxtb2RlbOKAnSBv ZiB0aGF0IHJlc291cmNlIGZvciBkaXNwbGF5IGludG8gYSBjbG91ZCBwb3J0YWwgLSZuYnNwOw0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4qKiBUaGlzIHdvcmvi gJlzIGdvaW5nIHRvIG1vdmUgZm9yd2FyZCB0byBjcmVhdGUgYSBzdGFuZGFyZCBOZXR3b3JrIEFQ SSBmb3IgY2xvdWQgdGVsZW1ldHJ5IChJ4oCZbSBvbmx5IHNob3dpbmcgb25lIHBpZWNlIG9mIHRo ZSBwcm9ibGVtIGhlcmUg4oCTIHRoZSByZXN0IHdpbGwgYmUgYWRkcmVzc2VkIGluIG90aGVyIGFy ZWFzKS4mbmJzcDsgSG93ZXZlciwgSSB0aGluayB3ZeKAmWxsDQogYmUgY29taW5nIGFyb3VuZCB0 byBkaXNjdXNzIHRoaXMgd2l0aCB0aGUgSUVURiBzbyBJIHdhbnRlZCB0byBwaW5nIHlvdXIgdGVh bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+TWljaGFlbCBCdWdlbmhhZ2VuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNlbnR1 cnlMaW5rIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ORlYgQ2hpZWYgQXJjaGl0ZWN0LCBFY28tU3lzdGVt IFN0cmF0ZWd5ICZhbXA7IERldi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGNlbnRlcj5UaGlz IGNvbW11bmljYXRpb24gaXMgdGhlIHByb3BlcnR5IG9mIENlbnR1cnlMaW5rIGFuZCBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbi4gVW5hdXRob3JpemVk IHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4g ZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseQ0KIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUt bWFpbCBhbmQgZGVzdHJveSBhbGwgY29waWVzIG9mIHRoZSBjb21tdW5pY2F0aW9uIGFuZCBhbnkg YXR0YWNobWVudHMuPC9jZW50ZXI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F9CE4726790142F3A357A865368F13D5centurylinkcom_-- From nobody Thu Feb 16 07:57:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36D9129576; Thu, 16 Feb 2017 07:57:53 -0800 (PST) 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 If-RhWW0r1Ca; Thu, 16 Feb 2017 07:57:52 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7466E1295ED; Thu, 16 Feb 2017 07:57:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3213; q=dns/txt; s=iport; t=1487260672; x=1488470272; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vKgNcb+kH8nmw5M+rX0lzvMW93TEEGZVcjdxLxkjXiI=; b=XObOsuiBJDSm8f7GhTsc0ZIr/eP+m2OmefT1UoQrIJh4ibLHQIKVw8m5 qGmLfVruRNAfMrIGdUcV0ioMCkpquLckCMqSI279cAXrDo0na+hK04ZuH cR7xWkjaEfrZzMOotc5vAMWbwW8saIaRAaq++9hmV5lkvEx7okTvn+Zjy s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAgBoy6VY/5RdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1GBagezDoIPggyGIgKCCkAXAQIBAQEBAQEBYiiEcQZ5EAIBCEY?= =?us-ascii?q?yJQIEAQ0FG4lRsn+LOwEBAQEBAQEBAQEBAQEBAQEBAQEfizuKGh8BBJt/AZIWg?= =?us-ascii?q?XuIZ4YkkxcBIAE2gQBRFYUCHoFhdYkqgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,169,1484006400"; d="scan'208";a="384986745" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2017 15:57:51 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v1GFvpZZ013637 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Feb 2017 15:57:51 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 16 Feb 2017 10:57:50 -0500 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; Thu, 16 Feb 2017 10:57:50 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Thread-Topic: YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHShgGo3YsNuj1RCk2BdRz4GVrn4qFqWnkAgAFCZICAADHygA== Date: Thu, 16 Feb 2017 15:57:50 +0000 Message-ID: References: In-Reply-To: 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.195] Content-Type: text/plain; charset="windows-1254" Content-ID: <9626FF6198BB6C499CFF902DD7D1900A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:57:54 -0000 Hi Lada,=20 On 2/16/17, 2:58 AM, "Ladislav Lhotka" wrote: >Hi Acee, > >with the indicated changes, I believe the document is ready to be >published. A few comments are inline. > >"Acee Lindem (acee)" writes: > >>>***** Reusability >>> >>> The module defines key-chain as a grouping with the aim of >>> making it reusable in other modules. However, this approach has >>> known problems that are discussed in >>> draft-ietf-netmod-schema-mount. I am not sure how relevant they >>> are in this case but, for one, the "key-chain-ref" >>> type is not applicable if the "key-chain" grouping is used in >>> another module. An alternative is not to use the grouping and >>> rely on schema mount. >> >> We will collapse unneeded levels of grouping. However, note that using >> grouping is a common YANG model practice (e.g., RFC 8022). We=B9ll also >> remove the statement regarding the top level usage of key-chain >> from the text. > >Groupings are good for relatively small sets of reusable parameters but >not so much for making the whole module "relocatable". And, of course, >they make the data model more difficult to read. I=92ve collapsed some additional groupings that are not used for common reuse in the -15 revision that I will post today. > >> >>> >>>***** Key string style >>> >>> The difference between ASCII and hexadecimal >>> formats of key strings should be explained. I understand that >>> the latter is a hash of the key and, if so, I'd suggest to >>> include "hexadecimal-string" also in state data. >> >> The hexadecimal option is not a hash. Rather, it a specification option >> that allows more entropy (256 hex unique hex digits versus printable >>ASCII >> characters). We=B9ll explain this in the text. > >I see, but you don't have any length restriction on either keystring or >hexadecimal-string, so both can be made arbitrarily strong, no? An impl=E9mentation would definitely impose a length restriction. It seems that the IETF models, in general, do not impose restrictions. What is the policy here?=20 > > >>> >>> - paragraph 2: the suggested way of supporting assymetric keys >>> looks like a hack, I would suggest a more explicit >>> representation, e.g. using a choice. >> >> I hate to add multiple ways to do the same thing - especially when the >> more general specification has been in use for 15-20 years. > >It is up to you to decide, I just find it cleaner to say explicitly that >a key is not to be used for sending rather than make the send-lifetime >interval empty. Maybe I=92ve just worked with key-chains too long but this seems intuitive enough to me.=20 There is also an indication in the operational state whether a key is active for sending or acceptance. Thanks, Acee=20 > >But I know from another context (DNS) that admins are often fond of >peculiar hacks they have been using for ages, and reluctant to abandon >them even if the new solution is arguably better. > >Thanks, Lada > >--=20 >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Feb 16 08:17:25 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0133C129D9A; Thu, 16 Feb 2017 08:17:25 -0800 (PST) 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 pKf-ZWYS2KVl; Thu, 16 Feb 2017 08:17:22 -0800 (PST) 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 97975129D56; Thu, 16 Feb 2017 08:17:22 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:140c:45a2:d9e9:c3fa] (unknown [IPv6:2001:718:1a02:1:140c:45a2:d9e9:c3fa]) by mail.nic.cz (Postfix) with ESMTPSA id 14DD960113; Thu, 16 Feb 2017 17:17:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487261841; bh=3V6eIU8M0464C7MImTzmX0sDkMtSaeGUrqKeaDmswmc=; h=From:Date:To; b=xSQ8zYdK5zE69SpcPCLzdewVL9tW8aTXLBNSWJKHaT5FGpWL9lT0uEuQoXIvRVLzI FSXk3ML1I7fIRHWg0ub1mQZgIRHiN0mxOZtPC9LoZxQplpV9bg+7eNOKne7orkIxme ECFPcZVSCOaKe0EJnajYFGyp4PeXGY8cnpUdemQo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 16 Feb 2017 17:17:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2FECB3D9-03E7-48A7-B15A-0E70AEE5B665@nic.cz> References: To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:17:25 -0000 > On 16 Feb 2017, at 16:57, Acee Lindem (acee) wrote: >=20 > Hi Lada,=20 >=20 > On 2/16/17, 2:58 AM, "Ladislav Lhotka" wrote: >=20 >> Hi Acee, >>=20 >> with the indicated changes, I believe the document is ready to be >> published. A few comments are inline. >>=20 >> "Acee Lindem (acee)" writes: >>=20 >>>> ***** Reusability >>>>=20 >>>> The module defines key-chain as a grouping with the aim of >>>> making it reusable in other modules. However, this approach has >>>> known problems that are discussed in >>>> draft-ietf-netmod-schema-mount. I am not sure how relevant they >>>> are in this case but, for one, the "key-chain-ref" >>>> type is not applicable if the "key-chain" grouping is used in >>>> another module. An alternative is not to use the grouping and >>>> rely on schema mount. >>>=20 >>> We will collapse unneeded levels of grouping. However, note that = using >>> grouping is a common YANG model practice (e.g., RFC 8022). We=C2=B9ll = also >>> remove the statement regarding the top level usage of key-chain >>> from the text. >>=20 >> Groupings are good for relatively small sets of reusable parameters = but >> not so much for making the whole module "relocatable". And, of = course, >> they make the data model more difficult to read. >=20 >=20 > I=E2=80=99ve collapsed some additional groupings that are not used for = common > reuse in the -15 revision that I will post today. OK. >=20 >=20 >=20 >>=20 >>>=20 >>>>=20 >>>> ***** Key string style >>>>=20 >>>> The difference between ASCII and hexadecimal >>>> formats of key strings should be explained. I understand that >>>> the latter is a hash of the key and, if so, I'd suggest to >>>> include "hexadecimal-string" also in state data. >>>=20 >>> The hexadecimal option is not a hash. Rather, it a specification = option >>> that allows more entropy (256 hex unique hex digits versus printable >>> ASCII >>> characters). We=C2=B9ll explain this in the text. >>=20 >> I see, but you don't have any length restriction on either keystring = or >> hexadecimal-string, so both can be made arbitrarily strong, no? >=20 > An impl=C3=A9mentation would definitely impose a length restriction. = It seems > that the IETF models, in general, do not impose restrictions. What is = the > policy here? I'd suggest to include minimum length for both in this module, and = implementations can specify maximum supported length through a deviation = if needed. > =20 >=20 >>=20 >>=20 >>>>=20 >>>> - paragraph 2: the suggested way of supporting assymetric keys >>>> looks like a hack, I would suggest a more explicit >>>> representation, e.g. using a choice. >>>=20 >>> I hate to add multiple ways to do the same thing - especially when = the >>> more general specification has been in use for 15-20 years. >>=20 >> It is up to you to decide, I just find it cleaner to say explicitly = that >> a key is not to be used for sending rather than make the = send-lifetime >> interval empty. >=20 > Maybe I=E2=80=99ve just worked with key-chains too long but this seems = intuitive > enough to me.=20 >=20 > There is also an indication in the operational state whether a key is > active for sending or acceptance. OK. Lada >=20 > Thanks, > Acee=20 >=20 >=20 >>=20 >> But I know from another context (DNS) that admins are often fond of >> peculiar hacks they have been using for ages, and reluctant to = abandon >> them even if the new solution is arguably better. >>=20 >> Thanks, Lada >>=20 >> --=20 >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Feb 16 09:39:47 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AC61294B9; Thu, 16 Feb 2017 09:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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=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 OfN0DL1MOzyN; Thu, 16 Feb 2017 09:39:41 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 E31DC126CD8; Thu, 16 Feb 2017 09:31:20 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id c85so4216517wmi.1; Thu, 16 Feb 2017 09:31:20 -0800 (PST) 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; bh=Aib3hKc6Uhk97EWtOzeFPeRXsD+yzjO1QTZMc+JgRYY=; b=hlv1APfw37kDsLeZkxWUV6YsxtFp/wqXtb6JihwJcs8oFtDNL6Afiss7le6ZwO1V/2 9YjIXTsUEH4JEI9MxxJqUSIf7XvtPIGy7gA+5x9isvL5z8i0XVe8h2i6I1eB19bOpoyG cj5OJNLU1PqyE7du22KTj3IdDHJxBjSn993pDnbI/Ge55ZMYHkU4Q5tovcRLsyfVxRgG I8QDJygPdZtRmhRuVMfaHa+2mpcLU8evmQfVMNKwt+0m0EutXO4odPS1Di1HvURUJBVX hJXKM+bQIMcz34wu83lDVl1VR+3MpxyUwtLxmGspAhZodF8ivdStCHiiDcP3MUkbJbXK mP7A== 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; bh=Aib3hKc6Uhk97EWtOzeFPeRXsD+yzjO1QTZMc+JgRYY=; b=K9MzTEMSsmn/1g3CXXuglbM88i21szXaQPAvdvHreuXJN0+IBfGSSmCMQaNuFvI/Md ga3+CdYt1smBUqB/wAEeqB3Lq3LKWMWsLiMagCVVKPf7LQRUNd4QIFvuSO195s8nAkiZ ZQTZq4PogPl1lUS/e5vh0w9SYNrgV1X1wiIW5MnaBp0w+8yNu4TYPaFx9trsNOKI9uCy ymYAmMuoUnCFGcGNz2bRMb5Hwo0a0ov+w4T1vLE+AaSj29sHyI+1H/ZQ6IPD+Wy2LoZs Btf/8eXn26B27IXdhr+N+pYLLwb/RFiHOLW9kTsfnKFeRt2LiuCxiz4NGKV4gzP+2+7B bpMQ== X-Gm-Message-State: AMke39n/mvawvMqln/6xqhlR6Ydzly6xLXRuGjwDqwAkhY5+A1Tb6slsGjuFzsveFtUAfw== X-Received: by 10.28.229.73 with SMTP id c70mr12718837wmh.82.1487266279160; Thu, 16 Feb 2017 09:31:19 -0800 (PST) Received: from [10.229.80.248] ([94.116.89.192]) by smtp.gmail.com with ESMTPSA id x69sm1074509wma.15.2017.02.16.09.31.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 09:31:18 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Thu, 16 Feb 2017 09:31:15 -0800 From: Jeff Tantsura To: RTGWG Message-ID: Thread-Topic: Last Call for draft-ietf-rtgwg-yang-key-chain References: <0FC4166F-3CB3-4344-95C1-145CCEA1F467@gmail.com> In-Reply-To: <0FC4166F-3CB3-4344-95C1-145CCEA1F467@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3570082277_2089629765" Archived-At: Cc: "yang-doctors@ietf.org" , rtgwg-chairs , draft-ietf-rtgwg-yang-key-chain@ietf.org Subject: Re: [yang-doctors] Last Call for draft-ietf-rtgwg-yang-key-chain X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 17:39:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3570082277_2089629765 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear RTGWG, =20 This concludes the WGLC for draft-ietf-rtgwg-yang-key-chain. I=E2=80=99d like to thanks Yang-doctors for their thoughtful reviews and the auth= ors for timely (pretty much immediate!) responses and updated draft!=20 =20 I=E2=80=99ll be done with the shepherd review in a day and will send the draft to= the IESG for publication. =20 Cheers, Jeff =20 =20 From: Jeff Tantsura Date: Monday, February 6, 2017 at 10:35 To: RTGWG Cc: rtgwg-chairs , Subject: Re: Last Call for draft-ietf-rtgwg-yang-key-chain=20 =20 Dear RTGWG, =20 There have been significant changes to the draft-ietf-rtgwg-yang-key-chain = draft. We would like the wg to review the updated draft and hence start another, 1= week long WGLC. =20 Please indicate support/ no-support by February 13, 2017. =20 Thanks, Jeff & Chris =20 From: Jeff Tantsura Date: Friday, September 9, 2016 at 16:11 To: RTGWG Cc: rtgwg-chairs , Subject: Last Call for draft-ietf-rtgwg-yang-key-chain=20 =20 Dear RTGWG, =20 The authors have requested the RTGWG to last call draft-ietf-rtgwg-yang-key= -chain=20 =20 =20 There was consensus that document is ready for the last call during the las= t IETF meeting and the authors have addressed all the comments from Director= ate QA review. Please indicate support or no-support by September 23rd, 2016.=20 =20 =20 IPR: If you are listed as a document author or contributor, please respond to th= is email. of whether or not you are aware of any relevant IPR. The response needs to = be sent to the RTGWG mailing list.=20 The document will not advance to the next stage until a response has been r= eceived from each author and each=20 individual that has contributed to the document. =20 =20 Thanks, Jeff & Chris --B_3570082277_2089629765 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear RTGWG,

 

This concludes the WGLC for draft-ietf-rtgwg-yang-key-chain.

I’= d like to thanks Yang-doctors for their thoughtful reviews and the authors f= or timely (pretty much immediate!) responses and updated draft! <= /span>

 

I’ll be = done with the shepherd review in a day and will send the draft to the IESG f= or publication.

 

<= span style=3D'font-size:10.5pt;color:black'>Cheers,

Jeff

 

 =

From:= Jeff Tantsura <jefftant.ietf@gmail.= com>
Date: Monday, February 6, 2017 at 10:35
To: RTGW= G <rtgwg@ietf.org>
Cc: rtgwg-chairs <rtgwg-chairs@ietf.or= g>, <draft-ietf-rtgwg-yang-key-chain@ietf.org>
Subject: R= e: Last Call for draft-ietf-rtgwg-yang-key-chain

&n= bsp;

Dear RTGWG,

 

There have been significant changes to the draft-ietf-rtgwg-yang-k= ey-chain draft.

We would like the wg to review the updated draft and hence start = another, 1 week long WGLC.

 

Please indicate support/ no-support by F= ebruary 13, 2017.

 

Thanks,

Jeff & Chris

<= span style=3D'font-size:11.0pt'> 

From: Jeff Tantsura <jefftant.ietf@gmail.com>
Date: Friday, Sep= tember 9, 2016 at 16:11
To: RTGWG <rtgwg@ietf.org>
Cc:= rtgwg-chairs <rtgwg-chairs@ietf.org>, <draft-ietf-rtgwg-yang-k= ey-chain@ietf.org>
Subject: Last Call for draft-ietf-rtgwg-yang= -key-chain

 

Dear RTGWG,

 

The authors have requested t= he RTGWG to last call draft-ietf-rtgwg-yang-key-chain

=

 

 =

There was consensus th= at document is ready for the last call during the last IETF meeting and the = authors have addressed all the comments from Directorate QA review.

Please indica= te support or no-support by September 23rd, 2016.

 

 

=

IPR:

=

If you are listed as a doc= ument author or contributor, please respond to this email.=

of whether or not you = are aware of any relevant IPR. The response needs to be sent to the RTGWG ma= iling list.

The document will not advance to the next stage until a response has= been received from each author and each

individual that has contributed to the = document.

 

 

Thanks,

Jeff & Chris

--B_3570082277_2089629765-- From nobody Thu Feb 16 12:42:58 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5595129A62 for ; Wed, 15 Feb 2017 08:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.777 X-Spam-Level: X-Spam-Status: No, score=-3.777 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=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 efTd3OxFn5HX for ; Wed, 15 Feb 2017 08:33:39 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0070.outbound.protection.outlook.com [104.47.36.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217B9129AE1 for ; Wed, 15 Feb 2017 08:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h6gUZZ21kpXoWSvzAKj8cYbM5CFlvlytBlK1bWZMOEY=; b=fj/G2suEkMiRzIX9bZ+nK6T6/So8ULxNN2xPc0Hutmi99XM36jLcq2+SHKjnoPMpMWoDbGlDgYRzNol/whq9AX1zxMmKJmZ5daz2PngvY0F2HkEq+fN2cF8kDFSZ0PQfzoMoGjgQltXuUNP/Ma8JOgxSjAHgM5TvicH1uAXW7VA= Received: from CO2PR04MB746.namprd04.prod.outlook.com (10.141.228.144) by CO2PR04MB745.namprd04.prod.outlook.com (10.141.228.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 16:33:36 +0000 Received: from CO2PR04MB746.namprd04.prod.outlook.com ([10.141.228.144]) by CO2PR04MB746.namprd04.prod.outlook.com ([10.141.228.144]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 16:33:36 +0000 From: "Holness, Marc" To: Benoit Claise , Juergen Schoenwaelder , Janos Farkas Thread-Topic: IEEE YANG module validation and YANG doctor review Thread-Index: AQHSh20dAJgG5ohDdkCfRRRN9j0/YaFqQSgw Date: Wed, 15 Feb 2017 16:33:36 +0000 Message-ID: References: <7d4dc69f-ed12-26e7-8d9d-0753615f45f7@ericsson.com> <20170214102048.GA12861@elstar.local> <3cfbc431-cb44-ceaa-9a1b-e25cb930daef@cisco.com> <14fe6515-a749-83cd-e5ff-4950e2f88448@cisco.com> In-Reply-To: <14fe6515-a749-83cd-e5ff-4950e2f88448@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mholness@ciena.com; x-originating-ip: [205.150.10.69] x-ms-office365-filtering-correlation-id: 46b10644-b625-450c-ba4b-08d455c063df x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR04MB745; x-microsoft-exchange-diagnostics: 1; CO2PR04MB745; 7:lJ0OHj+jW9VGu70Y3/tBtrUkpdSVzsfvUDjE++9ZVu5owpAm8D7HBkonA09kZW2EhOKSTigby7qpOTdb88j6dHY9PCEBbDAj+v5uwO1+9NwZwxbi7QXtItnjxeGF3l9hIQJ+8U4AdVwd+2KyZocMukak6K3b1e/eecKQU6yA0V6rkOD6WyeOrfsnHot1MsvZBPzGNDD4sxFBOhg3EZvslmIFUfW5UtJJpCB1tQC0mDHjKqXQ77XHoEN01F0DZbj8Wr2rf/6lgIYFzGZCe7g86yijhKPZe4MDfYcVY6q2fQxtmbtHl5z9JwYjNj9JD5xvi3lMjDMiCKhSgXjZx8Q9yZxx74Dsbn5vQKO0wK9lFN1oJUtwQd3XKewFuuYF8mSOG6tcDfWi/MRvDaFQi/kGHL2loMjbzucBnrJOfdZX5kF+wDxTpYM/Gi4yvZEI/NL31fC37VcR1OUhJlrPzV7ZZtQ0UoHQ/Lc8bd3Q0kYsoHlRSUVEU77JSIaAXEXzynglVvsxO5UgbAxjNuZoRkH04A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(95692535739014)(21748063052155)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CO2PR04MB745; BCL:0; PCL:0; RULEID:; SRVR:CO2PR04MB745; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(24454002)(43234003)(189002)(377454003)(189998001)(3660700001)(3280700002)(77096006)(6436002)(6116002)(236005)(99286003)(102836003)(3846002)(606005)(790700001)(7696004)(86362001)(575784001)(81166006)(25786008)(389900002)(53546003)(6506006)(92566002)(6306002)(2950100002)(68736007)(8936002)(9686003)(38730400002)(54896002)(54906002)(53936002)(81156014)(53946003)(76176999)(966004)(54356999)(5890100001)(101416001)(66066001)(229853002)(7906003)(33656002)(105586002)(106116001)(122556002)(6246003)(7736002)(106356001)(97736004)(4326007)(8676002)(2906002)(7416002)(50986999)(2900100001)(39060400002)(74316002)(5660300001)(55016002)(93886004)(217873001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR04MB745; H:CO2PR04MB746.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR04MB7469B9550C48C48F0F1415AD85B0CO2PR04MB746namprd_" MIME-Version: 1.0 X-OriginatorOrg: ciena.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 16:33:36.1427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB745 Archived-At: X-Mailman-Approved-At: Thu, 16 Feb 2017 12:42:52 -0800 Cc: John Messenger , YANG Doctors , Dan Romascanu Subject: Re: [yang-doctors] IEEE YANG module validation and YANG doctor review X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 16:33:53 -0000 --_000_CO2PR04MB7469B9550C48C48F0F1415AD85B0CO2PR04MB746namprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Benoit. It seems all the warnings are the same. Based upon the guidance provided in= the thread below, it seems I should change all occurrences of the form ... augment "/if:interfaces/if:interface" { when "/if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } ... to something like what is shown below. augment "/if:interfaces/if:interface" { when "/if:interfaces/if:interface/if:type =3D 'ianaif:ieee8023adLag' or /if:interfaces/if:interface/if:type =3D 'ianaif:ethernetCsm= acd' or /if:interfaces/if:interface/if:type =3D 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } Is this correct? BTW ... The examples shown in RFC6020, section 7.15.3 "Usage Example" and R= FC 7950, section 7.17.3 "Usage Example" seems to be misleading. Am I misint= erpreting things? import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType=3D'ds0'"; leaf ds0ChannelNumber { type ChannelNumber; } } Regards, Marc. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Wednesday, February 15, 2017 4:22 AM To: Holness, Marc ; Juergen Schoenwaelder ; Janos Farkas Cc: Dan Romascanu ; Mehmet ; Martin B= jorklund ; Andy Bierman ; rkrejci@cesne= t.cz; John Messenger ; YANG Doctors Subject: Re: IEEE YANG module validation and YANG doctor review Thanks Mark, [copying the YANG doctors as it might be of general interest] I basically investigated the first YANG module at http://www.claise.be/IEEE= StandardYANGPageCompilation.html >From the page first line, you can see where those YANG modules come from: h= ttps://github.com/YangModels/yang/tree/master/standard/ieee Note that I also compile http://www.claise.be/IEEEExperimentalYANGPageCompi= lation.html All info at http://www.claise.be/2016/07/ietf-yang-modules-statistiques/ IEEE (updated daily) * All YANG data modules for PAR-related projects, with compilation errors * All YANG data modules for non PAR-related projects, with compilation errors And at http://www.claise.be/YANGPageMain.html * IEEEStandard YANG MODELS * Number of YANG data models from IEEEStandard that passed compilation:= 2/8 * Number of YANG data models from IEEEStandard that passed compilation = with warnings: 0/8 * Number of YANG data models from IEEEStandard that failed compilation:= 6/8 * Generated on 15/02/2017 by Benoit Claise * IEEEExperimental YANG MODELS * Number of YANG data models from IEEEExperimental that passed compilat= ion: 1/5 * Number of YANG data models from IEEEExperimental that passed compilat= ion with warnings: 0/5 * Number of YANG data models from IEEEExperimental that failed compilat= ion: 4/5 * Generated on 15/02/2017 by Benoit Claise regarding the specific modules mentioned below: ieee802-types.yang =3D> PASSED ieee802-dot1q-types.yang =3D> PASSED ieee802-dot1q-bridge.yang =3D> FAILED ieee802-dot1q-tpmr.yang =3D> FAILED ieee802-dot1q-vlan-bridge.yang =3D> FAILED ieee802-dot1q-pb.yang =3D> FAILED Ieee802-dot1x.yang =3D> FAILED I understand that you ask the YANG doctors to review the following YANG mod= ules These ones are part of the P802.1Qcp project: +--> standard | +--> 802.1 | | +--> draft | | +--> ieee-dot1q-bridge.yang | | +--> ieee-dot1q-pb.yang | | +--> ieee-dot1q-tpmr.yang | | +--> ieee-dot1q-types.yang | | +--> ieee-dot1q-vlan-bridge.yang This is the P802.1Xck project: +--> standard | +--> 802.1 | | +--> draft | | +--> ieee-dot1x.yang It makes sense to resolve the validation errors before J=FCrgen starts his = YANG doctor review. The best way is to post the new YANG modules in github. From there, I'll ru= n my scripts. Regards, Benoit Hi Benoit and all, Thanks for this. I would like to provide a bit of clarity on the YANG modu= les that are a part of the current IEEE 802.1 YANG active projects (i.e., 8= 02.1Qcp and 802.1Xck). General IEEE 802 Types ieee802-types.yang - Generic IEEE 802 type definitions IEEE 802.1 Types ieee802-dot1q-types.yang - IEEE 802.1 type specific definitions IEEE 802.1Qcp (Bridges and Bridged Networks - Amendment: YANG Data Model) ieee802-dot1q-bridge.yang - Main IEEE 802.1Q bridging YANG modules which is= augmented by specific bridge models. The general structure is shown below. ieee802-dot1q-tpmr.yang - Two Port MAC Relay Bridge YANG module ieee802-dot1q-vlan-bridge.yang - Customer VLAN Bridge YANG module ieee802-dot1q-pb.yang - Provider Bridge YANG module IEEE 802.1Xck (Port-Based Network Access Control - Amendment 2: YANG Data M= odel) Ieee802-dot1x.yang - IEEE 802.1X (Port-based network access control) YANG m= odule The ieee802-dot1ax.yang module is not currently in scope. That being said h= owever, yes, I do need to make the changes to this module over time. It is = still very draft, and not ready for "prime time" yet. Regards, Marc. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, February 14, 2017 6:43 AM To: Juergen Schoenwaelder ; Janos Farkas Cc: Dan Romascanu ; Mehmet <= mersue@gmail.com>; Holness, Marc ; Martin Bjorklund ; Andy Bierman = ; rkrejci@cesnet.cz; Benoit Claise ; John Messenger Subject: IEEE YANG module validation and YANG doctor review (was: Re: [802.= 1 - 12074] Working Group ballot of P802.1Qcp/D1.0 - Bridges and Bridged Net= works - Amendment: YANG Data Model Dear all, http://www.claise.be/IEEEStandardYANGPageCompilation.html is now fixed. I looked at the first YANG module: ieee802-dot1ax.yang, which fails validat= ion for 3 validators out of 4. Pyang is the exception, but pyang doesn't ha= ve a xpath validation for now. For example, in yangdump-pro, it shows: *** Generated by yangdump-pro 16.10-4 *** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved. *** Copyright (c) 2012-2017, YumaWorks, Inc., All Rights Reserved. Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:87.11: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:87.47: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:87.84: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:187.11: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:187.47: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:187.84: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:529.11: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:529.48: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:757.11: warning(1032): no child node available Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot' XPath: /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge' ieee802-dot1ax.yang:757.48: warning(1032): no child node available Warning: Module 'iana-if-type' not used ieee802-dot1ax.yang:9.3: warning(1015): import not used *** *** 0 Errors, 11 Warnings The issue is (mutltiple times the same issue btw). OLD: augment "/if:interfaces/if:interface" { when "/if:type =3D 'ianaif:ieee8023adLag' or /if:type =3D 'ianaif:ethernetCsmacd' or /if:type =3D 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } NEW: augment "/if:interfaces/if:interface" { when "/if:interfaces/if:interface/if:type =3D 'ianaif:ieee8023adLag' or /if:interfaces/if:interface/if:type =3D 'ianaif:ethernetCsmacd' o= r /if:interfaces/if:interface/if:type =3D 'ianaif:bridge'" { description "Applies to Ethernet interfaces or Bridge Ports."; } I'll surely stand corrected by the YANG doctors if this is not the issue. Attached is a working copy of the YANG model, which passes yangdumpro and c= onfdc. There is a warning with yanglint (Radek is copied). yanglint -V -p /home/bclaise/yang/modules/ ieee802-dot1ax.yang warn: Schema node "ietf-interfaces:interfaces-state" not found (/ietf-inter= faces:interfaces-state). warn: Resolving when condition "/ietf-interfaces:interfaces-state/ietf-inte= rfaces:interface/ietf-interfaces:type =3D 'iana-if-type:ethernetCsmacd' or /ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces= :type =3D 'iana-if-type:bridge'" failed. (/ieee802-dot1ax:/ietf-interfaces:= interfaces/ietf-interfaces:interface) As J=FCrgenmentioned, I propose that IEEE fixes the errors/warnings seen at= http://www.claise.be/IEEEStandardYANGPageCompilation.html before we procee= d with the YANG doctor review. A very quick look through the rest of the errors tends to show the same err= or type. Regards, Benoit On 2/14/2017 11:29 AM, Benoit Claise wrote: On 2/14/2017 11:20 AM, Juergen Schoenwaelder wrote: On Tue, Feb 14, 2017 at 09:54:31AM +0000, Janos Farkas wrote: ps: This is the P802.1Xck project: +--> standard | +--> 802.1 | | +--> draft | | +--> ieee-dot1x.yang The P802.1Xck WG ballot closes tomorrow. So what does that ballot closing event tell me? Where exactly do I find the YANG modules that have been used in the .pdf file? By when do you need a review? Did Benoit run his tools on the correct documents or not? Janos, http://www.claise.be/IEEEStandardYANGPageCompilation.html Note that I made some changes this morning and screwed up a few things. That leads to some compilation issues. Let me solve this first. Regards, B. Regards, Benoit If so, perhaps it makes sense to fix the compilation issues before I do my review, no? /js . --_000_CO2PR04MB7469B9550C48C48F0F1415AD85B0CO2PR04MB746namprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Thanks Benoit.

 

It seems all the warnings are the = same. Based upon the guidance provided in the thread below, it seems I shou= ld change all occurrences of the form …

 

augment "/if:interfaces/if:in= terface" {

    when "/if:= type =3D 'ianaif:ieee8023adLag' or

     &nbs= p;           /if:type =3D= 'ianaif:ethernetCsmacd' or

     &nbs= p;           /if:type =3D= 'ianaif:bridge'" {

      des= cription

     &nbs= p;  "Applies to Ethernet interfaces or Bridge Ports.";<= /o:p>

      }

 

… to something like what is = shown below.

 

  augment "/if:interface= s/if:interface" {

    when "/if:= interfaces/if:interface/if:type =3D 'ianaif:ieee8023adLag' or

     &nbs= p;          /if:interfaces/if:= interface/if:type =3D 'ianaif:ethernetCsmacd' or

     &nbs= p;          /if:interfaces/if:= interface/if:type =3D 'ianaif:bridge'" {

      des= cription

     &nbs= p;  "Applies to Ethernet interfaces or Bridge Ports.";<= /o:p>

      }

 

Is this correct?

 

BTW … The examples shown in = RFC6020, section 7.15.3 “Usage Example” and RFC 7950, section 7= .17.3 “Usage Example” seems to be misleading. Am I misinterpret= ing things?

 

import interface-module {

  prefix "if";=

}

 

augment "/if:interfaces/if:if= Entry" {

  when "if:ifType=3DR= 17;ds0’";

    leaf ds0Channel= Number {

      typ= e ChannelNumber;

    }

}

 

Regards,

 

Marc.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Wednesday, February 15, 2017 4:22 AM
To: Holness, Marc <mholness@ciena.com>; Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Janos Farkas <Janos.Farkas= @ericsson.com>
Cc: Dan Romascanu <dromasca@gmail.com>; Mehmet <mersue@gmai= l.com>; Martin Bjorklund <mbj@tail-f.com>; Andy Bierman <andy@y= umaworks.com>; rkrejci@cesnet.cz; John Messenger <jmessenger@advaopti= cal.com>; YANG Doctors <yang-doctors@ietf.org>
Subject: Re: IEEE YANG module validation and YANG doctor review=

 

Thanks Mark,

[copying the YANG doctors as it might be of general interest]

I basically investigated the first YANG module at http://www.claise.be/IEEEStandardYANGPageCompilation.html
>From the page first line, you can see where those YANG modules come from: <= a href=3D"https://github.com/YangModels/yang/tree/master/standard/ieee"> https://github.com/YangModels/yang/tree/master/standard/ieee
Note that I also compile http://www.claise.be/IEEEExperimentalYANGPageCompilation.html

All info at http://www.claise.be/2016/07/ietf-yang-modules-statistiques/

IEEE (updated daily)


And at http://www.claise= .be/YANGPageMain.html
   

  • IEEEStandard YANG MODELS
  • Number of YANG data models from IEEEStandard that passed compilation: 2/8 <= o:p>
  • Number of YANG data models from IEEEStandard that passed compilation with w= arnings: 0/8
  • Number of YANG data models from IEEEStandard that failed compilation: 6/8 <= o:p>
  • Generated on 15/02/2017 by Benoit Claise
  • IEEEExperimental YANG MODELS
  • Number of YANG data models from IEEEExperimental that passed compilation: 1= /5
  • Number of YANG data models from IEEEExperimental that passed compilation wi= th warnings: 0/5
  • Number of YANG data models from IEEEExperimental that failed compilation: 4= /5
  • Generated on 15/02/2017 by Benoit Claise

 
regarding the specific modules mentioned below:
    ieee802-types.yang =3D> PASSED
    ieee802-dot1q-types.yang =3D> PASSED
    ieee802-dot1q-bridge.yang =3D> FAILED
    ieee802-dot1q-tpmr.yang =3D> FAILED
    ieee802-dot1q-vlan-bridge.yang =3D> FAILED
    ieee802-dot1q-pb.yang =3D> FAILED
    Ieee802-dot1x.yang =3D> FAILED


I understand that you ask the YANG doctors to review the following YANG mod= ules
    These ones are part of the P802.1Qcp project:

     +--> standard

     |    +--> 802.1

     |    |     &= #43;--> draft

     |    |    &n= bsp;     +--> ieee-dot1q-bridge.yang=

     |    |    &n= bsp;     +--> ieee-dot1q-pb.yang

     |    |    &n= bsp;     +--> ieee-dot1q-tpmr.yang

     |    |    &n= bsp;     +--> ieee-dot1q-types.yang<= /o:p>

     |    |    &n= bsp;     +--> ieee-dot1q-vlan-bridge.yang=

    
  This is the P802.1Xck project:

     +--> standard

     |    +--> 802.1

     |    |     &= #43;--> draft

     |    |  =         +--> ieee-dot1x.yang

 

 

It makes sense to resolve the validation errors befo= re J=FCrgen starts his YANG doctor review.
The best way is to post the new YANG modules in github. From there, I'll ru= n my scripts.

Regards, Benoit

 

Hi Benoit and all,

 

Thanks for this. I would like to  provide a bi= t of clarity on the YANG modules that are a part of the current IEEE 802.1 = YANG active projects (i.e., 802.1Qcp and 802.1Xck).

 

General IEEE 802 Types

 

ieee802-types.yang  - Generic I= EEE 802 type definitions

 

IEEE 802.1 Types

 

ieee802-dot1q-types.yang - IEEE 80= 2.1 type specific definitions

 

IEEE 802.1Qcp (Bridges and Bridged Networks R= 11; Amendment: YANG Data Model)

 

ieee802-dot1q-bridge.yang - Main IE= EE 802.1Q bridging YANG modules which is augmented by specific bridge models. The general structure is shown below.

 

ieee802-dot1q-tpmr.yang - Two Port M= AC Relay Bridge YANG module

ieee802-dot1q-vlan-bridge.yang - Cus= tomer VLAN Bridge YANG module

ieee802-dot1q-pb.yang  - Provid= er Bridge YANG module

 

IEEE 802.1Xck (Port-Based Network Access Control= - Amendment 2: YANG Data Model)

 

Ieee802-dot1x.yang - IEEE 802.1X (Po= rt-based network access control) YANG module

 

 

 

The ieee802-dot1ax.yang module is not currently in scope. That be= ing said however, yes, I do need to make the changes to this module over ti= me. It is still very draft, and not ready for “prime time” yet.=

 

Regards,

 

Marc.

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, February 14, 2017 6:43 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Janos Farkas <Janos.Farkas@ericsson.com>
Cc: Dan Romascanu <dromasca= @gmail.com>; Mehmet <mersue@gmail.com>; Holness, = Marc <mholness@ciena.com>; Martin Bjorklund <mbj@tail-f.com>; Andy Bierman <andy@yumaworks.com>; rkrejci@cesnet.cz; Benoit Claise &= lt;bclaise@cisco.com>; John Messenger <jmessenger@advaoptical.co= m>
Subject: IEEE YANG module validation and YANG doctor review (was: Re= : [802.1 - 12074] Working Group ballot of P802.1Qcp/D1.0 - Bridges and Brid= ged Networks — Amendment: YANG Data Model

 

Dear all,

http:= //www.claise.be/IEEEStandardYANGPageCompilation.html  is now fixed= .

I looked at the first YANG module: ieee802-dot1ax.yang, which fails validat= ion for 3 validators out of 4. Pyang is the exception, but pyang doesn't ha= ve a xpath validation for now.

For example, in yangdump-pro, it shows:

*** Generated by yangdump-pro 16.10-4
*** Copyright (c) 2008-2012, Andy Bierman, All Rights Reserved.
*** Copyright (c) 2012-2017, YumaWorks, Inc., All Rights Reserved.

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:87.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:87.47: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:87.84: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:187.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:187.47: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ieee8023adLag' or
/if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:187.84: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:529.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:529.48: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:757.11: warning(1032): no child node available

Warning: no child node 'ietf-interfaces:type' found for parent 'yuma-ncx:ro= ot'
XPath: /if:type =3D 'ianaif:ethernetCsmacd' or
/if:type =3D 'ianaif:bridge'
ieee802-dot1ax.yang:757.48: warning(1032): no child node available

Warning: Module 'iana-if-type' not used
ieee802-dot1ax.yang:9.3: warning(1015): import not used

***
*** 0 Errors, 11 Warnings

The issue is (mutltiple times the same issue btw). OLD:
  augment "/if:interfaces/if:interface" {
    when "/if:type =3D 'ianaif:ieee8023adLag' or
          /if:type =3D 'ianaif= :ethernetCsmacd' or
          /if:type =3D 'ianaif= :bridge'" {
      description
        "Applies to Ethernet interf= aces or Bridge Ports.";
      }

NEW:
  augment "/if:interfaces/if:interface" {
    when "/if:interfaces/if:interface/if:type =3D 'iana= if:ieee8023adLag' or
          /if:interfaces/if:in= terface/if:type =3D 'ianaif:ethernetCsmacd' or
          /if:interfaces/if:in= terface/if:type =3D 'ianaif:bridge'" {
      description
        "Applies to Ethernet interf= aces or Bridge Ports.";
      }

I'll surely stand corrected by the YANG doctors if this is not the issue.
Attached is a working copy of the YANG model, which passes yangdumpro and c= onfdc.
There is a warning with yanglint (Radek is copied).

yanglint -V -p /home/bclaise/yang/modules/ ieee802-dot1ax.yang
warn: Schema node "ietf-interfaces:interfaces-state" not found (/= ietf-interfaces:interfaces-state).
warn: Resolving when condition "/ietf-interfaces:interfaces-state/ietf= -interfaces:interface/ietf-interfaces:type =3D 'iana-if-type:ethernetCsmacd= ' or
/ietf-interfaces:interfaces-state/ietf-interfaces:interface/ietf-interfaces= :type =3D 'iana-if-type:bridge'" failed. (/ieee802-dot1ax:/ietf-interf= aces:interfaces/ietf-interfaces:interface)

As J=FCrgenmentioned, I propose that IEEE fixes the errors/warnings seen at= http://www.claise.be/IEEEStandardYANGPageCompilation.html before we pro= ceed with the YANG doctor review.
A very quick look through the rest of the errors tends to show the same err= or type.

Regards, Benoit

On 2/14/2017 11:29 AM, Benoit Claise wrote:

On 2/14/2017 11:20 AM, Juergen Schoenwaelder wrote: =

On Tue, Feb 14, 2017 at 09:54:31AM +0000, Janos = Farkas wrote:

ps:
This is the P802.1Xck project:
      +--> standard
      |    +--> 802.1
      |    |    = ; +--> draft
      |    |    = ;      +--> ieee-dot1x.yang


The P802.1Xck WG ballot closes tomorrow.

So what does that ballot closing event tell me? Wher= e exactly do I
find the YANG modules that have been used in the .pdf file? By when do
you need a review? Did Benoit run his tools on the correct documents
or not?

Note that I made some changes this morning and screw= ed up a few things.
That leads to some compilation issues.
Let me solve this first.

Regards, B.


Regards, Benoit

If so, perhaps it makes sense to fix the compilation= issues
before I do my review, no?

/js

 


.

 

 

 

--_000_CO2PR04MB7469B9550C48C48F0F1415AD85B0CO2PR04MB746namprd_-- From nobody Sun Feb 19 11:37:50 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C202E129480 for ; Sun, 19 Feb 2017 11:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 geDddJwPJG_5 for ; Sun, 19 Feb 2017 11:37:47 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 DFF86129454 for ; Sun, 19 Feb 2017 11:37:46 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id s27so6774466wrb.2 for ; Sun, 19 Feb 2017 11:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language:disposition-notification-to; bh=wr9S4dtSHR68O+RiVM0Gv7WOQTxcvdWWjYo2N6kC5tA=; b=W+4v++MPRK3ZHeMS5c/0WdliDymKk896RKyl3I1q29Ek5iMFiLEnHNybN8QtFXvIs4 4N0AOCnI69iNs3YIvs4fkf27nn+2AzK9XcIECXnjQzL/u6hzKSUbiyVvz/eSdJDZVnSx YNMSjNgWQn27ijR9nugWViDoOGmQVThlIuT/reQcNnp3d2R9grMc1NFx5OUQn5beAkSy zRhBPoEWJn6aPbIldX7xeYdt+ZH5+UNmJYMwA8U52bG8yh9FTq2nR19vv0SSYUrnir8V 4YgfUhgLWxetdQ0j1bdpWIfOw/eY1RGBZq7FVHY/PvjDYQuG9xaZIup8ujjmSsNB6HZn +b2g== 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:subject:date:message-id:mime-version :thread-index:content-language:disposition-notification-to; bh=wr9S4dtSHR68O+RiVM0Gv7WOQTxcvdWWjYo2N6kC5tA=; b=EjHmY8jpQbdbn5jSNo0R/qsRGVMmRO4jBg5EyLTljVFL7aD6c0LAZuIZ7eVecYQBG0 yzlwnTXoq+7cpGLCD89ckOYnYoQuwxT7o4lmtL7gBfA11fL3BZgcqpFPuqnnTYsVJHF8 JDqOQvGA7pZjM/MlksO8dXv9SpsUsH9BExAtgYlDaN3ii12jgKn/CyQaHDmkVEexTfpb u08KTAl5gC+t0Tor+03gKtJT+azucZKKYpDnPDzygkOujNKfTUjBElwtorXKlOtv93bZ d9gGiNIDPPhBvHvpRhPtTyvc6YJJppnRbvEUaa4AYxUPyGkYGToFR6EmqPPLotX/jszn 6kyQ== X-Gm-Message-State: AMke39nX6JwLYzeLn8hXgwnjvH9oaveqnFRJUJ/0rTti8VpbfzjiE4tVvD/beWn3yyDsgw== X-Received: by 10.223.129.196 with SMTP id 62mr13859120wra.43.1487533065237; Sun, 19 Feb 2017 11:37:45 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B34102C.dip0.t-ipconnect.de. [91.52.16.44]) by smtp.gmail.com with ESMTPSA id z134sm10576978wmc.20.2017.02.19.11.37.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Feb 2017 11:37:44 -0800 (PST) From: "Mehmet Ersue" To: Date: Sun, 19 Feb 2017 20:37:43 +0100 Message-ID: <02e901d28ae7$a50ce590$ef26b0b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EA_01D28AF0.06D4D000" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKK5OxBnIZhTSGdTzGSR0duQdYVOg== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0205.58A9F408.0049,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Gunter Van De Velde' , 'Dan Romascanu' , 'Robert Sparks' Subject: [yang-doctors] Introducing the new Datatracker Review Tracking tool for YANG Module Reviews X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 19:37:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EA_01D28AF0.06D4D000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear YANG Doctors, as discussed with Benoit this mail is to introduce the new datatracker review tracking tool for YANG module reviews. The updated entry page for YANG Doctors team is at: https://www.ietf.org/iesg/directorate/yang-doctors.html The entry page of the YANG review tracking tool is at: https://datatracker.ietf.org/dir/yangdoctors/about/ Some of you know the review tracking tool already from OPS-DIR reviews. The usual process for YANG Doctor's reviews using the new datatracker tool is summarized below. A) ADs, WG chairs or draft authors request the review of a YANG module on Datatracker. - Sign in on Datatracker: https://datatracker.ietf.org/accounts/login/?next=/ - Go to the draft page (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ - Click on the button "Review request" which brings you to (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/reviewreques t/ - Choose the type of review (Early, LC, Telechat) and set a recommended deadline - If required propose a reviewer in comments. B) YANG secretary assigns the requested review to a reviewer. - Datatracker generates an email to the reviewer indicating the draft with the YANG module and the review deadline. - All assigned open review requests and closed review requests can be always listed at: https://datatracker.ietf.org/group/yangdoctors/reviews/ Notes: - Datatracker proposes a reviewer using based on the round robin approach. - YANG doctors can enter their availability into their datatracker account profile to avoid wrong assignments. C) The reviewer enters the review result into the review tool. - The reviewer goes to the draft review request page at (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/reviewreques t/8317/ - Clicks on "Complete review" - Enters state, reviewed revision, and the review result. - In case the reviewer enters the review result directly into the tool or uploads a text file, the tool generates an email to YANG Doctors maillist, draft authors and the related WG maillist. Z) YANG doctors secretary will send a weekly summary of requested and ongoing reviews to YANG doctors maillist. The first summary mail will be send out in parallel to this mail. Notes: - Old review assignments on the current review history page (https://trac.ietf.org/trac/ops/wiki/yang-doctors-review-history) will be migrated to the datatracker tool by the admin soon. The old page will be used for external review requests only. - The Wiki page for the YANG review process will be updated within a week based on the collected feedback. Thank you in advance for your suggestions and comments. Please let us know if you have any questions. Cheers, Mehmet (YANG Doctors Secretary) ------=_NextPart_000_02EA_01D28AF0.06D4D000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear YANG = Doctors,

 

as discussed with Benoit = this mail is to introduce the new datatracker review tracking tool for = YANG module reviews.

 

The updated entry page = for YANG Doctors team is at: https://= www.ietf.org/iesg/directorate/yang-doctors.html

=

The entry page of the = YANG review tracking tool is at: https://data= tracker.ietf.org/dir/yangdoctors/about/

 

Some of you know the = review tracking tool already from OPS-DIR reviews. =

The usual process for YANG Doctor’s = reviews using the new datatracker tool is summarized = below.

 

A) ADs, WG chairs or = draft authors request the review of a YANG module on = Datatracker.

   - Sign in on Datatracker: = https://datatracker.ietf.org/accounts/login/?next=3D/

   - Go = to the draft page (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ =

   - Click on the button = "Review request" which brings you to (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-= mount/reviewrequest/

   - = Choose the type of review (Early, LC, Telechat) and set a recommended = deadline

   - If required propose a reviewer in = comments.

 

B) YANG secretary = assigns the requested review to a reviewer.

   - = Datatracker generates an email to the reviewer indicating the draft with = the YANG module and the review deadline.

   - All = assigned open review requests and closed review requests can be always = listed at: https://= datatracker.ietf.org/group/yangdoctors/reviews/ =

 

   Notes: =

   - Datatracker proposes a = reviewer using based on the round robin = approach.

   - YANG doctors can enter their = availability into their datatracker account profile to avoid wrong = assignments.

 

C) The reviewer enters = the review result into the review tool.

   - The = reviewer goes to the draft review request page at (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-sy= slog-model/reviewrequest/8317/

   - = Clicks on "Complete review"

   - Enters = state, reviewed revision, and the review result.

   - In case = the reviewer enters the review result directly into the tool or uploads = a text file, the tool generates an email to YANG Doctors maillist, draft = authors and the related WG maillist.

 

Z) YANG doctors = secretary will send a weekly summary of requested and ongoing reviews to = YANG doctors maillist.

The first summary mail will be send out in = parallel to this mail.

 

Notes:

- Old review assignments = on the current review history page (= https://trac.ietf.org/trac/ops/wiki/yang-doctors-review-history) = will be migrated to the datatracker tool by the admin soon. The old page = will be used for external review requests only.

- The Wiki page for the = YANG review process will be updated within a week based on the collected = feedback.

 

Thank you in advance for = your suggestions and comments.

Please let us know if = you have any questions.

 

Cheers,

Mehmet

(YANG Doctors = Secretary)

 

------=_NextPart_000_02EA_01D28AF0.06D4D000-- From nobody Sun Feb 19 11:37:54 2017 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9614F129454; Sun, 19 Feb 2017 11:37:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mehmet Ersue" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148753306959.31278.17996988070433891942.idtracker@ietfa.amsl.com> Date: Sun, 19 Feb 2017 11:37:49 -0800 Archived-At: Subject: [yang-doctors] Open review assignments for YANG Doctors X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Reply-To: dromasca@gmail.com, mersue@gmail.com List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 19:37:49 -0000 The following reviewers have assignments: Last calls: Reviewer LC end Draft Kent Watsen 2017-02-27 draft-ietf-netmod-syslog-model-12 Early review requests: Reviewer Due Draft Ladislav Lhotka 2017-02-17 draft-ietf-rtgwg-yang-key-chain-13 Jan Lindblad 2017-03-03 draft-ietf-pim-igmp-mld-yang-01 Carl Moberg 2017-02-28 draft-ietf-lime-yang-connectionless-oam-03 Carl Moberg 2017-02-28 draft-ietf-lime-yang-connectionless-oam-methods-00 Carl Moberg 2017-02-28 draft-ietf-lime-yang-oam-model-08 Thomas Nadeau 2017-02-28 draft-ietf-netmod-intf-ext-yang-03 Balazs Lengyel 2017-02-28 draft-ietf-netconf-yang-push-04 Next in the reviewer rotation: Andy Bierman Martin Bjorklund Dean Bogdanovic Giles Heron Mahesh Jethanandani Radek Krejčí Balazs Lengyel Ladislav Lhotka Jan Lindblad From nobody Sun Feb 19 12:06:04 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D880112950B for ; Sun, 19 Feb 2017 12:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ffc_qV1d_UUa for ; Sun, 19 Feb 2017 12:06:01 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 6951F129415 for ; Sun, 19 Feb 2017 12:06:01 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id 35so13596413wrw.0 for ; Sun, 19 Feb 2017 12:06:01 -0800 (PST) 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=+IoJe63jd1tScBig/ORteuPnP/mlHIbfCFwnqaK3o74=; b=0AgnyKbg5DMiNDG3QJ7Sjd2kmpAujtJItlNp3HltUUYmEeNFvvDIRm9i4mwxb0ubyR 1/7R4lFynkL0b3dmSNFHeAhBLH/m6Ayyp7fkMh1oVXxKSN4W9szGx802ZKseKRnNwLu4 gksyAFS2MU4f0Vl8H7ld1rRS65en8Ylc2DEVOLfNl069f4mUitPeu/zINggAwaiK7esW WqEfD7J4e6OLlhJyxaRyp/GEbt+Z8jN4b4UPO5FuRGm/yITfhKk4W7jI+cdgWa42nMa3 0DKaY75IQblQ++HoV5GlGFwk7b2Sci76ASjJ8J0SJd8FEMz5vzViXXGChdk/SBJN4fLg Ja9w== 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=+IoJe63jd1tScBig/ORteuPnP/mlHIbfCFwnqaK3o74=; b=HS5P+8H5Uy/wM62qNo+c77ESQ4FsL36GMfYZu7SLAdXPOX0ctAXVPYdBFhRr48rc// WJwedaHmv+4/A/4oaPysOvKYBtb2LA0yQnpVyPL2DbQjpQCxjL1N892Um58HObiOxvPy G8D4RKx69yNuBCwju9Mn316T13kVvTuIG1lOVwf1lGxMw9vXPoeXYP6fH3Miyu4aAmcq walbpgjS+MyM6PrrMsvjY5xy6V7YQHkW5a34KSyczxQ/ZyxYgqnyT/bEgbWVEl+RDCcP m/rXXOTMhhpt3qevq1+EVzIczSyz3vyER1+97tAPlLvmFlt3PlOOAc+9rJl0ZEmbuR1z /bxg== X-Gm-Message-State: AMke39kEQ+UOThcDsXHMRp2Qf/92dKVmV/dKcTDjbaFrBnGGB+NxSfi1nsgQOBo+nO6FHlfDhecyp03u0oyakg== X-Received: by 10.223.151.138 with SMTP id s10mr12804095wrb.65.1487534759666; Sun, 19 Feb 2017 12:05:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Sun, 19 Feb 2017 12:05:58 -0800 (PST) From: Andy Bierman Date: Sun, 19 Feb 2017 12:05:58 -0800 Message-ID: To: YANG Doctors Content-Type: multipart/alternative; boundary=94eb2c1b5912f1005a0548e7ac2b Archived-At: Subject: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 20:06:03 -0000 --94eb2c1b5912f1005a0548e7ac2b Content-Type: text/plain; charset=UTF-8 Hi, The CORE WG is working on some standards for an IoT version of RESTCONF. The CBOR encoding is relevant to RESTCONF for some applications like YANG push. I am trying to organize a side meeting about YANG to CBOR and SID (numeric schema node identifiers). The goal of the meeting is understand how it works (and doesn't work). Hopefully there will be a 1 hour slot open for this meeting, and a room available. The first step is determining if any YANG doctors care about what the CORE WG is doing with YANG. Another topic: YANG to GPB? Better approach? Where is it documented? Does an algorithm exist that works for YANG augment? CORE WG drafts: YANG to CBOR https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ SID https://datatracker.ietf.org/doc/draft-ietf-core-sid/ CoMI https://datatracker.ietf.org/doc/draft-ietf-core-comi/ Andy --94eb2c1b5912f1005a0548e7ac2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The CORE WG is working on some stan= dards for an IoT version of RESTCONF.
The CBOR encoding is releva= nt to RESTCONF for some applications like YANG push.

I am trying to organize a side meeting about YANG to CBOR and
= SID (numeric schema node identifiers). The goal of the meeting is
understand how it works (and doesn't work).=C2=A0 Hopefully there will= be a
1 hour slot open for this meeting, and a room available.
The first step is determining if any YANG doctors care about what
the CORE WG is doing with YANG.

Another t= opic: YANG to GPB? Better approach? Where is it documented?
Does = an algorithm exist that works for YANG augment?

CO= RE WG drafts:

YANG to CBOR

SID


Andy

--94eb2c1b5912f1005a0548e7ac2b-- From nobody Sun Feb 19 23:06:04 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520B21298BC for ; Sun, 19 Feb 2017 23:06:03 -0800 (PST) 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 nK3eojHVWoLD for ; Sun, 19 Feb 2017 23:06:01 -0800 (PST) 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 799FD1298BB for ; Sun, 19 Feb 2017 23:06:01 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655] (unknown [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655]) by mail.nic.cz (Postfix) with ESMTPSA id 29D23600D6; Mon, 20 Feb 2017 08:05:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487574359; bh=jugLByevmdFV48sfxZKUd1jogXtMpcIixGgBSymNrEY=; h=From:Date:To; b=RZJwf9w4usnDy3s4KamSQxX4ludVvEyivYHx513TzSccwj4XqrfdvDbLkQJ94ItC3 xux+L46NBJWfuQfE6Yu15xb21xcalwcNEkQJTSEmGdk8Fi+MI6elY/DQQbOSt0FDdj hYvB/KSjZeOlUanIv+J+dRHih0/kMpErblmefGJY= 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: Mon, 20 Feb 2017 08:06:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> References: 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: Cc: Benoit Claise Subject: Re: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 07:06:03 -0000 Hi Andy, I would be interested in attending that meeting. Lada > On 19 Feb 2017, at 21:05, Andy Bierman wrote: >=20 > Hi, >=20 > The CORE WG is working on some standards for an IoT version of = RESTCONF. > The CBOR encoding is relevant to RESTCONF for some applications like = YANG push. >=20 > I am trying to organize a side meeting about YANG to CBOR and > SID (numeric schema node identifiers). The goal of the meeting is > understand how it works (and doesn't work). Hopefully there will be a > 1 hour slot open for this meeting, and a room available. > The first step is determining if any YANG doctors care about what > the CORE WG is doing with YANG. >=20 > Another topic: YANG to GPB? Better approach? Where is it documented? > Does an algorithm exist that works for YANG augment? >=20 > CORE WG drafts: >=20 > YANG to CBOR > https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ >=20 > SID > https://datatracker.ietf.org/doc/draft-ietf-core-sid/ >=20 >=20 > CoMI > https://datatracker.ietf.org/doc/draft-ietf-core-comi/ >=20 >=20 > Andy >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 20 00:05:35 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792AA1298A5 for ; Mon, 20 Feb 2017 00:05:33 -0800 (PST) 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 vdVTyfO1rv6k for ; Mon, 20 Feb 2017 00:05:32 -0800 (PST) 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 6FFEA1293E9 for ; Mon, 20 Feb 2017 00:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13687; q=dns/txt; s=iport; t=1487577931; x=1488787531; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=zaLLv1FVNKvpP2di46PQmSiY2Hot4er9RzVVMdHZsWo=; b=jGtmnA+9pas4BDvhL5FPXInVISPORq0CSvP1MCXCgqxhmdKK1mO6dvBw BWeuKPQTJDungMSGqS8HIikNHz4gNasplQPXuUwIT95/eZWw1WSGKzRqu ursxa5AJ+FEcoP61I3TIOFo8gbKYQwSX4TPbL9aVmITSrGSESk6/Z/WcP k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgBKoqpY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm+BQwMnX41jcpECH5AIgx2CD4IMLIV2AoJpGAECAQEBAQEBAWI?= =?us-ascii?q?ohHEGLUwQCw4fGVcGAQwIAQEQiVsOrDyDRiuLHgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFhkyCBQiCYoMXgQ8QAgEGVIUmBZVehiaGdIY0hHWBe4UXgy2GS4sciAY?= =?us-ascii?q?fOHgIIBQIFxWFPoFJPzUBiFWCOwEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,185,1484006400"; d="scan'208,217";a="692377375" 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; 20 Feb 2017 08:05:27 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1K85Q5D012435; Mon, 20 Feb 2017 08:05:26 GMT To: Mehmet Ersue , yang-doctors@ietf.org References: <02e901d28ae7$a50ce590$ef26b0b0$@gmail.com> From: Benoit Claise Message-ID: <0252f6ae-8688-7c77-a5ae-7aaa0185dcea@cisco.com> Date: Mon, 20 Feb 2017 09:05:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <02e901d28ae7$a50ce590$ef26b0b0$@gmail.com> Content-Type: multipart/alternative; boundary="------------7D32F97F7B02403238C03952" Archived-At: Cc: 'Gunter Van De Velde' , 'Dan Romascanu' , 'Robert Sparks' Subject: Re: [yang-doctors] Introducing the new Datatracker Review Tracking tool for YANG Module Reviews X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 08:05:33 -0000 This is a multi-part message in MIME format. --------------7D32F97F7B02403238C03952 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Mehmet. Dear all, Feel free to insert a picture at https://datatracker.ietf.org/dir/yangdoctors/photos/. That would help the community find you. Regards, Benoit > > Dear YANG Doctors, > > as discussed with Benoit this mail is to introduce the new datatracker > review tracking tool for YANG module reviews. > > The updated entry page for YANG Doctors team is at: > https://www.ietf.org/iesg/directorate/yang-doctors.html > > The entry page of the YANG review tracking tool is at: > https://datatracker.ietf.org/dir/yangdoctors/about/ > > Some of you know the review tracking tool already from OPS-DIR reviews. > > The usual process for YANG Doctors reviews using the new datatracker > tool is summarized below. > > A) ADs, WG chairs or draft authors request the review of a YANG module > on Datatracker. > > - Sign in on Datatracker: > https://datatracker.ietf.org/accounts/login/?next=/ > > - Go to the draft page (example): > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/ > > - Click on the button "Review request" which brings you to > (example): > https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/reviewrequest/ > > > - Choose the type of review (Early, LC, Telechat) and set a > recommended deadline > > - If required propose a reviewer in comments. > > B) YANG secretary assigns the requested review to a reviewer. > > - Datatracker generates an email to the reviewer indicating the > draft with the YANG module and the review deadline. > > - All assigned open review requests and closed review requests can > be always listed at: > https://datatracker.ietf.org/group/yangdoctors/reviews/ > > Notes: > > - Datatracker proposes a reviewer using based on the round robin > approach. > > - YANG doctors can enter their availability into their datatracker > account profile to avoid wrong assignments. > > C) The reviewer enters the review result into the review tool. > > - The reviewer goes to the draft review request page at (example): > https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/reviewrequest/8317/ > > > - Clicks on "Complete review" > > - Enters state, reviewed revision, and the review result. > > - In case the reviewer enters the review result directly into the > tool or uploads a text file, the tool generates an email to YANG > Doctors maillist, draft authors and the related WG maillist. > > Z) YANG doctors secretary will send a weekly summary of requested and > ongoing reviews to YANG doctors maillist. > > The first summary mail will be send out in parallel to this mail. > > Notes: > > - Old review assignments on the current review history page > (https://trac.ietf.org/trac/ops/wiki/yang-doctors-review-history) will > be migrated to the datatracker tool by the admin soon. The old page > will be used for external review requests only. > > - The Wiki page for the YANG review process will be updated within a > week based on the collected feedback. > > Thank you in advance for your suggestions and comments. > > Please let us know if you have any questions. > > Cheers, > > Mehmet > > (YANG Doctors Secretary) > --------------7D32F97F7B02403238C03952 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Thanks Mehmet.

Dear all,
Feel free to insert a picture at https://datatracker.ietf.org/dir/yangdoctors/photos/.
That would help the community find you.

Regards, Benoit

Dear YANG Doctors,

as discussed with Benoit this mail is to introduce the new datatracker review tracking tool for YANG module reviews.

The updated entry page for YANG Doctors team is at: https://www.ietf.org/iesg/directorate/yang-doctors.html

The entry page of the YANG review tracking tool is at: https://datatracker.ietf.org/dir/yangdoctors/about/

Some of you know the review tracking tool already from OPS-DIR reviews.

The usual process for YANG Doctors reviews using the new datatracker tool is summarized below.

A) ADs, WG chairs or draft authors request the review of a YANG module on Datatracker.

- Sign in on Datatracker: https://datatracker.ietf.org/accounts/login/?next=/

- Go to the draft page (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

- Click on the button "Review request" which brings you to (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/reviewrequest/

- Choose the type of review (Early, LC, Telechat) and set a recommended deadline

- If required propose a reviewer in comments.

B) YANG secretary assigns the requested review to a reviewer.

- Datatracker generates an email to the reviewer indicating the draft with the YANG module and the review deadline.

- All assigned open review requests and closed review requests can be always listed at: https://datatracker.ietf.org/group/yangdoctors/reviews/

Notes:

- Datatracker proposes a reviewer using based on the round robin approach.

- YANG doctors can enter their availability into their datatracker account profile to avoid wrong assignments.

C) The reviewer enters the review result into the review tool.

- The reviewer goes to the draft review request page at (example): https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/reviewrequest/8317/

- Clicks on "Complete review"

- Enters state, reviewed revision, and the review result.

- In case the reviewer enters the review result directly into the tool or uploads a text file, the tool generates an email to YANG Doctors maillist, draft authors and the related WG maillist.

Z) YANG doctors secretary will send a weekly summary of requested and ongoing reviews to YANG doctors maillist.

The first summary mail will be send out in parallel to this mail.

Notes:

- Old review assignments on the current review history page (https://trac.ietf.org/trac/ops/wiki/yang-doctors-review-history) will be migrated to the datatracker tool by the admin soon. The old page will be used for external review requests only.

- The Wiki page for the YANG review process will be updated within a week based on the collected feedback.

Thank you in advance for your suggestions and comments.

Please let us know if you have any questions.

Cheers,

Mehmet

(YANG Doctors Secretary)


--------------7D32F97F7B02403238C03952-- From nobody Mon Feb 20 03:50:02 2017 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EEA1299B9; Mon, 20 Feb 2017 03:49:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ladislav Lhotka" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2017 03:49:56 -0800 Archived-At: Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org, ietf@ietf.org, rtgwg@ietf.org Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 11:49:57 -0000 Reviewer: Ladislav Lhotka Review result: Almost Ready # General Comments ## Cryptographic algorithm types What is the reason for representing these as a YANG choice with empty leaves? I think it would be more natural to use a single leaf, either an enumeration or (if extensibility is important) identityref. ## Reusability The module defines key-chain as a grouping with the aim of making it reusable in other modules. However, this approach has known problems that are discussed in draft-ietf-netmod-schema-mount. I am not sure how relevant they are in this case but, for one, the "key-chain-ref" type is not applicable if the "key-chain" grouping is used in another module. An alternative is not to use the grouping and rely on schema mount. ## Key string style The difference between ASCII and hexadecimal formats of key strings should be explained. I understand that the latter is a hash of the key and, if so, I'd suggest to include "hexadecimal-string" also in state data. Also, I believe that storing clear-text key in configuration is insecure and Security Considerations should warn against it. ## Example It might be useful to include an appendix with example instance data. # Specific comments ## Sec. 2 - paragraph 2: s/where ever/wherever/ ## Sec. 3 - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter is used in other places of the text). - paragraph 2: the suggested way of supporting asymmetric keys looks like a hack, I would suggest a more explicit representation, e.g. using a choice. ## Sec. 4 - The module has inconsistent indentation: up to "grouping crypto-algorithm-types", top-level statements are indented with four spaces, the subsequent ones with five spaces. ## Sec. 6 - The statement "Given that the key chains themselves are sensitive data, it is RECOMMENDED that the NETCONF communication channel be encrypted." is misleading because RFC 6241 requires that transport protocols for NETCONF guarantee confidentiality (and RFC 8040 does the same for RESTCONF). From nobody Mon Feb 20 03:51:51 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF70129456 for ; Mon, 20 Feb 2017 03:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 fSsv0j73wl9V for ; Mon, 20 Feb 2017 03:51:48 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 070F412945C for ; Mon, 20 Feb 2017 03:51:48 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id 89so57959635wrr.3 for ; Mon, 20 Feb 2017 03:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=wfvI1vK8Pv0OVb88aQI0pjfG4OUlqk/tsw50kdjHmYI=; b=uiQJf+uveyv93RpzAL5Zo1HcC6W7uJvrHiHRnSQ2liSgpknedMD68cRD6lq1NYj2ij 0ECw/S7ZYf6Pu6MDt8JqHlmQkht9Ydjxx93CbfFmFol9mVhvox32vxIKoHgymwc63uz4 yqjOMnVWa9z8yZxZcSdhUt32XjqiH3USScv9aZVKkysUWnrjR+B477bkVtVsvmxxLma9 mrnyd79jufBZ3AY9S/6fguETIizK5AinbQ9iuOpNZ69AAMrT6zIEZoAHwbi4yTvQ+6Td NpczpPIp1NwXBYdchV/JqlqJdVEHUg7cGVZhp6y4tJDKhsaetBzguekX78CCK6nGO4b4 e6JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=wfvI1vK8Pv0OVb88aQI0pjfG4OUlqk/tsw50kdjHmYI=; b=jFhuoGG60DsYyXNTxbMxrodoRWtahNWiLGRULbX2tmcpqkHSmr/Yp77qOEYhJN31Li Xc8m5qKkSieyAamCF01UuGI1YZtek8hzLgYmeOqIDPo12XxNu3YUaWVhUF0Rb0e8WKNC FfNWKAzcnVXivNX0IETMT4xFpfKPnBBy6dq0PaxylAokSBhFIUoxpX7ht9ePqh6RF0W+ z8ypQbwW7NS97uC2BKGdqRTBlV6zR8SwmIr9kcU3Zciks8EvB94T2Hca3RIHo+AxQzPa JDOhzIFHprV1iGfS5b5Xduf4IHyjLFv89e/vWMFbfWGZQwU5eLRUXfIU/c6RlJYl5enS w71Q== X-Gm-Message-State: AMke39ky9IvClL0ZyXyQLtddwNJLvjbWAzWhh1t92R4WONksYqRUySpJRh/uvD7pZi3x+w== X-Received: by 10.223.165.17 with SMTP id i17mr17536322wrb.62.1487591506474; Mon, 20 Feb 2017 03:51:46 -0800 (PST) Received: from [192.168.178.37] (p5B342FEF.dip0.t-ipconnect.de. [91.52.47.239]) by smtp.gmail.com with ESMTPSA id y89sm460907wrc.23.2017.02.20.03.51.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Feb 2017 03:51:45 -0800 (PST) References: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> Mime-Version: 1.0 (1.0) In-Reply-To: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (13G36) From: Mehmet Ersue Date: Mon, 20 Feb 2017 12:51:44 +0100 To: Ladislav Lhotka Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 11:51:50 -0000 me2 Cheers, Mehmet (Sent from my iPad) > Am 20.02.2017 um 08:06 schrieb Ladislav Lhotka : >=20 > Hi Andy, >=20 > I would be interested in attending that meeting. >=20 > Lada >=20 >> On 19 Feb 2017, at 21:05, Andy Bierman wrote: >>=20 >> Hi, >>=20 >> The CORE WG is working on some standards for an IoT version of RESTCONF. >> The CBOR encoding is relevant to RESTCONF for some applications like YANG= push. >>=20 >> I am trying to organize a side meeting about YANG to CBOR and >> SID (numeric schema node identifiers). The goal of the meeting is >> understand how it works (and doesn't work). Hopefully there will be a >> 1 hour slot open for this meeting, and a room available. >> The first step is determining if any YANG doctors care about what >> the CORE WG is doing with YANG. >>=20 >> Another topic: YANG to GPB? Better approach? Where is it documented? >> Does an algorithm exist that works for YANG augment? >>=20 >> CORE WG drafts: >>=20 >> YANG to CBOR >> https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ >>=20 >> SID >> https://datatracker.ietf.org/doc/draft-ietf-core-sid/ >>=20 >>=20 >> CoMI >> https://datatracker.ietf.org/doc/draft-ietf-core-comi/ >>=20 >>=20 >> Andy >>=20 >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Mon Feb 20 03:56:19 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CE21293D6; Mon, 20 Feb 2017 03:56:17 -0800 (PST) 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 gfVCnU2vykhj; Mon, 20 Feb 2017 03:56:16 -0800 (PST) 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 026601299B5; Mon, 20 Feb 2017 03:56:16 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655] (unknown [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655]) by mail.nic.cz (Postfix) with ESMTPSA id 60EAA60129; Mon, 20 Feb 2017 12:56:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487591774; bh=blneXzU46WFtAaKP/oiCwi/DYlmmPY7IKQRiOi4hSqE=; h=From:Date:To; b=QemSl7TM/Jrv2dCbRhFI+bd24ueR3u6P6FkBECw38yBIAJBhxufsihsUbYR2nRwUR IQWAd2gS9ah05TFOykHLYL4UfbC99BTYJ5tDxxyDvoTRQHvn0f0cGLuJ0aj8e2G2/f 5JtoGx+2gjW5D7cA9aAccyZeC2K37wsCde5JJxok= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> Date: Mon, 20 Feb 2017 12:56:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8B1E055B-6B06-482D-8341-B49B6EE32BEC@nic.cz> References: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org Subject: Re: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 11:56:18 -0000 Hi, this is my old review, on Mehmet's request I entered it into the = datatracker, so no action is needed. I just removed my objection that = turned out to be nonsense. Lada > On 20 Feb 2017, at 12:49, Ladislav Lhotka wrote: >=20 > Reviewer: Ladislav Lhotka > Review result: Almost Ready >=20 > # General Comments >=20 > ## Cryptographic algorithm types >=20 > What is the reason for representing these as a YANG choice with empty > leaves? I think it would be more natural to use a single leaf, either > an enumeration or (if extensibility is important) identityref. >=20 > ## Reusability >=20 > The module defines key-chain as a grouping with the aim of making it > reusable in other modules. However, this approach has known problems > that are discussed in draft-ietf-netmod-schema-mount. I am not sure > how relevant they are in this case but, for one, the "key-chain-ref" > type is not applicable if the "key-chain" grouping is used in another > module. An alternative is not to use the grouping and rely on schema > mount. >=20 > ## Key string style >=20 > The difference between ASCII and hexadecimal formats of key strings > should be explained. I understand that the latter is a hash of the key > and, if so, I'd suggest to include "hexadecimal-string" also in state > data. >=20 > Also, I believe that storing clear-text key in configuration is > insecure and Security Considerations should warn against it. >=20 > ## Example >=20 > It might be useful to include an appendix with example instance data. >=20 > # Specific comments >=20 > ## Sec. 2 >=20 > - paragraph 2: s/where ever/wherever/ >=20 > ## Sec. 3 >=20 > - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter > is used in other places of the=20 > text). > - paragraph 2: the suggested way of supporting asymmetric keys looks > like a hack, I would suggest=20 > a more explicit representation, e.g. using a choice. >=20 > ## Sec. 4 >=20 > - The module has inconsistent indentation: up to "grouping > crypto-algorithm-types", top-level =20 > statements are indented with four spaces, the subsequent ones with > five spaces. >=20 > ## Sec. 6 >=20 > - The statement "Given that the key chains themselves are sensitive > data, it is RECOMMENDED =20 > that the NETCONF communication channel be encrypted." is > misleading because RFC 6241=20 > requires that transport protocols for NETCONF guarantee > confidentiality (and RFC 8040 does the=20 > same for RESTCONF). >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 20 03:56:49 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B891293D6 for ; Mon, 20 Feb 2017 03:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.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 U6pY7i5t1AKF for ; Mon, 20 Feb 2017 03:56:45 -0800 (PST) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16631299BB for ; Mon, 20 Feb 2017 03:56:44 -0800 (PST) Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 795E420191; Mon, 20 Feb 2017 12:56:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1487591802; bh=Jf+9iMbcFJ+uPawYbMUs7B/FmoLzHQtNiWSUktWjx2Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=PyBf8CvPcg7Tk9/1EqvM/6TylVuQxQjhNFSt8OfyrFkPye7T7hSVahquQk24vbqXU NJ30YuUfyB8opzhsKxtLQjuwOOYrCnLjCvxJD35tz/NQ/tX0XS9dkeB+MfQuKbO7FP AvQTyqMWmEcHGt28BjwM2KmFdRxMisCnhSBGASB0= To: Andy Bierman References: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= Message-ID: <0d43dff0-3190-8600-30fa-0ec62b48b56e@cesnet.cz> Date: Mon, 20 Feb 2017 12:56:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 11:56:47 -0000 +1 Radek Dne 20.2.2017 v 08:06 Ladislav Lhotka napsal(a): > Hi Andy, > > I would be interested in attending that meeting. > > Lada > >> On 19 Feb 2017, at 21:05, Andy Bierman wrote: >> >> Hi, >> >> The CORE WG is working on some standards for an IoT version of RESTCONF. >> The CBOR encoding is relevant to RESTCONF for some applications like YANG push. >> >> I am trying to organize a side meeting about YANG to CBOR and >> SID (numeric schema node identifiers). The goal of the meeting is >> understand how it works (and doesn't work). Hopefully there will be a >> 1 hour slot open for this meeting, and a room available. >> The first step is determining if any YANG doctors care about what >> the CORE WG is doing with YANG. >> >> Another topic: YANG to GPB? Better approach? Where is it documented? >> Does an algorithm exist that works for YANG augment? >> >> CORE WG drafts: >> >> YANG to CBOR >> https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ >> >> SID >> https://datatracker.ietf.org/doc/draft-ietf-core-sid/ >> >> >> CoMI >> https://datatracker.ietf.org/doc/draft-ietf-core-comi/ >> >> >> Andy >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Radek Krejci mobile : +420 732 212 714 office : +420 234 680 256 e-mail : rkrejci@cesnet.cz LinkedIn: http://www.linkedin.com/in/radekkrejci CESNET, Association of Legal Entities Zikova 4 160 00 Praha 6 Czech Republic From nobody Mon Feb 20 04:22:03 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C841299BA for ; Mon, 20 Feb 2017 04:22:00 -0800 (PST) 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, FREEMAIL_FROM=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 abac8qjwklPI for ; Mon, 20 Feb 2017 04:21:59 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 2CCA8129464 for ; Mon, 20 Feb 2017 04:21:59 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id c85so77480586wmi.1 for ; Mon, 20 Feb 2017 04:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=Ld4tmjueen+OydgSdD3pF5JfenduNNLyWPWBLwsRsXc=; b=Gcd8k7GoXWiXxLBEGLqdKc9XkqHWhF8oIB7s5WACqpAr3AFsIbNE/boOJnsEzPI4qF Cw2QNERtoAjhlwtqWNEZak0X0joyQNPm26ORhoaLtJEYfttRwZ1+nzWthbhGA8nNqBDQ qt/sH3v/smb2AAhG/VZtDAegyL05B9K4U5nz1qM1/lrqM0T4iDPjVIPK4TUeNgQElxed 0mv+fue87YKA6hHBX/UTqsD7hDgxSFsU/pr1UdKiY7WXvz7Rpsz9Rqy8mLUjJja9JHdX aCLYYwYeROCzQOu6iBk9OPfLMQGgRDMP1OjrU9tb3rNKDDOtnE85rW4gj5KI/g0RU+/d uHCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=Ld4tmjueen+OydgSdD3pF5JfenduNNLyWPWBLwsRsXc=; b=Vp4oEge+3mURknTL1hO7DCymbd/tTvoMRf8m/qDAsBMpdvahX1iIG69t8FgbfuacKe KSOZS55hxiEzPWQtN3snJ19GoYEl01RhUwB2CvbqOiZJ1n4r+3IOGg1GorfzZ3wrtPgR wC1sDPfWe6Ci9SXVo4McSVXMTcnjUXfC7hZngD8nTKjxG++Yh5WSKnAqsRC6S0SESWNz XuKz/DkC3JeqtCdE0lKjvVZtVdYvevvtm7v1WtTO3bnh/u/fKlobuR+NAtRWmWmJOEat iR3KO3OY8H+lY5d+UqGlne+QT77/7jimF8Z5xKAL6vtBzIPl56ZQvGI6PZkBVl0zsmli P/Fg== X-Gm-Message-State: AMke39mjshrwIMpXtC6uGDxIol6ivGlR1PDFAFZWj2MkTls5/RsNZjXyImo9KPO+PrbLIA== X-Received: by 10.28.215.200 with SMTP id o191mr10387019wmg.118.1487593317423; Mon, 20 Feb 2017 04:21:57 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B342FEF.dip0.t-ipconnect.de. [91.52.47.239]) by smtp.gmail.com with ESMTPSA id b10sm13275708wmi.34.2017.02.20.04.21.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 04:21:56 -0800 (PST) From: "Mehmet Ersue" To: "'Ladislav Lhotka'" , Date: Mon, 20 Feb 2017 13:21:57 +0100 Message-ID: <006801d28b73$eec8e990$cc5abcb0$@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: AdKLc+tAb0LroHnPSLqKEtgIj3Uu9A== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0203.58AADF64.01BC,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: [yang-doctors] First review entry WAS:RE: Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:22:01 -0000 Many Thanks Lada!!! Looks perfect. Though, I'm not 100% sure whether we should send such mails always to ietf@ietf.org. I can imagine yang-doctors, draft authors and the related WG would be sufficient. @Benoit: What do you think? Cheers, Mehmet > -----Original Message----- > From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf Of > Ladislav Lhotka > Sent: Monday, February 20, 2017 12:50 PM > To: yang-doctors@ietf.org > Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org; ietf@ietf.org; > rtgwg@ietf.org > Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 > > Reviewer: Ladislav Lhotka > Review result: Almost Ready > > # General Comments > > ## Cryptographic algorithm types > > What is the reason for representing these as a YANG choice with empty > leaves? I think it would be more natural to use a single leaf, either an > enumeration or (if extensibility is important) identityref. > > ## Reusability > > The module defines key-chain as a grouping with the aim of making it > reusable in other modules. However, this approach has known problems that > are discussed in draft-ietf-netmod-schema-mount. I am not sure how > relevant they are in this case but, for one, the "key-chain-ref" > type is not applicable if the "key-chain" grouping is used in another module. > An alternative is not to use the grouping and rely on schema mount. > > ## Key string style > > The difference between ASCII and hexadecimal formats of key strings should > be explained. I understand that the latter is a hash of the key and, if so, I'd > suggest to include "hexadecimal-string" also in state data. > > Also, I believe that storing clear-text key in configuration is insecure and > Security Considerations should warn against it. > > ## Example > > It might be useful to include an appendix with example instance data. > > # Specific comments > > ## Sec. 2 > > - paragraph 2: s/where ever/wherever/ > > ## Sec. 3 > > - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter > is used in other places of the > text). > - paragraph 2: the suggested way of supporting asymmetric keys looks > like a hack, I would suggest > a more explicit representation, e.g. using a choice. > > ## Sec. 4 > > - The module has inconsistent indentation: up to "grouping > crypto-algorithm-types", top-level > statements are indented with four spaces, the subsequent ones with five > spaces. > > ## Sec. 6 > > - The statement "Given that the key chains themselves are sensitive > data, it is RECOMMENDED > that the NETCONF communication channel be encrypted." is misleading > because RFC 6241 > requires that transport protocols for NETCONF guarantee confidentiality > (and RFC 8040 does the > same for RESTCONF). > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Mon Feb 20 04:37:34 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B301299C0 for ; Mon, 20 Feb 2017 04:37:32 -0800 (PST) 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 IeQwXVMD9zI5 for ; Mon, 20 Feb 2017 04:37:31 -0800 (PST) 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 85F581299BE for ; Mon, 20 Feb 2017 04:37:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655] (unknown [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655]) by mail.nic.cz (Postfix) with ESMTPSA id 35F4B60168; Mon, 20 Feb 2017 13:37:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487594249; bh=yGLbt69O8LF5OHEaDDoBeQiAWTistFXYnKg72k0u9ok=; h=From:Date:To; b=pm/VpJS6lsQ/+OnmbcZASlWJcMcysyFkAORPGkA8FzuBNGeSLmiONypd3fJJ4xWO9 HALkKBHCiLiFjCY8Yp2xjUQQ2S2MmEGip5dKpCxKOkiy3ygLusZJO0aJJBfu7233Rw hMzNEqnnq99ic2GSeg6i6UvOduff292604027Jus= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <006801d28b73$eec8e990$cc5abcb0$@gmail.com> Date: Mon, 20 Feb 2017 13:37:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80571237-8277-4746-BB36-9A8E3FC88D90@nic.cz> References: <006801d28b73$eec8e990$cc5abcb0$@gmail.com> To: Mehmet Ersue X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise Subject: Re: [yang-doctors] First review entry WAS:RE: Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:37:33 -0000 > On 20 Feb 2017, at 13:21, Mehmet Ersue wrote: >=20 > Many Thanks Lada!!! Looks perfect. Well, there may be spurious line breaks depending on the width of the = browser window. Actually, I think it would be helpful to support some = kind of lightweight markup such as markdown. >=20 > Though, I'm not 100% sure whether we should send such mails always to > ietf@ietf.org. Certainly not! If I correctly remember, the review form mentioned only = draft-ietf-rtgwg-yang-key-chain.all@ietf.org and rtgwg@ietf.org to be in = Cc. Lada > I can imagine yang-doctors, draft authors and the related WG would be > sufficient. >=20 > @Benoit:=20 > What do you think? >=20 > Cheers, > Mehmet >=20 >> -----Original Message----- >> From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf = Of >> Ladislav Lhotka >> Sent: Monday, February 20, 2017 12:50 PM >> To: yang-doctors@ietf.org >> Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org; ietf@ietf.org; >> rtgwg@ietf.org >> Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 >>=20 >> Reviewer: Ladislav Lhotka >> Review result: Almost Ready >>=20 >> # General Comments >>=20 >> ## Cryptographic algorithm types >>=20 >> What is the reason for representing these as a YANG choice with empty >> leaves? I think it would be more natural to use a single leaf, either = an >> enumeration or (if extensibility is important) identityref. >>=20 >> ## Reusability >>=20 >> The module defines key-chain as a grouping with the aim of making it >> reusable in other modules. However, this approach has known problems = that >> are discussed in draft-ietf-netmod-schema-mount. I am not sure how >> relevant they are in this case but, for one, the "key-chain-ref" >> type is not applicable if the "key-chain" grouping is used in another > module. >> An alternative is not to use the grouping and rely on schema mount. >>=20 >> ## Key string style >>=20 >> The difference between ASCII and hexadecimal formats of key strings = should >> be explained. I understand that the latter is a hash of the key and, = if > so, I'd >> suggest to include "hexadecimal-string" also in state data. >>=20 >> Also, I believe that storing clear-text key in configuration is = insecure > and >> Security Considerations should warn against it. >>=20 >> ## Example >>=20 >> It might be useful to include an appendix with example instance data. >>=20 >> # Specific comments >>=20 >> ## Sec. 2 >>=20 >> - paragraph 2: s/where ever/wherever/ >>=20 >> ## Sec. 3 >>=20 >> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter >> is used in other places of the >> text). >> - paragraph 2: the suggested way of supporting asymmetric keys = looks >> like a hack, I would suggest >> a more explicit representation, e.g. using a choice. >>=20 >> ## Sec. 4 >>=20 >> - The module has inconsistent indentation: up to "grouping >> crypto-algorithm-types", top-level >> statements are indented with four spaces, the subsequent ones with > five >> spaces. >>=20 >> ## Sec. 6 >>=20 >> - The statement "Given that the key chains themselves are sensitive >> data, it is RECOMMENDED >> that the NETCONF communication channel be encrypted." is = misleading >> because RFC 6241 >> requires that transport protocols for NETCONF guarantee > confidentiality >> (and RFC 8040 does the >> same for RESTCONF). >>=20 >>=20 >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 20 04:48:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EEC1299BF for ; Mon, 20 Feb 2017 04:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 so3ZeCgITVhZ for ; Mon, 20 Feb 2017 04:48:08 -0800 (PST) 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 4D3B9129434 for ; Mon, 20 Feb 2017 04:48:08 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id z61so63318957wrc.1 for ; Mon, 20 Feb 2017 04:48:07 -0800 (PST) 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:disposition-notification-to; bh=rE9bvUknr5nBoaR7zFk+TEVWJjNMRcuLUk57pDY2mgY=; b=IcKx6Qjj8UYdfeAFQpfB2pap2K5EUKn49Sx0gKOmccBsDDkFB+rrr/oqKa7kjhtPgP XSPOf4QbMFcuPSDz6CAldMkUp0BpjSwp6QoDZgUHZNsOlOvH+zG4isDt19Dja8CFTOUj lNoKzqEUjy1dohg1Ga20TtA4yQAL2J0GFz/illAH/WzfGec70xnn8+oQaqzmNrX9Ihdj dyMZwEvYRUOt9+ZmgeuuFhIDPND+lyhPVDLtBFAsQdao0NmiqJPo/WPTOQ9bGwMDK6CQ iVoHzLjxyfj29+Bkn63Q/MfhORE3tjJojecWl+WX/aMzOYIX+bjttvvZG4sHK4njsrvd tvOg== 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:disposition-notification-to; bh=rE9bvUknr5nBoaR7zFk+TEVWJjNMRcuLUk57pDY2mgY=; b=VJ2qV+kFmZyZn16jzkmvOUIc/cM6LP3ZeXq3M8NsBAFFC3hcw/cgk5t6mK6+Q22uY5 Ve2SETz0cmh05T4mSqDVDMlRuiR3ucjP/IXrU+7pRgsXN5LMcIVQekJ3xhjMhZ2yGIi3 eIigPVhkCbU+cL93GyZ2iJYzzXxTeQauAtXVDhhlF8nQdo/5wiVrndN6nUzCLKoGJLLh 4btyhTVu7uxaD9FA79njm1dFlqMp/PLG8NcUzPEK2xJUct02z1HCC/agn6qIl89Gd3MV yJYt567cwh4p1fQh/TksNbaAJX9NMbf41E+wnxhpz22Qx05BkM1+bCaMFK5XHi9KTtR+ 0EKg== X-Gm-Message-State: AMke39ns5RT2Ybwbcnp6HTLX6T8q2eBZRSMu4eBiIqjMaMKYAJQofqnFjWuJZ0Vp3qlDoA== X-Received: by 10.223.129.163 with SMTP id 32mr14954680wra.140.1487594886543; Mon, 20 Feb 2017 04:48:06 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B342FEF.dip0.t-ipconnect.de. [91.52.47.239]) by smtp.gmail.com with ESMTPSA id c133sm13318801wmd.13.2017.02.20.04.48.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 04:48:05 -0800 (PST) From: "Mehmet Ersue" To: "'Ladislav Lhotka'" References: <006801d28b73$eec8e990$cc5abcb0$@gmail.com> <80571237-8277-4746-BB36-9A8E3FC88D90@nic.cz> In-Reply-To: <80571237-8277-4746-BB36-9A8E3FC88D90@nic.cz> Date: Mon, 20 Feb 2017 13:48:07 +0100 Message-ID: <010901d28b77$9627de50$c2779af0$@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: AQGIOONTslgTBWVcGpoonQR5ys1BQgIYTe+5ofW6kpA= Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0202.58AAE585.025A,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Benoit Claise' Subject: Re: [yang-doctors] First review entry WAS:RE: Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:48:10 -0000 The review form actually includes ietf@ietf.org which we also see in CC of the automatically generated mail. Cheers, Mehmet > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Monday, February 20, 2017 1:38 PM > To: Mehmet Ersue > Cc: Benoit Claise > Subject: Re: First review entry WAS:RE: [yang-doctors] Review of draft-ietf- > rtgwg-yang-key-chain-13 > > > > On 20 Feb 2017, at 13:21, Mehmet Ersue wrote: > > > > Many Thanks Lada!!! Looks perfect. > > Well, there may be spurious line breaks depending on the width of the > browser window. Actually, I think it would be helpful to support some kind of > lightweight markup such as markdown. > > > > > Though, I'm not 100% sure whether we should send such mails always to > > ietf@ietf.org. > > Certainly not! If I correctly remember, the review form mentioned only > draft-ietf-rtgwg-yang-key-chain.all@ietf.org and rtgwg@ietf.org to be in Cc. > > Lada > > > I can imagine yang-doctors, draft authors and the related WG would be > > sufficient. > > > > @Benoit: > > What do you think? > > > > Cheers, > > Mehmet > > > >> -----Original Message----- > >> From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf > >> Of Ladislav Lhotka > >> Sent: Monday, February 20, 2017 12:50 PM > >> To: yang-doctors@ietf.org > >> Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org; ietf@ietf.org; > >> rtgwg@ietf.org > >> Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 > >> > >> Reviewer: Ladislav Lhotka > >> Review result: Almost Ready > >> > >> # General Comments > >> > >> ## Cryptographic algorithm types > >> > >> What is the reason for representing these as a YANG choice with empty > >> leaves? I think it would be more natural to use a single leaf, either > >> an enumeration or (if extensibility is important) identityref. > >> > >> ## Reusability > >> > >> The module defines key-chain as a grouping with the aim of making it > >> reusable in other modules. However, this approach has known problems > >> that are discussed in draft-ietf-netmod-schema-mount. I am not sure > >> how relevant they are in this case but, for one, the "key-chain-ref" > >> type is not applicable if the "key-chain" grouping is used in another > > module. > >> An alternative is not to use the grouping and rely on schema mount. > >> > >> ## Key string style > >> > >> The difference between ASCII and hexadecimal formats of key strings > >> should be explained. I understand that the latter is a hash of the > >> key and, if > > so, I'd > >> suggest to include "hexadecimal-string" also in state data. > >> > >> Also, I believe that storing clear-text key in configuration is > >> insecure > > and > >> Security Considerations should warn against it. > >> > >> ## Example > >> > >> It might be useful to include an appendix with example instance data. > >> > >> # Specific comments > >> > >> ## Sec. 2 > >> > >> - paragraph 2: s/where ever/wherever/ > >> > >> ## Sec. 3 > >> > >> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter > >> is used in other places of the > >> text). > >> - paragraph 2: the suggested way of supporting asymmetric keys looks > >> like a hack, I would suggest > >> a more explicit representation, e.g. using a choice. > >> > >> ## Sec. 4 > >> > >> - The module has inconsistent indentation: up to "grouping > >> crypto-algorithm-types", top-level > >> statements are indented with four spaces, the subsequent ones with > > five > >> spaces. > >> > >> ## Sec. 6 > >> > >> - The statement "Given that the key chains themselves are sensitive > >> data, it is RECOMMENDED > >> that the NETCONF communication channel be encrypted." is > >> misleading because RFC 6241 > >> requires that transport protocols for NETCONF guarantee > > confidentiality > >> (and RFC 8040 does the > >> same for RESTCONF). > >> > >> > >> _______________________________________________ > >> yang-doctors mailing list > >> yang-doctors@ietf.org > >> https://www.ietf.org/mailman/listinfo/yang-doctors > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > From nobody Mon Feb 20 04:53:38 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1946012947D; Mon, 20 Feb 2017 04:53:30 -0800 (PST) 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 LYlj9QTuBxNn; Mon, 20 Feb 2017 04:53:28 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E6A5129434; Mon, 20 Feb 2017 04:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1487595208; x=1488804808; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Oq0hHheM5PUHmVCUR4tfnud0Ti+JEvgE2uWPbGioGLs=; b=PpZCnobijN9McvK3VGFngCsy30iDK3E/w0DBpgTwj+c65jsN5XOnegcf pvo9HMQ1lMp27F6Nuxp86E1a51lDUX9ADaFNg+cZaCs1hMiyHmjXd+/Ni LDTiKs85/8tfnTrSW6ikRCuOZP2CZoxdBdBhVfIfEq5vCzVzwMOcgO6VA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQCU5qpY/4UNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1FhgQkHjVynSIIMKoV4AoI4PxgBAgEBAQEBAQFiKIRxBnkQAgEIRjI?= =?us-ascii?q?lAgQBDQWJbw6vaotOAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWLO4o5BZAIi3wBk?= =?us-ascii?q?hyRCpMhAR84gQBTFT6ESR6BYXUBigOBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.35,186,1484006400"; d="scan'208";a="210648156" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Feb 2017 12:53:05 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1KCr5ct015004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Feb 2017 12:53:05 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, 20 Feb 2017 07:53:05 -0500 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, 20 Feb 2017 07:53:05 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , "yang-doctors@ietf.org" Thread-Topic: Review of draft-ietf-rtgwg-yang-key-chain-13 Thread-Index: AQHSi293pFk9o9mEqEaW7SaUvTwXFqFx2aOA Date: Mon, 20 Feb 2017 12:53:04 +0000 Message-ID: References: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> In-Reply-To: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> 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.196] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Subject: Re: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:53:30 -0000 Hi Lada,=20 I believe we=B9ve addressed all of these other than adding an explicit leaf for key direction (which was discussed on the RTGWG list). The current version is https://www.ietf.org/id/draft-ietf-rtgwg-yang-key-chain-15.txt Thanks, Acee=20 On 2/20/17, 6:49 AM, "Ladislav Lhotka" wrote: >Reviewer: Ladislav Lhotka >Review result: Almost Ready > ># General Comments > >## Cryptographic algorithm types > >What is the reason for representing these as a YANG choice with empty >leaves? I think it would be more natural to use a single leaf, either >an enumeration or (if extensibility is important) identityref. > >## Reusability > >The module defines key-chain as a grouping with the aim of making it >reusable in other modules. However, this approach has known problems >that are discussed in draft-ietf-netmod-schema-mount. I am not sure >how relevant they are in this case but, for one, the "key-chain-ref" >type is not applicable if the "key-chain" grouping is used in another >module. An alternative is not to use the grouping and rely on schema >mount. > >## Key string style > >The difference between ASCII and hexadecimal formats of key strings >should be explained. I understand that the latter is a hash of the key >and, if so, I'd suggest to include "hexadecimal-string" also in state >data. > >Also, I believe that storing clear-text key in configuration is >insecure and Security Considerations should warn against it. > >## Example > >It might be useful to include an appendix with example instance data. > ># Specific comments > =20 >## Sec. 2 > >- paragraph 2: s/where ever/wherever/ > >## Sec. 3 > >- paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter >is used in other places of the > text). >- paragraph 2: the suggested way of supporting asymmetric keys looks >like a hack, I would suggest > a more explicit representation, e.g. using a choice. > >## Sec. 4 > >- The module has inconsistent indentation: up to "grouping >crypto-algorithm-types", top-level > statements are indented with four spaces, the subsequent ones with >five spaces. > >## Sec. 6 > >- The statement "Given that the key chains themselves are sensitive >data, it is RECOMMENDED > that the NETCONF communication channel be encrypted." is >misleading because RFC 6241 > requires that transport protocols for NETCONF guarantee >confidentiality (and RFC 8040 does the > same for RESTCONF). > > From nobody Mon Feb 20 04:57:54 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF812946E; Mon, 20 Feb 2017 04:57:49 -0800 (PST) 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 ygnOykqTEZ5z; Mon, 20 Feb 2017 04:57:48 -0800 (PST) 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 F276B12941D; Mon, 20 Feb 2017 04:57:47 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655] (unknown [IPv6:2001:718:1a02:1:fd80:c4c7:82a3:3655]) by mail.nic.cz (Postfix) with ESMTPSA id 834FA61E45; Mon, 20 Feb 2017 13:57:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487595466; bh=dwxVewM09ncLgYi5sSMWOCU+MP21JjAv1zh4yZP1gWI=; h=From:Date:To; b=qXrR4J66xG6vmSq5MfgonXHxctfIEPu2UjcWxRnWYS2hlv+1gybJnNS0JRE8SlLdj Xua7Xg+9B4P2JKub5L4GLBTVwRJ0REXpyCNigLDoim8wD4V+eerbf9TSqtYfU6l7U0 6UBRkP1BMls2VXe0Hrc2ByqFc+3t4nMfw7xE65RM= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 20 Feb 2017 13:58:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <04FB4163-BBA3-44ED-8B9F-E1F2A5F49205@nic.cz> References: <148759139687.25976.6374643432126541498.idtracker@ietfa.amsl.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Benoit Claise , "draft-ietf-rtgwg-yang-key-chain.all@ietf.org" , "ietf@ietf.org" , "rtgwg@ietf.org" Subject: Re: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 12:57:49 -0000 > On 20 Feb 2017, at 13:53, Acee Lindem (acee) wrote: >=20 > Hi Lada,=20 > I believe we=C2=B9ve addressed all of these other than adding an = explicit leaf > for key direction (which was discussed on the RTGWG list). The current > version is = https://www.ietf.org/id/draft-ietf-rtgwg-yang-key-chain-15.txt Yes, I saw it, looks good. Thanks, Lada >=20 > Thanks, > Acee=20 >=20 > On 2/20/17, 6:49 AM, "Ladislav Lhotka" wrote: >=20 >> Reviewer: Ladislav Lhotka >> Review result: Almost Ready >>=20 >> # General Comments >>=20 >> ## Cryptographic algorithm types >>=20 >> What is the reason for representing these as a YANG choice with empty >> leaves? I think it would be more natural to use a single leaf, either >> an enumeration or (if extensibility is important) identityref. >>=20 >> ## Reusability >>=20 >> The module defines key-chain as a grouping with the aim of making it >> reusable in other modules. However, this approach has known problems >> that are discussed in draft-ietf-netmod-schema-mount. I am not sure >> how relevant they are in this case but, for one, the "key-chain-ref" >> type is not applicable if the "key-chain" grouping is used in another >> module. An alternative is not to use the grouping and rely on schema >> mount. >>=20 >> ## Key string style >>=20 >> The difference between ASCII and hexadecimal formats of key strings >> should be explained. I understand that the latter is a hash of the = key >> and, if so, I'd suggest to include "hexadecimal-string" also in state >> data. >>=20 >> Also, I believe that storing clear-text key in configuration is >> insecure and Security Considerations should warn against it. >>=20 >> ## Example >>=20 >> It might be useful to include an appendix with example instance data. >>=20 >> # Specific comments >>=20 >> ## Sec. 2 >>=20 >> - paragraph 2: s/where ever/wherever/ >>=20 >> ## Sec. 3 >>=20 >> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter >> is used in other places of the >> text). >> - paragraph 2: the suggested way of supporting asymmetric keys = looks >> like a hack, I would suggest >> a more explicit representation, e.g. using a choice. >>=20 >> ## Sec. 4 >>=20 >> - The module has inconsistent indentation: up to "grouping >> crypto-algorithm-types", top-level >> statements are indented with four spaces, the subsequent ones with >> five spaces. >>=20 >> ## Sec. 6 >>=20 >> - The statement "Given that the key chains themselves are sensitive >> data, it is RECOMMENDED >> that the NETCONF communication channel be encrypted." is >> misleading because RFC 6241 >> requires that transport protocols for NETCONF guarantee >> confidentiality (and RFC 8040 does the >> same for RESTCONF). >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Feb 20 06:49:18 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E4E1294AC for ; Mon, 20 Feb 2017 06:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 0n2YMGO8eBdG for ; Mon, 20 Feb 2017 06:49:16 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::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 6A4A912947F for ; Mon, 20 Feb 2017 06:49:16 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 5so13201356pgj.0 for ; Mon, 20 Feb 2017 06:49:16 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=PRw1UDTnZLHw2vJgIg5WQ5OyUCILhKX49wPYQCOuWoQ=; b=HYF+xDpGecK8ELwz80gtaiDVVCeke4W1kl7jks4dpJ5kK+70o+uudZ/0H+8MXSrogZ 3mvriynB+6e7RhsgdFUHyIM5j6ZTixjsztq4qCcq/k5GJwMpviki0sOAJ9cdfhvhkS9e aLz4pN1WVGUALCCRy8I98bYf1pM8MENAx9pWurcWIjHPzYaI/09ArTOkOWUMEG7ngZ3a ZVJ8LCP7G9+2/kKnOYSprnxsYkuZhBVdt/d5N/k3Ieqz3kBY0NvZodvx/JmrDrVWG+0g bs7LaFkjFbQjiyFYBUJ2bR+8kNS8iIi6wciDtOoZ90cGv5tJJnHFt5gft9eGA7QiMgmN jUDQ== 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 :content-transfer-encoding:message-id:references:to; bh=PRw1UDTnZLHw2vJgIg5WQ5OyUCILhKX49wPYQCOuWoQ=; b=agn5kvgFgJCxM+on7YVj23lCq+aMymxwRS2/FbYcs9lMpvxL3e7GgKyTMTCELvbmJa 2tXw/kmJUvI0UJuaAe8yHf8FmR2t4KT0tLsC8482W5vcwsxvaS9Wm6P10bf5qUVfeVlj 2QlZOWwmVkEAKWWVtpH83VLYEJd3IlspkrUTlmmzNgqCVXMeaYyq6ysT6geew9oFokqT EsSZ8g1tClsyzO+AYgqend1cMCSFsIYYJ83fjrSWSRwOQ+bjcpOfd60Pz8P4ROqImSW8 pvMTgFtCGrJNNUY9+ZQ7Lr8MasBNgbFjVQmYKN3AQYzaDaONLGEOcPwk5U1rEnvFqA0V eTkA== X-Gm-Message-State: AMke39mrBFK0IFSeVZFGqv1d/nlAUwNeVRDmpw9FEi65a/9D5tcWprpjJ2veboK7zrDKSA== X-Received: by 10.84.168.3 with SMTP id e3mr32157248plb.144.1487602155886; Mon, 20 Feb 2017 06:49:15 -0800 (PST) Received: from sjc-mahesh-nitro11.cisco.com ([128.107.241.174]) by smtp.gmail.com with ESMTPSA id p6sm4869938pgn.40.2017.02.20.06.49.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 20 Feb 2017 06:49:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <0d43dff0-3190-8600-30fa-0ec62b48b56e@cesnet.cz> Date: Mon, 20 Feb 2017 06:49:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <11A89948-DEC1-4CAF-AB89-56BDC6048BCF@gmail.com> References: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> <0d43dff0-3190-8600-30fa-0ec62b48b56e@cesnet.cz> To: =?utf-8?Q?Radek_Krej=C4=8D=C3=AD?= X-Mailer: Apple Mail (2.3124) Archived-At: Cc: yang-doctors@ietf.org Subject: Re: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 14:49:18 -0000 Ditto. > On Feb 20, 2017, at 3:56 AM, Radek Krej=C4=8D=C3=AD = wrote: >=20 > +1 >=20 > Radek >=20 >=20 > Dne 20.2.2017 v 08:06 Ladislav Lhotka napsal(a): >> Hi Andy, >>=20 >> I would be interested in attending that meeting. >>=20 >> Lada >>=20 >>> On 19 Feb 2017, at 21:05, Andy Bierman wrote: >>>=20 >>> Hi, >>>=20 >>> The CORE WG is working on some standards for an IoT version of = RESTCONF. >>> The CBOR encoding is relevant to RESTCONF for some applications like = YANG push. >>>=20 >>> I am trying to organize a side meeting about YANG to CBOR and >>> SID (numeric schema node identifiers). The goal of the meeting is >>> understand how it works (and doesn't work). Hopefully there will be = a >>> 1 hour slot open for this meeting, and a room available. >>> The first step is determining if any YANG doctors care about what >>> the CORE WG is doing with YANG. >>>=20 >>> Another topic: YANG to GPB? Better approach? Where is it documented? >>> Does an algorithm exist that works for YANG augment? >>>=20 >>> CORE WG drafts: >>>=20 >>> YANG to CBOR >>> https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ >>>=20 >>> SID >>> https://datatracker.ietf.org/doc/draft-ietf-core-sid/ >>>=20 >>>=20 >>> CoMI >>> https://datatracker.ietf.org/doc/draft-ietf-core-comi/ >>>=20 >>>=20 >>> Andy >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 > --=20 > Radek Krejci > mobile : +420 732 212 714 > office : +420 234 680 256 > e-mail : rkrejci@cesnet.cz > LinkedIn: http://www.linkedin.com/in/radekkrejci >=20 > CESNET, Association of Legal Entities > Zikova 4 > 160 00 Praha 6 > Czech Republic >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors From nobody Mon Feb 20 10:03:06 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81E51293E8 for ; Mon, 20 Feb 2017 10:03:05 -0800 (PST) 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 5kf6vjXQncwJ for ; Mon, 20 Feb 2017 10:03:04 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A31127A90 for ; Mon, 20 Feb 2017 10:03:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4761; q=dns/txt; s=iport; t=1487613784; x=1488823384; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=QTQb6gDq2vUV4WHbOJOZ7fQ3NJ2zaKg5jxOLYkTHzpE=; b=kwSmpKtU/8orEuoOpLEszlSDpJgulpuDtIXczyP2bzUUCYrCARsKmbB1 ZQgfCvM527VFSbVldUHEKMw6D6HclJMB1hlIJk7pMXN6auqlE46Balux/ apriI3YOZ/o6W3WwgcmL1+wTtM24ZTiDRSODd2qdmyX8DZaVO8z+Rl6tQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQCJLqtY/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDIDJ1+NY3KRI4gMjSiCDB8LhXgCgwsYAQIBAQEBAQEBYiiEcAE?= =?us-ascii?q?BAQQBATY2CwwECw4DBAEBAScHIQYfCQgGAQwGAgEBiVMDFQ6wIocyDYQTAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWGTIIFgmqCUYFmAQGFYR8BBJtKOo4ChBuKP4Z?= =?us-ascii?q?Lij9diAYfOIEAIBQIFxU+hEkeGYFJPzWIVAcIF4IXAQEB?= X-IronPort-AV: E=Sophos;i="5.35,187,1484006400"; d="scan'208";a="652674954" 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; 20 Feb 2017 18:03:02 +0000 Received: from [10.61.70.135] (ams3-vpn-dhcp1671.cisco.com [10.61.70.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1KI2xBN024292; Mon, 20 Feb 2017 18:03:00 GMT To: Mehmet Ersue , "'Ladislav Lhotka'" References: <006801d28b73$eec8e990$cc5abcb0$@gmail.com> <80571237-8277-4746-BB36-9A8E3FC88D90@nic.cz> <010901d28b77$9627de50$c2779af0$@gmail.com> From: Benoit Claise Message-ID: <21272db0-2d5f-c55b-631a-621ac2e5e31b@cisco.com> Date: Mon, 20 Feb 2017 19:02:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <010901d28b77$9627de50$c2779af0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: 'Benoit Claise' Subject: Re: [yang-doctors] First review entry WAS:RE: Review of draft-ietf-rtgwg-yang-key-chain-13 X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 18:03:06 -0000 On 2/20/2017 1:48 PM, Mehmet Ersue wrote: > The review form actually includes ietf@ietf.org which we also see in CC of > the automatically generated mail. I don't think that's necessary. There are too many emails anyway, and the datatracker contains the links to all the reviews. And finally, the YANG doctors emails are archived. Regards, Benoit > > Cheers, > Mehmet > >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Monday, February 20, 2017 1:38 PM >> To: Mehmet Ersue >> Cc: Benoit Claise >> Subject: Re: First review entry WAS:RE: [yang-doctors] Review of > draft-ietf- >> rtgwg-yang-key-chain-13 >> >> >>> On 20 Feb 2017, at 13:21, Mehmet Ersue wrote: >>> >>> Many Thanks Lada!!! Looks perfect. >> Well, there may be spurious line breaks depending on the width of the >> browser window. Actually, I think it would be helpful to support some kind > of >> lightweight markup such as markdown. >> >>> Though, I'm not 100% sure whether we should send such mails always to >>> ietf@ietf.org. >> Certainly not! If I correctly remember, the review form mentioned only >> draft-ietf-rtgwg-yang-key-chain.all@ietf.org and rtgwg@ietf.org to be in > Cc. >> Lada >> >>> I can imagine yang-doctors, draft authors and the related WG would be >>> sufficient. >>> >>> @Benoit: >>> What do you think? >>> >>> Cheers, >>> Mehmet >>> >>>> -----Original Message----- >>>> From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf >>>> Of Ladislav Lhotka >>>> Sent: Monday, February 20, 2017 12:50 PM >>>> To: yang-doctors@ietf.org >>>> Cc: draft-ietf-rtgwg-yang-key-chain.all@ietf.org; ietf@ietf.org; >>>> rtgwg@ietf.org >>>> Subject: [yang-doctors] Review of draft-ietf-rtgwg-yang-key-chain-13 >>>> >>>> Reviewer: Ladislav Lhotka >>>> Review result: Almost Ready >>>> >>>> # General Comments >>>> >>>> ## Cryptographic algorithm types >>>> >>>> What is the reason for representing these as a YANG choice with empty >>>> leaves? I think it would be more natural to use a single leaf, either >>>> an enumeration or (if extensibility is important) identityref. >>>> >>>> ## Reusability >>>> >>>> The module defines key-chain as a grouping with the aim of making it >>>> reusable in other modules. However, this approach has known problems >>>> that are discussed in draft-ietf-netmod-schema-mount. I am not sure >>>> how relevant they are in this case but, for one, the "key-chain-ref" >>>> type is not applicable if the "key-chain" grouping is used in another >>> module. >>>> An alternative is not to use the grouping and rely on schema mount. >>>> >>>> ## Key string style >>>> >>>> The difference between ASCII and hexadecimal formats of key strings >>>> should be explained. I understand that the latter is a hash of the >>>> key and, if >>> so, I'd >>>> suggest to include "hexadecimal-string" also in state data. >>>> >>>> Also, I believe that storing clear-text key in configuration is >>>> insecure >>> and >>>> Security Considerations should warn against it. >>>> >>>> ## Example >>>> >>>> It might be useful to include an appendix with example instance data. >>>> >>>> # Specific comments >>>> >>>> ## Sec. 2 >>>> >>>> - paragraph 2: s/where ever/wherever/ >>>> >>>> ## Sec. 3 >>>> >>>> - paragraph 1: replace both Key-Id a Key-ID with Key ID (the latter >>>> is used in other places of the >>>> text). >>>> - paragraph 2: the suggested way of supporting asymmetric keys looks >>>> like a hack, I would suggest >>>> a more explicit representation, e.g. using a choice. >>>> >>>> ## Sec. 4 >>>> >>>> - The module has inconsistent indentation: up to "grouping >>>> crypto-algorithm-types", top-level >>>> statements are indented with four spaces, the subsequent ones with >>> five >>>> spaces. >>>> >>>> ## Sec. 6 >>>> >>>> - The statement "Given that the key chains themselves are sensitive >>>> data, it is RECOMMENDED >>>> that the NETCONF communication channel be encrypted." is >>>> misleading because RFC 6241 >>>> requires that transport protocols for NETCONF guarantee >>> confidentiality >>>> (and RFC 8040 does the >>>> same for RESTCONF). >>>> >>>> >>>> _______________________________________________ >>>> yang-doctors mailing list >>>> yang-doctors@ietf.org >>>> https://www.ietf.org/mailman/listinfo/yang-doctors >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > . > From nobody Tue Feb 21 00:58:31 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95AA129892; Tue, 21 Feb 2017 00:58:19 -0800 (PST) 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 sfPZyPnEDOzU; Tue, 21 Feb 2017 00:58:18 -0800 (PST) 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 566EE129529; Tue, 21 Feb 2017 00:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11030; q=dns/txt; s=iport; t=1487667497; x=1488877097; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=wh95X+EeXE3RF1V1JLzFXCR+WWUjlpa52eLI6U5e7ZI=; b=b5wba+UvF3VTC5jces29dh0EsL/ZCcGabCMIQqv/BSv5bqHBFfQ4JpdA ZjAewJSbi8gfssuz1VuKe8RCK6sL4LOsrSpo+b4VbbGopnQKqbtB/aJc/ /+nZUCUwF2HQQ+SEEaBISjmPN53zU8+mcZe+cp4KkTsuUqz4HGBHgSLK6 o=; X-IronPort-AV: E=Sophos;i="5.35,188,1484006400"; d="scan'208,217";a="692410003" 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; 21 Feb 2017 08:58:15 +0000 Received: from [10.61.70.135] (ams3-vpn-dhcp1671.cisco.com [10.61.70.135]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v1L8wEnS023537; Tue, 21 Feb 2017 08:58:14 GMT To: Rob Shakir , Lou Berger , Jeff Tantsura , "Acee Lindem (acee)" , RTG YANG Design Team , Xufeng Liu , Yingzhen Qu References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> From: Benoit Claise Message-ID: <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> Date: Tue, 21 Feb 2017 09:58:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------562F8DECCF94E8B5A68EE02E" Archived-At: Cc: YANG Doctors , Alia Atlas Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 08:58:20 -0000 This is a multi-part message in MIME format. --------------562F8DECCF94E8B5A68EE02E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Including the YANG doctors on this important topic. Regards, Benoit > As I wrote the initial email. I can probably add some comments at the > next meeting. > > We have examined multiple times rewriting of regexps from the W3C > standard to something that is more commonly supported. And to be > frank, it's not a useful task to spend time on. Worse, the existing > IETF types modules use elements such as \p{L} when AFAICS, there is no > reason not to use [a-zA-Z] for all practical use cases (I know of no > system that has an interface that needs to be zoned to 🍺 for example). > > r. > > On Mon, 20 Feb 2017 at 17:49 Lou Berger > wrote: > > [Adding Kent as netmod co-chair, netmod AD is already on the list.] > > Jeff, > > This is an important user perspective. I personally am open to > changing the regexp reference in YANG (see [1]), *but* I think this > would required rev'ing YANG (to 1.2, for example) to do so. > > Also, in poking around, I can only find posix definitions behind > pay-walls, which may be an issue - but as IAB is responsible for IETF > liaisons, perhaps you could run this part to ground ;-) > > If Kent is agreeable, I'd be open to having an presentation and > discussion on this (even without a draft) at the next meeting. > > Kent? > > Thanks, > > Lou > > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > > HI, > > > > I have been having some discussion with OC folks (privately), > I’d really want to see convergence between OC and IETF. > > > > Below is the explanation why not to use IETF version. Do you > think there’s anything we could do (Lou?) > > > > “For types modules, there's a pretty interesting problem > (AFAICS). We have found that the W3C standard that is being used > for regexp has very limited support. We've actually forked our > types modules to stop referencing IETF ones, since we're aiming to > use a regexp standard that is more commonly supported (POSIX). > > > > When I've raised this privately, there seems to be a bunch of > opposition to even discussing such implementation questions - such > that forking and moving forward seems a much more effective > solution. Whilst I can't speak for OC, personally, I'd oppose > trying to split our types across IETF and OC as it adds to the > implementation complexity. > > > > Perhaps with your new hat, it might be possible for us to > discuss further what IETF's interest is in usability vs. > long-winded NETMOD discussions :-) that seem to reach few answers.” > > > > > > Cheers, > > Jeff > > > > > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch --------------562F8DECCF94E8B5A68EE02E Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Including the YANG doctors on this important topic.

Regards, Benoit
As I wrote the initial email. I can probably add some comments at the next meeting.

We have examined multiple times rewriting of regexps from the W3C standard to something that is more commonly supported. And to be frank, it's not a useful task to spend time on. Worse, the existing IETF types modules use elements such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z] for all practical use cases (I know of no system that has an interface that needs to be zoned to 🍺  for example).

r.

On Mon, 20 Feb 2017 at 17:49 Lou Berger <lberger@labn.net> wrote:
[Adding Kent as netmod co-chair, netmod AD is already on the list.]

Jeff,

    This is an important user perspective.  I personally am open to
changing the regexp reference in YANG (see [1]), *but* I think this
would required rev'ing YANG (to 1.2, for example) to do so.

Also, in poking around, I can only find posix definitions behind
pay-walls, which may be an issue - but as IAB is responsible for IETF
liaisons, perhaps you could run this part to ground ;-)

If Kent is agreeable, I'd be open to having an presentation and
discussion on this (even without a draft) at the next meeting.

Kent?

Thanks,

Lou

[1] https://tools.ietf.org/html/rfc7950#section-9.4.5
On 2/20/2017 7:55 PM, Jeff Tantsura wrote:
> HI,
>
> I have been having some discussion with OC folks (privately), I’d really want to see convergence between OC and IETF.
>
> Below is the explanation why not to use IETF version.  Do you think there’s anything we could do (Lou?)
>
> “For types modules, there's a pretty interesting problem (AFAICS). We have found that the W3C standard that is being used for regexp has very limited support. We've actually forked our types modules to stop referencing IETF ones, since we're aiming to use a regexp standard that is more commonly supported (POSIX).
>
> When I've raised this privately, there seems to be a bunch of opposition to even discussing such implementation questions - such that forking and moving forward seems a much more effective solution. Whilst I can't speak for OC, personally, I'd oppose trying to split our types across IETF and OC as it adds to the implementation complexity.
>
> Perhaps with your new hat, it might be possible for us to discuss further what IETF's interest is in usability vs. long-winded NETMOD discussions :-) that seem to reach few answers.”
>
>
> Cheers,
> Jeff
>
>
>
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

_______________________________________________
Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch


_______________________________________________
Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

--------------562F8DECCF94E8B5A68EE02E-- From nobody Tue Feb 21 03:21:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3641B128B38; Tue, 21 Feb 2017 03:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mkvvmUKPZlBV; Tue, 21 Feb 2017 03:21:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33D128AB0; Tue, 21 Feb 2017 03:21:08 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EDBE1AE0332; Tue, 21 Feb 2017 12:21:06 +0100 (CET) Date: Tue, 21 Feb 2017 12:21:07 +0100 (CET) Message-Id: <20170221.122107.2124509611280123175.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> References: <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: rtg-dt-yang-arch@ietf.org, lberger@labn.net, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:21:10 -0000 SGksDQoNCkZpcnN0IG9mIGFsbCwgSSBhbSBub3QgcGFydGljdWxhcmlseSBhdHRhY2hlZCB0byBh bnkgc3BlY2lmaWMgcmVnZXhwDQpmbGF2b3IsIHNvIGlmIHdlIHdlcmUgZGVzaWduaW5nIHNvbWV0 aGluZyBuZXcgSSB3b3VsZCBiZSBvcGVuIHRvIHVzaW5nDQpQT1NJWCBvciBzb21ldGhpbmcgZWxz ZS4NCg0KSSBub3RlIHRoYXQgdGhlcmUgYXJlIHNldmVyYWwgWUFORyBpbXBsZW1lbnRhdGlvbnMg b3V0IHRoZXJlIHRoYXQNCnN1Y2Nlc3NmdWxseSAqYXJlKiBpbXBsZW1lbnRpbmcgdGhlIFhNTCBy ZWdleHAgZmxhdm9yLiAgTXkgZ3Vlc3MgaXMNCnRoYXQgbW9zdCBpbnRlcm5hbGx5IHVzZSBsaWJ4 bWwyLg0KDQpJIGFsc28gbm90ZSB0aGF0IHdoaWxlIHdlIGNhbiBkaXNjdXNzIGluZGl2aWR1YWwg ZGF0YXR5cGVzLCBpdCBzZWVtcw0KcmVhc29uYWJsZSB0byBwaWNrIGEgcmVnZXhwIGRpYWxlY3Qg dGhhdCBzdXBwb3J0cyB1bmljb2RlICh3aGljaCBQT1NJWA0KZG9lc24ndCBkbykuDQoNCkJ1dCBp cyB0aGUgcHJvYmxlbSBsYWNrIG9mIGxpYnJhcnkgc3VwcG9ydCwgb3IgdGhhdCB0aGUgWFNEIHJl Z2V4cA0KZGlhbGVjdCBpcyB0b28gcHJpbWl0aXZlPyAgIEZXSVcsIFBPU0lYIGlzIGFsc28gZmFp cmx5IHNpbXBsZS4NCg0KDQovbWFydGluDQoNCg0KDQoNCg0KQmVub2l0IENsYWlzZSA8YmNsYWlz ZUBjaXNjby5jb20+IHdyb3RlOg0KPiBJbmNsdWRpbmcgdGhlIFlBTkcgZG9jdG9ycyBvbiB0aGlz IGltcG9ydGFudCB0b3BpYy4NCj4gDQo+IFJlZ2FyZHMsIEJlbm9pdA0KPiA+IEFzIEkgd3JvdGUg dGhlIGluaXRpYWwgZW1haWwuIEkgY2FuIHByb2JhYmx5IGFkZCBzb21lIGNvbW1lbnRzIGF0IHRo ZQ0KPiA+IG5leHQgbWVldGluZy4NCj4gPg0KPiA+IFdlIGhhdmUgZXhhbWluZWQgbXVsdGlwbGUg dGltZXMgcmV3cml0aW5nIG9mIHJlZ2V4cHMgZnJvbSB0aGUgVzNDDQo+ID4gc3RhbmRhcmQgdG8g c29tZXRoaW5nIHRoYXQgaXMgbW9yZSBjb21tb25seSBzdXBwb3J0ZWQuIEFuZCB0byBiZQ0KPiA+ IGZyYW5rLCBpdCdzIG5vdCBhIHVzZWZ1bCB0YXNrIHRvIHNwZW5kIHRpbWUgb24uIFdvcnNlLCB0 aGUgZXhpc3RpbmcNCj4gPiBJRVRGIHR5cGVzIG1vZHVsZXMgdXNlIGVsZW1lbnRzIHN1Y2ggYXMg XHB7TH0gd2hlbiBBRkFJQ1MsIHRoZXJlIGlzIG5vDQo+ID4gcmVhc29uIG5vdCB0byB1c2UgW2Et ekEtWl0gZm9yIGFsbCBwcmFjdGljYWwgdXNlIGNhc2VzIChJIGtub3cgb2Ygbm8NCj4gPiBzeXN0 ZW0gdGhhdCBoYXMgYW4gaW50ZXJmYWNlIHRoYXQgbmVlZHMgdG8gYmUgem9uZWQgdG8g8J+NuiBm b3IgZXhhbXBsZSkuDQo+ID4NCj4gPiByLg0KPiA+DQo+ID4gT24gTW9uLCAyMCBGZWIgMjAxNyBh dCAxNzo0OSBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0DQo+ID4gPG1haWx0bzpsYmVyZ2Vy QGxhYm4ubmV0Pj4gd3JvdGU6DQo+ID4NCj4gPiAgICAgW0FkZGluZyBLZW50IGFzIG5ldG1vZCBj by1jaGFpciwgbmV0bW9kIEFEIGlzIGFscmVhZHkgb24gdGhlIGxpc3QuXQ0KPiA+DQo+ID4gICAg IEplZmYsDQo+ID4NCj4gPiAgICAgICAgIFRoaXMgaXMgYW4gaW1wb3J0YW50IHVzZXIgcGVyc3Bl Y3RpdmUuICBJIHBlcnNvbmFsbHkgYW0gb3BlbiB0bw0KPiA+ICAgICBjaGFuZ2luZyB0aGUgcmVn ZXhwIHJlZmVyZW5jZSBpbiBZQU5HIChzZWUgWzFdKSwgKmJ1dCogSSB0aGluayB0aGlzDQo+ID4g ICAgIHdvdWxkIHJlcXVpcmVkIHJldidpbmcgWUFORyAodG8gMS4yLCBmb3IgZXhhbXBsZSkgdG8g ZG8gc28uDQo+ID4NCj4gPiAgICAgQWxzbywgaW4gcG9raW5nIGFyb3VuZCwgSSBjYW4gb25seSBm aW5kIHBvc2l4IGRlZmluaXRpb25zIGJlaGluZA0KPiA+ICAgICBwYXktd2FsbHMsIHdoaWNoIG1h eSBiZSBhbiBpc3N1ZSAtIGJ1dCBhcyBJQUIgaXMgcmVzcG9uc2libGUgZm9yIElFVEYNCj4gPiAg ICAgbGlhaXNvbnMsIHBlcmhhcHMgeW91IGNvdWxkIHJ1biB0aGlzIHBhcnQgdG8gZ3JvdW5kIDst KQ0KPiA+DQo+ID4gICAgIElmIEtlbnQgaXMgYWdyZWVhYmxlLCBJJ2QgYmUgb3BlbiB0byBoYXZp bmcgYW4gcHJlc2VudGF0aW9uIGFuZA0KPiA+ICAgICBkaXNjdXNzaW9uIG9uIHRoaXMgKGV2ZW4g d2l0aG91dCBhIGRyYWZ0KSBhdCB0aGUgbmV4dCBtZWV0aW5nLg0KPiA+DQo+ID4gICAgIEtlbnQ/ DQo+ID4NCj4gPiAgICAgVGhhbmtzLA0KPiA+DQo+ID4gICAgIExvdQ0KPiA+DQo+ID4gICAgIFsx XSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTkuNC41DQo+ID4g ICAgIE9uIDIvMjAvMjAxNyA3OjU1IFBNLCBKZWZmIFRhbnRzdXJhIHdyb3RlOg0KPiA+ICAgICA+ IEhJLA0KPiA+ICAgICA+DQo+ID4gICAgID4gSSBoYXZlIGJlZW4gaGF2aW5nIHNvbWUgZGlzY3Vz c2lvbiB3aXRoIE9DIGZvbGtzIChwcml2YXRlbHkpLA0KPiA+ICAgICBJ4oCZZCByZWFsbHkgd2Fu dCB0byBzZWUgY29udmVyZ2VuY2UgYmV0d2VlbiBPQyBhbmQgSUVURi4NCj4gPiAgICAgPg0KPiA+ ICAgICA+IEJlbG93IGlzIHRoZSBleHBsYW5hdGlvbiB3aHkgbm90IHRvIHVzZSBJRVRGIHZlcnNp b24uICBEbyB5b3UNCj4gPiAgICAgdGhpbmsgdGhlcmXigJlzIGFueXRoaW5nIHdlIGNvdWxkIGRv IChMb3U/KQ0KPiA+ICAgICA+DQo+ID4gICAgID4g4oCcRm9yIHR5cGVzIG1vZHVsZXMsIHRoZXJl J3MgYSBwcmV0dHkgaW50ZXJlc3RpbmcgcHJvYmxlbQ0KPiA+ICAgICAoQUZBSUNTKS4gV2UgaGF2 ZSBmb3VuZCB0aGF0IHRoZSBXM0Mgc3RhbmRhcmQgdGhhdCBpcyBiZWluZyB1c2VkDQo+ID4gICAg IGZvciByZWdleHAgaGFzIHZlcnkgbGltaXRlZCBzdXBwb3J0LiBXZSd2ZSBhY3R1YWxseSBmb3Jr ZWQgb3VyDQo+ID4gICAgIHR5cGVzIG1vZHVsZXMgdG8gc3RvcCByZWZlcmVuY2luZyBJRVRGIG9u ZXMsIHNpbmNlIHdlJ3JlIGFpbWluZyB0bw0KPiA+ICAgICB1c2UgYSByZWdleHAgc3RhbmRhcmQg dGhhdCBpcyBtb3JlIGNvbW1vbmx5IHN1cHBvcnRlZCAoUE9TSVgpLg0KPiA+ICAgICA+DQo+ID4g ICAgID4gV2hlbiBJJ3ZlIHJhaXNlZCB0aGlzIHByaXZhdGVseSwgdGhlcmUgc2VlbXMgdG8gYmUg YSBidW5jaCBvZg0KPiA+ICAgICBvcHBvc2l0aW9uIHRvIGV2ZW4gZGlzY3Vzc2luZyBzdWNoIGlt cGxlbWVudGF0aW9uIHF1ZXN0aW9ucyAtIHN1Y2gNCj4gPiAgICAgdGhhdCBmb3JraW5nIGFuZCBt b3ZpbmcgZm9yd2FyZCBzZWVtcyBhIG11Y2ggbW9yZSBlZmZlY3RpdmUNCj4gPiAgICAgc29sdXRp b24uIFdoaWxzdCBJIGNhbid0IHNwZWFrIGZvciBPQywgcGVyc29uYWxseSwgSSdkIG9wcG9zZQ0K PiA+ICAgICB0cnlpbmcgdG8gc3BsaXQgb3VyIHR5cGVzIGFjcm9zcyBJRVRGIGFuZCBPQyBhcyBp dCBhZGRzIHRvIHRoZQ0KPiA+ICAgICBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KPiA+ICAg ICA+DQo+ID4gICAgID4gUGVyaGFwcyB3aXRoIHlvdXIgbmV3IGhhdCwgaXQgbWlnaHQgYmUgcG9z c2libGUgZm9yIHVzIHRvDQo+ID4gICAgIGRpc2N1c3MgZnVydGhlciB3aGF0IElFVEYncyBpbnRl cmVzdCBpcyBpbiB1c2FiaWxpdHkgdnMuDQo+ID4gICAgIGxvbmctd2luZGVkIE5FVE1PRCBkaXNj dXNzaW9ucyA6LSkgdGhhdCBzZWVtIHRvIHJlYWNoIGZldyBhbnN3ZXJzLuKAnQ0KPiA+ICAgICA+ DQo+ID4gICAgID4NCj4gPiAgICAgPiBDaGVlcnMsDQo+ID4gICAgID4gSmVmZg0KPiA+ICAgICA+ DQo+ID4gICAgID4NCj4gPiAgICAgPg0KPiA+ICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gICAgID4gUnRnLWR0LXlhbmctYXJjaCBtYWls aW5nIGxpc3QNCj4gPiAgICAgPiBSdGctZHQteWFuZy1hcmNoQGlldGYub3JnIDxtYWlsdG86UnRn LWR0LXlhbmctYXJjaEBpZXRmLm9yZz4NCj4gPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J0Zy1kdC15YW5nLWFyY2gNCj4gPg0KPiA+ICAgICBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICBSdGctZHQteWFu Zy1hcmNoIG1haWxpbmcgbGlzdA0KPiA+ICAgICBSdGctZHQteWFuZy1hcmNoQGlldGYub3JnIDxt YWlsdG86UnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZz4NCj4gPiAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGctZHQteWFuZy1hcmNoDQo+ID4NCj4gPg0KPiA+DQo+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBS dGctZHQteWFuZy1hcmNoIG1haWxpbmcgbGlzdA0KPiA+IFJ0Zy1kdC15YW5nLWFyY2hAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy1kdC15YW5n LWFyY2gNCj4gDQo= From nobody Tue Feb 21 07:29:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13C129409 for ; Tue, 21 Feb 2017 07:29:55 -0800 (PST) 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_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=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 GqPrZSG4ZJvI for ; Tue, 21 Feb 2017 07:29:54 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0123.outbound.protection.outlook.com [104.47.38.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF9D126CD8 for ; Tue, 21 Feb 2017 07:29:53 -0800 (PST) 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=+spSjgEzXI6Elve7FKs1N30+kEMb+pdgsyNl/UVYdMs=; b=A1+7cZzLV2mJyovHyZUPrT+F6Ldz/GV7xRZB5BqmfqfKz/xMqguG+TfSt7CxbryEwCX5ldcZsZvGaNaIuq34VNpl8jnrxslcIDU4DKM85bV6fsZ3cdq3BbV54i0y8fOaCOy/A5MGQR4R0wkZn3ObGIRNmdBdfcFiDykaNUjDkbg= 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_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 21 Feb 2017 15:29: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.0919.018; Tue, 21 Feb 2017 15:29:52 +0000 From: Kent Watsen To: Mahesh Jethanandani , =?utf-8?B?UmFkZWsgS3JlasSNw60=?= Thread-Topic: [yang-doctors] binary encoded YANG data: side meeting in Chicago? Thread-Index: AQHSjFdYo2f2N8WHfkSBLXwhuEj7nA== Date: Tue, 21 Feb 2017 15:29:51 +0000 Message-ID: References: <497E64EB-61F1-4D47-8EBD-A9C80EA0915D@nic.cz> <0d43dff0-3190-8600-30fa-0ec62b48b56e@cesnet.cz> <11A89948-DEC1-4CAF-AB89-56BDC6048BCF@gmail.com> In-Reply-To: <11A89948-DEC1-4CAF-AB89-56BDC6048BCF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: 55cb5c52-f929-4eaf-a4ba-08d45a6e7afb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1444; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 7:14QV1ng2xpVtoTQbSlvJrm/xGT71DMTaUba02+E2ZVU44O8xE9Cy8S/JN7vq9XOWUwUNFM4LQWzqUU5zwnDEwIc8al2iFFyuRn89wvGdNQ0Bk3GaU5+sPAqN7jaEX1nKF4VZGPjC68W1jHO6NUUdbuuHnURoOhx0i2Lus+TAgfvgEw1d4kAdvDt1EWoELrNLgfk3+J9Vvhwb/OUqfuZnGlNaelayZSNUHItg/szBYwQnqit5qjMISaqcS5HquWI8GluOUMaL6ULtQ7hezwetSqEBjC64d9iwucyUia34LNyxwKgKC4UVpao/K5RVGHXbYSgCUehJwxUIadqsxeX2Bw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39450400003)(39840400002)(377454003)(24454002)(199003)(189002)(39060400002)(92566002)(558084003)(76176999)(54356999)(189998001)(2900100001)(5660300001)(38730400002)(3846002)(102836003)(6116002)(105586002)(4001350100001)(97736004)(106116001)(68736007)(106356001)(2906002)(305945005)(33656002)(3280700002)(7736002)(53936002)(93886004)(101416001)(2950100002)(36756003)(6436002)(50986999)(6246003)(8676002)(25786008)(99286003)(6512007)(77096006)(6486002)(81156014)(82746002)(81166006)(6506006)(83716003)(83506001)(8936002)(229853002)(66066001)(86362001)(3660700001)(4326007)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) 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: 21 Feb 2017 15:29:51.9985 (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: Cc: "yang-doctors@ietf.org" Subject: Re: [yang-doctors] binary encoded YANG data: side meeting in Chicago? X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:29:55 -0000 DQpMaWtld2lzZQ0KDQpLZW50DQoNCg0KPkRpdHRvLg0KPg0KPj4gT24gRmViIDIwLCAyMDE3LCBh dCAzOjU2IEFNLCBSYWRlayBLcmVqxI3DrSA8cmtyZWpjaUBjZXNuZXQuY3o+IHdyb3RlOg0KPj4g DQo+PiArMQ0KPj4gDQo+PiBSYWRlaw0KPj4gDQo+PiANCj4+PiBEbmUgMjAuMi4yMDE3IHYgMDg6 MDYgTGFkaXNsYXYgTGhvdGthIG5hcHNhbChhKToNCj4+PiBIaSBBbmR5LA0KPj4+IA0KPj4+IEkg d291bGQgYmUgaW50ZXJlc3RlZCBpbiBhdHRlbmRpbmcgdGhhdCBtZWV0aW5nLg0KPj4+IA0KPj4+ IExhZGENCj4+PiANCg0KDQo= From nobody Tue Feb 21 09:14:48 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C00912948F; Tue, 21 Feb 2017 09:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 8gsxXsraTj1U; Tue, 21 Feb 2017 09:14:41 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B64B712945B; Tue, 21 Feb 2017 09:08:18 -0800 (PST) Received: from localhost (unknown [172.29.2.202]) by trail.lhotka.name (Postfix) with ESMTPSA id E19C91820009; Tue, 21 Feb 2017 18:06:50 +0100 (CET) From: Ladislav Lhotka To: Martin Bjorklund , bclaise@cisco.com In-Reply-To: <20170221.122107.2124509611280123175.mbj@tail-f.com> References: <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> <20170221.122107.2124509611280123175.mbj@tail-f.com> Date: Tue, 21 Feb 2017 18:08:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:14:43 -0000 Martin Bjorklund writes: > Hi, > > First of all, I am not particularily attached to any specific regexp > flavor, so if we were designing something new I would be open to using > POSIX or something else. >From the narrow viewpoint of the regex language design, the W3C XML Schema flavour is probably the most appropriate as it is specifically designed for use in schema languages. For example, it is a good thing that the ^ and $ anchors are not needed. However, ...=20=20 > > I note that there are several YANG implementations out there that > successfully *are* implementing the XML regexp flavor. My guess is > that most internally use libxml2. AFAICT, libxml2 is not available for Python 3, so I am currently using the PyXB module, it works but it would certainly be easier to use a built-in module. I guess it is the same in most other languages: a native regex package exists but it is specific to that language. > > I also note that while we can discuss individual datatypes, it seems > reasonable to pick a regexp dialect that supports unicode (which POSIX > doesn't do). This is a showstopper. > > But is the problem lack of library support, or that the XSD regexp > dialect is too primitive? FWIW, POSIX is also fairly simple. I wouldn't say that it is too primitive - we haven't much use e.g. for groups. I don't see any better alternative, so my preference is to stick to XSD. Lada > > > /martin > > > > > > Benoit Claise wrote: >> Including the YANG doctors on this important topic. >>=20 >> Regards, Benoit >> > As I wrote the initial email. I can probably add some comments at the >> > next meeting. >> > >> > We have examined multiple times rewriting of regexps from the W3C >> > standard to something that is more commonly supported. And to be >> > frank, it's not a useful task to spend time on. Worse, the existing >> > IETF types modules use elements such as \p{L} when AFAICS, there is no >> > reason not to use [a-zA-Z] for all practical use cases (I know of no >> > system that has an interface that needs to be zoned to =F0=9F=8D=BA fo= r example). >> > >> > r. >> > >> > On Mon, 20 Feb 2017 at 17:49 Lou Berger > > > wrote: >> > >> > [Adding Kent as netmod co-chair, netmod AD is already on the list.] >> > >> > Jeff, >> > >> > This is an important user perspective. I personally am open to >> > changing the regexp reference in YANG (see [1]), *but* I think this >> > would required rev'ing YANG (to 1.2, for example) to do so. >> > >> > Also, in poking around, I can only find posix definitions behind >> > pay-walls, which may be an issue - but as IAB is responsible for I= ETF >> > liaisons, perhaps you could run this part to ground ;-) >> > >> > If Kent is agreeable, I'd be open to having an presentation and >> > discussion on this (even without a draft) at the next meeting. >> > >> > Kent? >> > >> > Thanks, >> > >> > Lou >> > >> > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 >> > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: >> > > HI, >> > > >> > > I have been having some discussion with OC folks (privately), >> > I=E2=80=99d really want to see convergence between OC and IETF. >> > > >> > > Below is the explanation why not to use IETF version. Do you >> > think there=E2=80=99s anything we could do (Lou?) >> > > >> > > =E2=80=9CFor types modules, there's a pretty interesting problem >> > (AFAICS). We have found that the W3C standard that is being used >> > for regexp has very limited support. We've actually forked our >> > types modules to stop referencing IETF ones, since we're aiming to >> > use a regexp standard that is more commonly supported (POSIX). >> > > >> > > When I've raised this privately, there seems to be a bunch of >> > opposition to even discussing such implementation questions - such >> > that forking and moving forward seems a much more effective >> > solution. Whilst I can't speak for OC, personally, I'd oppose >> > trying to split our types across IETF and OC as it adds to the >> > implementation complexity. >> > > >> > > Perhaps with your new hat, it might be possible for us to >> > discuss further what IETF's interest is in usability vs. >> > long-winded NETMOD discussions :-) that seem to reach few answers.= =E2=80=9D >> > > >> > > >> > > Cheers, >> > > Jeff >> > > >> > > >> > > >> > > _______________________________________________ >> > > Rtg-dt-yang-arch mailing list >> > > Rtg-dt-yang-arch@ietf.org >> > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >> > >> > _______________________________________________ >> > Rtg-dt-yang-arch mailing list >> > Rtg-dt-yang-arch@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >> > >> > >> > >> > _______________________________________________ >> > Rtg-dt-yang-arch mailing list >> > Rtg-dt-yang-arch@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >>=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Feb 21 09:25:04 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A434B129505 for ; Tue, 21 Feb 2017 09:25:03 -0800 (PST) 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 QJ1s6Lw0fi99 for ; Tue, 21 Feb 2017 09:25:01 -0800 (PST) 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 E2AE712952E for ; Tue, 21 Feb 2017 09:25:00 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id r141so81519785wmg.1 for ; Tue, 21 Feb 2017 09:25:00 -0800 (PST) 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=uPVdtIKswqRLSoI4tHP7bjlTsBSZwpXqV0Z9qsXHSq4=; b=yI9Cf7BB7+czfjUDaBHSktc9J3zo64NJemGfTiz9Ta0PFaIYChd4vwEGkf2Zwexh5j 2tdBHOlcM7swtkCPX2W4H1K2tWG+A4tlR+3g7WgkfQfgqpKcLJA/mUpSrqmQRN6GVatC h2/IgKBDOmq8/7adEkLDoR4tzHrcj2Fo9OzIz0BSs1d40l4OOT2EYbqDIoj3yd308dXQ EghSGs0/o9E4svVTdD6mLWc/NSLqBh4UZAmrH2luAmQV5Z6fnuNSfu1vFDs21S0XQvif OaCjbiWf4Oj0kg5U5+KeWYYmJJMc+tozE+ceSuCd3FDors99RbAtfIlxGLFgtUDQZsgn EFLQ== 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=uPVdtIKswqRLSoI4tHP7bjlTsBSZwpXqV0Z9qsXHSq4=; b=lN8rUvL8bj3RiMIckaotJHy6fidHiMOFf/3q9dYpaZCVfTpvvs/t3JkNQvMRgGuzNv QRWFvhhWK5AUNm8NNhs651AASFlGPxzc3t5uyv3dof2D6OQURpoteH5k78x9JMfamRSY +KNiLFcHDe18p8KvqUCibDJMcTrlr2tS349iOAYw9EKo7Fmr1RBItLk/cyLSM8rBeGhp i7XjM8kkjMHrNzZP7Rn62/AdCx2scxyL2SXlPlrmGG/9jq+Jvmq+ggyyarl48C22s3sB V0t8E1HqMJq95yB9Xw8OYwUZqz9keP/mQR+a57caTavcFNRcw/r/HrIxEQs2VKgrIm/e CDCQ== X-Gm-Message-State: AMke39nw0e790+56nlj3EuN4m4ABahJGFCaUJLiR6swTxLjIK+w6p9m4SmhjJSUwdgKEN2jxydo1Kn7Wgpb6Jg== X-Received: by 10.28.46.73 with SMTP id u70mr25149327wmu.54.1487697899331; Tue, 21 Feb 2017 09:24:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Tue, 21 Feb 2017 09:24:58 -0800 (PST) In-Reply-To: <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> From: Andy Bierman Date: Tue, 21 Feb 2017 09:24:58 -0800 Message-ID: To: Benoit Claise Content-Type: multipart/alternative; boundary=001a114240b0d2b9d705490da840 Archived-At: Cc: RTG YANG Design Team , Lou Berger , Xufeng Liu , Yingzhen Qu , Alia Atlas , YANG Doctors , Jeff Tantsura , Rob Shakir , "Acee Lindem \(acee\)" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:25:03 -0000 --001a114240b0d2b9d705490da840 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Maybe the openconfig folks are just looking for reasons to ignore the IETF modules. Implementation details such as regexp are not the type of thing the IETF discusses at length. libxml2 is widely deployed, so "lack of implementations" does not seem true. Google has over 900 opensource projects listed on github: https://github.com/google You would think they would have an implementation of this regexp in there somewhere. ;-) It would require a new version of YANG that breaks backward compatibility with v1.0 and 1.1 to change this. Not sure it is really worth it. Andy On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise wrote: > Including the YANG doctors on this important topic. > > Regards, Benoit > > As I wrote the initial email. I can probably add some comments at the nex= t > meeting. > > We have examined multiple times rewriting of regexps from the W3C standar= d > to something that is more commonly supported. And to be frank, it's not a > useful task to spend time on. Worse, the existing IETF types modules use > elements such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z= ] > for all practical use cases (I know of no system that has an interface th= at > needs to be zoned to =F0=9F=8D=BA for example). > > r. > > On Mon, 20 Feb 2017 at 17:49 Lou Berger wrote: > >> [Adding Kent as netmod co-chair, netmod AD is already on the list.] >> >> Jeff, >> >> This is an important user perspective. I personally am open to >> changing the regexp reference in YANG (see [1]), *but* I think this >> would required rev'ing YANG (to 1.2, for example) to do so. >> >> Also, in poking around, I can only find posix definitions behind >> pay-walls, which may be an issue - but as IAB is responsible for IETF >> liaisons, perhaps you could run this part to ground ;-) >> >> If Kent is agreeable, I'd be open to having an presentation and >> discussion on this (even without a draft) at the next meeting. >> >> Kent? >> >> Thanks, >> >> Lou >> >> [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 >> On 2/20/2017 7:55 PM, Jeff Tantsura wrote: >> > HI, >> > >> > I have been having some discussion with OC folks (privately), I=E2=80= =99d >> really want to see convergence between OC and IETF. >> > >> > Below is the explanation why not to use IETF version. Do you think >> there=E2=80=99s anything we could do (Lou?) >> > >> > =E2=80=9CFor types modules, there's a pretty interesting problem (AFAI= CS). We >> have found that the W3C standard that is being used for regexp has very >> limited support. We've actually forked our types modules to stop >> referencing IETF ones, since we're aiming to use a regexp standard that = is >> more commonly supported (POSIX). >> > >> > When I've raised this privately, there seems to be a bunch of >> opposition to even discussing such implementation questions - such that >> forking and moving forward seems a much more effective solution. Whilst = I >> can't speak for OC, personally, I'd oppose trying to split our types acr= oss >> IETF and OC as it adds to the implementation complexity. >> > >> > Perhaps with your new hat, it might be possible for us to discuss >> further what IETF's interest is in usability vs. long-winded NETMOD >> discussions :-) that seem to reach few answers.=E2=80=9D >> > >> > >> > Cheers, >> > Jeff >> > >> > >> > >> > _______________________________________________ >> > Rtg-dt-yang-arch mailing list >> > Rtg-dt-yang-arch@ietf.org >> > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >> >> _______________________________________________ >> Rtg-dt-yang-arch mailing list >> Rtg-dt-yang-arch@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch >> > > > _______________________________________________ > Rtg-dt-yang-arch mailing listRtg-dt-yang-arch@ietf.orghttps://www.ietf.or= g/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a114240b0d2b9d705490da840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


Maybe the openconfig= folks are just looking for reasons to ignore the IETF modules.
I= mplementation details such as regexp are not the type of thing the IETF
discusses at length. =C2=A0libxml2 is widely deployed, so "lack= of implementations"
does not seem true.

Google has over 900 opensource projects listed on github:
<= a href=3D"https://github.com/google">https://github.com/google

You would think they would have an implementation of t= his regexp in there somewhere. ;-)

It would requir= e a new version of YANG that breaks backward compatibility
with v= 1.0 and 1.1 to change this. Not sure it is really worth it.

<= /div>

Andy


On Tue, Feb 21, 2017 at 12:58 AM, Be= noit Claise <bclaise@cisco.com> wrote:
=20 =20 =20
Including the YANG = doctors on this important topic.

Regards, Benoit
=20
As I wrote the initial email. I can probably add some comments at the next meeting.

We have examined multiple times rewriting of regexps from the W3C standard to something that is more commonly supported. And to be frank, it's not a useful task to spend time on. Worse, the existing IETF types modules use elements such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z] for all practical use cases (I know of no system that has an interface that needs to be zoned to =F0=9F=8D=BA =C2=A0for exampl= e).

r.

On Mon, 20 Feb 2017 at 17:49 Lou Berger <lberger@labn.net> wrote:
[Adding Kent as netmod co-chair, netmod AD is already on the list.]

Jeff,

=C2=A0 =C2=A0 This is an important user perspective.=C2=A0 I pers= onally am open to
changing the regexp reference in YANG (see [1]), *but* I think this
would required rev'ing YANG (to 1.2, for example) to do so.
Also, in poking around, I can only find posix definitions behind
pay-walls, which may be an issue - but as IAB is responsible for IETF
liaisons, perhaps you could run this part to ground ;-)

If Kent is agreeable, I'd be open to having an presentation and
discussion on this (even without a draft) at the next meeting.
Kent?

Thanks,

Lou

[1] https://tools.ietf.org/html/rfc7950#section-9.4.5
On 2/20/2017 7:55 PM, Jeff Tantsura wrote:
> HI,
>
> I have been having some discussion with OC folks (privately), I=E2=80=99d really want to see convergence between O= C and IETF.
>
> Below is the explanation why not to use IETF version.=C2=A0 = Do you think there=E2=80=99s anything we could do (Lou?)
>
> =E2=80=9CFor types modules, there's a pretty interesting= problem (AFAICS). We have found that the W3C standard that is being used for regexp has very limited support. We've actually forked our types modules to stop referencing IETF ones, since we're aiming to use a regexp standard that is more commonly supported (POSIX).
>
> When I've raised this privately, there seems to be a bunch of opposition to even discussing such implementation questions - such that forking and moving forward seems a much more effective solution. Whilst I can't speak for OC, personally, I'd oppose trying to split our types across IETF and OC as it adds to the implementation complexity.
>
> Perhaps with your new hat, it might be possible for us to discuss further what IETF's interest is in usability vs. long-winded NETMOD discussions :-) that seem to reach few answers.=E2=80=9D
>
>
> Cheers,
> Jeff
>
>
>
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch=

_______________________________________________
Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch


_______________________________________________
Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://www.=
ietf.org/mailman/listinfo/rtg-dt-yang-arch


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--001a114240b0d2b9d705490da840-- From nobody Tue Feb 21 09:27:15 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2309D129519; Tue, 21 Feb 2017 09:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gLJJAPTrqfWx; Tue, 21 Feb 2017 09:27:05 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C3631129505; Tue, 21 Feb 2017 09:27:05 -0800 (PST) Received: from tops.chopps.org (97-83-46-222.dhcp.trcy.mi.charter.com [97.83.46.222]) (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 B176A61B30; Tue, 21 Feb 2017 17:27:03 +0000 (UTC) References: <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> <20170221.122107.2124509611280123175.mbj@tail-f.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Ladislav Lhotka In-reply-to: Date: Tue, 21 Feb 2017 12:27:02 -0500 Message-ID: <87a89fxxnd.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: rtg-dt-yang-arch@ietf.org, Xufeng_Liu@jabil.com, lberger@labn.net, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, acee@cisco.com, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:27:07 -0000 --=-=-= Content-Type: text/plain Ladislav Lhotka writes: > Martin Bjorklund writes: >> I also note that while we can discuss individual datatypes, it seems >> reasonable to pick a regexp dialect that supports unicode (which POSIX >> doesn't do). > > This is a showstopper. I'm sympathetic to supporting unicode, and while I don't wish to debate the point personally, it clearly is not stopping actual users. They appear to be voting with their feet. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAliseGYACgkQLh2DDte4 MCWcog/8Cyaim35uAzO4S+HfbNtnBdbeUXv26CQFqKUZEnbXvn38l3QarDONMV8z impZhQF9yse1ssIOkC7T0VSQFrqbhoq1O5DjZdGyhT4jei0Z/KgFCgmwEIQEYwTV TCNUMzHK0TUkVBnBU/fBlTBQ1pmWBjFUCRKb1vGltHJJlprpUwogDcLBgIicDf3J rZtezGZCWS6iXKP/gUw7XZwxOVVPOdZ0+znxoPPozeUg9sJJ4wLSv21GwQSgFaLg Gqac1h08JRaNHN9yJcXYRkKXCJkPB6rCGdo5UwrbJcAEThPb23+wtwULoKJEFsya YdFsnaMG7klmmXUxCXKi4KA2p85dgTUllwIUVWbavRaEP4V9iHLbcNEGSKiJd33z 4SlHGhTBOFmhaFSlqdFSOF+NhSSyZ7HpsXHJMFa3luIylQQ6idXUyiou6w6V+xGE SDSGQPFQdMh5/P/Rd0s09QoTPNdOkDq350AOA9suRwc76uz+yO5KBKOANnRq/5pk fuRKSA9wXIn/T1ZLJHRwhAlyFOC7t+EPO8XAmNJoPrZCPVrKt10STvYDB3GR9goT yAjTBCimzsul6zBrvdVfRKhoZPqMnESMkcg0XCa4fMTQnxgvxuxmI92aCbSWaOe7 A29ORmluXtDELv9lPfcG96Dfta48m1CvbZZl9DudGeLds1xO4oM= =p5+y -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 21 09:33:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5FF129517; Tue, 21 Feb 2017 09:33:17 -0800 (PST) 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_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=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 o7rd5Bs_pX98; Tue, 21 Feb 2017 09:33:14 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0119.outbound.protection.outlook.com [104.47.41.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16FF12952E; Tue, 21 Feb 2017 09:33:12 -0800 (PST) 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=f6Ha6Ek3sUwyxLfz7a07qbisJmfMXxHYOGP1jNKZTfg=; b=WMqN9Vp7cKbvSTtB8+H2svQaf0axRUJVPo58Z9dLXtyqeH9wL80ZMoUgnsYEDR94GgAJ6T5JfgqteWc0jWf8IIVdm6WVggJimk5HMW62sXviuqx1/SEhgeGUG0IuM4ZoFIYTE76xriVcM5ZgC/wfnpvX7L14U3cO7NIDljrNm5k= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1219.namprd05.prod.outlook.com (10.160.113.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Tue, 21 Feb 2017 17:33:10 +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.0919.018; Tue, 21 Feb 2017 17:33:10 +0000 From: Kent Watsen To: Andy Bierman , Benoit Claise Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types Thread-Index: AQHSi+StkdIR7osOm0ei4kB8g34eIqFzEfkAgAAXggCAAI2VAP//rneA Date: Tue, 21 Feb 2017 17:33:10 +0000 Message-ID: References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: ffd56a78-e007-40e2-f198-08d45a7fb4e7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1219; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1219; 7:RgH+eTvKwvlKac/BiIECAWZKzQvSUtITe6p4/Hi3s/FKYZ+9cAkDvw4PR28ci0YCA1otDP+8wz8046yEzLiihRLUCqtDADIln/ZX3GG9+HEKeFRuyuJB+zxAA0GuNGhddKrTmP9XwPeyU/5npZ9HYjqZFv481ZxCQRqGawVGZ9YVQkHzGtkO86UvzrKZcTEl3KSzaYH4hhGRJcNLcXj3Dd2Yet6mw8HLFx0Z5MHCc53JDlyFBkLohzuGnrF1b9ehZuS7+zm7n/GyVvEaHcAkwotbtAA2QGAYFFOr0yCQrJKdVspQEkUyMoXTL8RRTCbqZ11f1g9LZENazjs6OEYwDw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(131327999870524)(95692535739014)(21748063052155)(5213294742642); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1219; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1219; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39410400002)(39450400003)(39850400002)(39840400002)(39860400002)(24454002)(377454003)(51444003)(199003)(189002)(36756003)(6116002)(25786008)(82746002)(5660300001)(83506001)(3846002)(102836003)(3660700001)(92566002)(66066001)(54906002)(2906002)(33656002)(229853002)(83716003)(3280700002)(99286003)(236005)(54896002)(6512007)(6306002)(6506006)(230783001)(2950100002)(101416001)(122556002)(105586002)(106356001)(53546006)(189998001)(81166006)(97736004)(81156014)(7736002)(77096006)(606005)(6486002)(4326007)(76176999)(7906003)(6436002)(8676002)(50986999)(54356999)(4001350100001)(7416002)(86362001)(68736007)(8936002)(2900100001)(39060400002)(106116001)(6246003)(38730400002)(107886003)(93886004)(53936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1219; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AF735E2B2EF64C3FA833E400BAE00A10junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 17:33:10.6907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1219 Archived-At: Cc: RTG YANG Design Team , Rob Shakir , Phil Shafer , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Lou Berger , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:33:18 -0000 --_000_AF735E2B2EF64C3FA833E400BAE00A10junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WytwaGlsXQ0KDQpNeSBjaGFpciByZXNwb25zZSBpcyB0aGF0IHdlJ2QgbmVlZCB0byBzZWUgaWYg dGhlcmUgaXMgc3VmZmljaWVudCBXRyBpbnRlcmVzdCB0byBwcm9wb3NlIG1ha2luZyBhIGNoYW5n ZS4gIENlcnRhaW5seSwgYSBzb2x1dGlvbiB0aGF0IGNvdWxkIGF1Z21lbnQgdGhlIGV4aXN0aW5n IHNvbHV0aW9uIGluIGEgd2F5IHRoYXQgZGlkbid0IGJyZWFrIGV4aXN0aW5nIGNsaWVudHMgd2l0 aG91dCB3YXJuaW5nIHdvdWxkIGJlIGdvb2QgKGUuZy4sIFlBTkctbmV4dCkuDQoNCk15IGNvbnRy aWJ1dG9yIHJlc3BvbnNlIGlzIHRoYXQgSlVOT1MgYWxzbyBzdHJ1Z2dsZXMgdG8gc3VwcG9ydCBY U0QgcmVnZXguICBJbiBmYWN0LCBJIHRoaW5rIHRoYXQgaXQgaGFzIGFsd2F5cyB1c2VkIFBPU0lY IHJlZ2V4IGFuZCBjb250aW51ZXMgdG8gZG8gc28gdG8gdGhpcyBkYXkuICBQaGlsIG1pZ2h0IGhh dmUgbW9yZSB0byBzYXkgb24gdGhpcyBwb2ludC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KT24g Mi8yMS8xNywgMTI6MjQgUE0sICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KDQpIaSwNCg0KDQpNYXliZSB0aGUgb3Bl bmNvbmZpZyBmb2xrcyBhcmUganVzdCBsb29raW5nIGZvciByZWFzb25zIHRvIGlnbm9yZSB0aGUg SUVURiBtb2R1bGVzLg0KSW1wbGVtZW50YXRpb24gZGV0YWlscyBzdWNoIGFzIHJlZ2V4cCBhcmUg bm90IHRoZSB0eXBlIG9mIHRoaW5nIHRoZSBJRVRGDQpkaXNjdXNzZXMgYXQgbGVuZ3RoLiAgbGli eG1sMiBpcyB3aWRlbHkgZGVwbG95ZWQsIHNvICJsYWNrIG9mIGltcGxlbWVudGF0aW9ucyINCmRv ZXMgbm90IHNlZW0gdHJ1ZS4NCg0KR29vZ2xlIGhhcyBvdmVyIDkwMCBvcGVuc291cmNlIHByb2pl Y3RzIGxpc3RlZCBvbiBnaXRodWI6DQpodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlDQoNCllvdSB3 b3VsZCB0aGluayB0aGV5IHdvdWxkIGhhdmUgYW4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyByZWdl eHAgaW4gdGhlcmUgc29tZXdoZXJlLiA7LSkNCg0KSXQgd291bGQgcmVxdWlyZSBhIG5ldyB2ZXJz aW9uIG9mIFlBTkcgdGhhdCBicmVha3MgYmFja3dhcmQgY29tcGF0aWJpbGl0eQ0Kd2l0aCB2MS4w IGFuZCAxLjEgdG8gY2hhbmdlIHRoaXMuIE5vdCBzdXJlIGl0IGlzIHJlYWxseSB3b3J0aCBpdC4N Cg0KDQpBbmR5DQoNCg0KT24gVHVlLCBGZWIgMjEsIDIwMTcgYXQgMTI6NTggQU0sIEJlbm9pdCBD bGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+IHdyb3Rl Og0KSW5jbHVkaW5nIHRoZSBZQU5HIGRvY3RvcnMgb24gdGhpcyBpbXBvcnRhbnQgdG9waWMuDQoN ClJlZ2FyZHMsIEJlbm9pdA0KQXMgSSB3cm90ZSB0aGUgaW5pdGlhbCBlbWFpbC4gSSBjYW4gcHJv YmFibHkgYWRkIHNvbWUgY29tbWVudHMgYXQgdGhlIG5leHQgbWVldGluZy4NCg0KV2UgaGF2ZSBl eGFtaW5lZCBtdWx0aXBsZSB0aW1lcyByZXdyaXRpbmcgb2YgcmVnZXhwcyBmcm9tIHRoZSBXM0Mg c3RhbmRhcmQgdG8gc29tZXRoaW5nIHRoYXQgaXMgbW9yZSBjb21tb25seSBzdXBwb3J0ZWQuIEFu ZCB0byBiZSBmcmFuaywgaXQncyBub3QgYSB1c2VmdWwgdGFzayB0byBzcGVuZCB0aW1lIG9uLiBX b3JzZSwgdGhlIGV4aXN0aW5nIElFVEYgdHlwZXMgbW9kdWxlcyB1c2UgZWxlbWVudHMgc3VjaCBh cyBccHtMfSB3aGVuIEFGQUlDUywgdGhlcmUgaXMgbm8gcmVhc29uIG5vdCB0byB1c2UgW2EtekEt Wl0gZm9yIGFsbCBwcmFjdGljYWwgdXNlIGNhc2VzIChJIGtub3cgb2Ygbm8gc3lzdGVtIHRoYXQg aGFzIGFuIGludGVyZmFjZSB0aGF0IG5lZWRzIHRvIGJlIHpvbmVkIHRvIPCfjbogIGZvciBleGFt cGxlKS4NCg0Kci4NCg0KT24gTW9uLCAyMCBGZWIgMjAxNyBhdCAxNzo0OSBMb3UgQmVyZ2VyIDxs YmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pj4gd3JvdGU6DQpbQWRkaW5n IEtlbnQgYXMgbmV0bW9kIGNvLWNoYWlyLCBuZXRtb2QgQUQgaXMgYWxyZWFkeSBvbiB0aGUgbGlz dC5dDQoNCkplZmYsDQoNCiAgICBUaGlzIGlzIGFuIGltcG9ydGFudCB1c2VyIHBlcnNwZWN0aXZl LiAgSSBwZXJzb25hbGx5IGFtIG9wZW4gdG8NCmNoYW5naW5nIHRoZSByZWdleHAgcmVmZXJlbmNl IGluIFlBTkcgKHNlZSBbMV0pLCAqYnV0KiBJIHRoaW5rIHRoaXMNCndvdWxkIHJlcXVpcmVkIHJl didpbmcgWUFORyAodG8gMS4yLCBmb3IgZXhhbXBsZSkgdG8gZG8gc28uDQoNCkFsc28sIGluIHBv a2luZyBhcm91bmQsIEkgY2FuIG9ubHkgZmluZCBwb3NpeCBkZWZpbml0aW9ucyBiZWhpbmQNCnBh eS13YWxscywgd2hpY2ggbWF5IGJlIGFuIGlzc3VlIC0gYnV0IGFzIElBQiBpcyByZXNwb25zaWJs ZSBmb3IgSUVURg0KbGlhaXNvbnMsIHBlcmhhcHMgeW91IGNvdWxkIHJ1biB0aGlzIHBhcnQgdG8g Z3JvdW5kIDstKQ0KDQpJZiBLZW50IGlzIGFncmVlYWJsZSwgSSdkIGJlIG9wZW4gdG8gaGF2aW5n IGFuIHByZXNlbnRhdGlvbiBhbmQNCmRpc2N1c3Npb24gb24gdGhpcyAoZXZlbiB3aXRob3V0IGEg ZHJhZnQpIGF0IHRoZSBuZXh0IG1lZXRpbmcuDQoNCktlbnQ/DQoNClRoYW5rcywNCg0KTG91DQoN ClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTkuNC41DQpP biAyLzIwLzIwMTcgNzo1NSBQTSwgSmVmZiBUYW50c3VyYSB3cm90ZToNCj4gSEksDQo+DQo+IEkg aGF2ZSBiZWVuIGhhdmluZyBzb21lIGRpc2N1c3Npb24gd2l0aCBPQyBmb2xrcyAocHJpdmF0ZWx5 KSwgSeKAmWQgcmVhbGx5IHdhbnQgdG8gc2VlIGNvbnZlcmdlbmNlIGJldHdlZW4gT0MgYW5kIElF VEYuDQo+DQo+IEJlbG93IGlzIHRoZSBleHBsYW5hdGlvbiB3aHkgbm90IHRvIHVzZSBJRVRGIHZl cnNpb24uICBEbyB5b3UgdGhpbmsgdGhlcmXigJlzIGFueXRoaW5nIHdlIGNvdWxkIGRvIChMb3U/ KQ0KPg0KPiDigJxGb3IgdHlwZXMgbW9kdWxlcywgdGhlcmUncyBhIHByZXR0eSBpbnRlcmVzdGlu ZyBwcm9ibGVtIChBRkFJQ1MpLiBXZSBoYXZlIGZvdW5kIHRoYXQgdGhlIFczQyBzdGFuZGFyZCB0 aGF0IGlzIGJlaW5nIHVzZWQgZm9yIHJlZ2V4cCBoYXMgdmVyeSBsaW1pdGVkIHN1cHBvcnQuIFdl J3ZlIGFjdHVhbGx5IGZvcmtlZCBvdXIgdHlwZXMgbW9kdWxlcyB0byBzdG9wIHJlZmVyZW5jaW5n IElFVEYgb25lcywgc2luY2Ugd2UncmUgYWltaW5nIHRvIHVzZSBhIHJlZ2V4cCBzdGFuZGFyZCB0 aGF0IGlzIG1vcmUgY29tbW9ubHkgc3VwcG9ydGVkIChQT1NJWCkuDQo+DQo+IFdoZW4gSSd2ZSBy YWlzZWQgdGhpcyBwcml2YXRlbHksIHRoZXJlIHNlZW1zIHRvIGJlIGEgYnVuY2ggb2Ygb3Bwb3Np dGlvbiB0byBldmVuIGRpc2N1c3Npbmcgc3VjaCBpbXBsZW1lbnRhdGlvbiBxdWVzdGlvbnMgLSBz dWNoIHRoYXQgZm9ya2luZyBhbmQgbW92aW5nIGZvcndhcmQgc2VlbXMgYSBtdWNoIG1vcmUgZWZm ZWN0aXZlIHNvbHV0aW9uLiBXaGlsc3QgSSBjYW4ndCBzcGVhayBmb3IgT0MsIHBlcnNvbmFsbHks IEknZCBvcHBvc2UgdHJ5aW5nIHRvIHNwbGl0IG91ciB0eXBlcyBhY3Jvc3MgSUVURiBhbmQgT0Mg YXMgaXQgYWRkcyB0byB0aGUgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4NCj4NCj4gUGVyaGFw cyB3aXRoIHlvdXIgbmV3IGhhdCwgaXQgbWlnaHQgYmUgcG9zc2libGUgZm9yIHVzIHRvIGRpc2N1 c3MgZnVydGhlciB3aGF0IElFVEYncyBpbnRlcmVzdCBpcyBpbiB1c2FiaWxpdHkgdnMuIGxvbmct d2luZGVkIE5FVE1PRCBkaXNjdXNzaW9ucyA6LSkgdGhhdCBzZWVtIHRvIHJlYWNoIGZldyBhbnN3 ZXJzLuKAnQ0KPg0KPg0KPiBDaGVlcnMsDQo+IEplZmYNCj4NCj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUnRnLWR0LXlhbmctYXJjaCBt YWlsaW5nIGxpc3QNCj4gUnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZzxtYWlsdG86UnRnLWR0LXlh bmctYXJjaEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ydGctZHQteWFuZy1hcmNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpSdGctZHQteWFuZy1hcmNoIG1haWxpbmcgbGlzdA0KUnRnLWR0LXlhbmct YXJjaEBpZXRmLm9yZzxtYWlsdG86UnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLWR0LXlhbmctYXJjaA0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUnRnLWR0LXlh bmctYXJjaCBtYWlsaW5nIGxpc3QNCg0KUnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZzxtYWlsdG86 UnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9ydGctZHQteWFuZy1hcmNoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnlhbmctZG9jdG9ycyBtYWlsaW5nIGxpc3QNCnlhbmct ZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby95YW5nLWRvY3RvcnMNCg0K --_000_AF735E2B2EF64C3FA833E400BAE00A10junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiQXBwbGUgQ29sb3IgRW1vamkiOw0KCXBhbm9zZS0xOjAgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q291cmllcjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpu b3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5v bmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGlu ZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPlsmIzQzO3BoaWxdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpIj5NeSBjaGFpciByZXNwb25zZSBpcyB0aGF0IHdlJ2QgbmVlZCB0byBz ZWUgaWYgdGhlcmUgaXMgc3VmZmljaWVudCBXRyBpbnRlcmVzdCB0byBwcm9wb3NlIG1ha2luZyBh IGNoYW5nZS4mbmJzcDsgQ2VydGFpbmx5LCBhIHNvbHV0aW9uIHRoYXQgY291bGQgYXVnbWVudCB0 aGUgZXhpc3Rpbmcgc29sdXRpb24gaW4gYSB3YXkgdGhhdCBkaWRuJ3QgYnJlYWsgZXhpc3RpbmcN CiBjbGllbnRzIHdpdGhvdXQgd2FybmluZyB3b3VsZCBiZSBnb29kIChlLmcuLCBZQU5HLW5leHQp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+TXkgY29u dHJpYnV0b3IgcmVzcG9uc2UgaXMgdGhhdCBKVU5PUyBhbHNvIHN0cnVnZ2xlcyB0byBzdXBwb3J0 IFhTRCByZWdleC4mbmJzcDsgSW4gZmFjdCwgSSB0aGluayB0aGF0IGl0IGhhcyBhbHdheXMgdXNl ZCBQT1NJWCByZWdleCBhbmQgY29udGludWVzIHRvIGRvIHNvIHRvIHRoaXMgZGF5LiZuYnNwOyBQ aGlsIG1pZ2h0IGhhdmUgbW9yZSB0byBzYXkgb24gdGhpcw0KIHBvaW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzIxLzE3LCAxMjoy NCBQTSwgJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwg PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIHRo ZSBvcGVuY29uZmlnIGZvbGtzIGFyZSBqdXN0IGxvb2tpbmcgZm9yIHJlYXNvbnMgdG8gaWdub3Jl IHRoZSBJRVRGIG1vZHVsZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHN1Y2ggYXMgcmVnZXhwIGFyZSBu b3QgdGhlIHR5cGUgb2YgdGhpbmcgdGhlIElFVEY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRpc2N1c3NlcyBhdCBsZW5ndGguICZuYnNwO2xpYnht bDIgaXMgd2lkZWx5IGRlcGxveWVkLCBzbyAmcXVvdDtsYWNrIG9mIGltcGxlbWVudGF0aW9ucyZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ ZG9lcyBub3Qgc2VlbSB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Hb29nbGUgaGFzIG92ZXIgOTAwIG9wZW5zb3VyY2UgcHJvamVjdHMg bGlzdGVkIG9uIGdpdGh1Yjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUiPmh0dHBzOi8v Z2l0aHViLmNvbS9nb29nbGU8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPllvdSB3b3VsZCB0aGluayB0aGV5IHdvdWxkIGhhdmUgYW4gaW1w bGVtZW50YXRpb24gb2YgdGhpcyByZWdleHAgaW4gdGhlcmUgc29tZXdoZXJlLiA7LSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQg cmVxdWlyZSBhIG5ldyB2ZXJzaW9uIG9mIFlBTkcgdGhhdCBicmVha3MgYmFja3dhcmQgY29tcGF0 aWJpbGl0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+d2l0aCB2MS4wIGFuZCAxLjEgdG8gY2hhbmdlIHRoaXMuIE5vdCBzdXJlIGl0IGlzIHJlYWxs eSB3b3J0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMjEsIDIwMTcgYXQgMTI6NTggQU0sIEJlbm9pdCBD bGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmJjbGFpc2VAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmNsdWRpbmcgdGhl IFlBTkcgZG9jdG9ycyBvbiB0aGlzIGltcG9ydGFudCB0b3BpYy48YnI+DQo8YnI+DQpSZWdhcmRz LCBCZW5vaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgSSB3cm90ZSB0aGUgaW5pdGlhbCBlbWFpbC4gSSBjYW4gcHJvYmFibHkgYWRkIHNv bWUgY29tbWVudHMgYXQgdGhlIG5leHQgbWVldGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSBleGFtaW5lZCBtdWx0aXBsZSB0aW1lcyBy ZXdyaXRpbmcgb2YgcmVnZXhwcyBmcm9tIHRoZSBXM0Mgc3RhbmRhcmQgdG8gc29tZXRoaW5nIHRo YXQgaXMgbW9yZSBjb21tb25seSBzdXBwb3J0ZWQuIEFuZCB0byBiZSBmcmFuaywgaXQncyBub3Qg YSB1c2VmdWwgdGFzayB0byBzcGVuZCB0aW1lIG9uLiBXb3JzZSwgdGhlIGV4aXN0aW5nIElFVEYg dHlwZXMgbW9kdWxlcyB1c2UgZWxlbWVudHMgc3VjaA0KIGFzIFxwe0x9IHdoZW4gQUZBSUNTLCB0 aGVyZSBpcyBubyByZWFzb24gbm90IHRvIHVzZSBbYS16QS1aXSBmb3IgYWxsIHByYWN0aWNhbCB1 c2UgY2FzZXMgKEkga25vdyBvZiBubyBzeXN0ZW0gdGhhdCBoYXMgYW4gaW50ZXJmYWNlIHRoYXQg bmVlZHMgdG8gYmUgem9uZWQgdG8NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcHBs ZSBDb2xvciBFbW9qaSZxdW90OyI+JiMxMjc4NjY7PC9zcGFuPiAmbmJzcDtmb3IgZXhhbXBsZSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE1vbiwgMjAgRmViIDIwMTcgYXQgMTc6NDkgTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmxiZXJnZXJAbGFibi5uZXQiIHRhcmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5bQWRkaW5nIEtlbnQgYXMgbmV0bW9kIGNvLWNoYWlyLCBuZXRtb2QgQUQgaXMg YWxyZWFkeSBvbiB0aGUgbGlzdC5dPGJyPg0KPGJyPg0KSmVmZiw8YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IFRoaXMgaXMgYW4gaW1wb3J0YW50IHVzZXIgcGVyc3BlY3RpdmUuJm5ic3A7IEkgcGVy c29uYWxseSBhbSBvcGVuIHRvPGJyPg0KY2hhbmdpbmcgdGhlIHJlZ2V4cCByZWZlcmVuY2UgaW4g WUFORyAoc2VlIFsxXSksICpidXQqIEkgdGhpbmsgdGhpczxicj4NCndvdWxkIHJlcXVpcmVkIHJl didpbmcgWUFORyAodG8gMS4yLCBmb3IgZXhhbXBsZSkgdG8gZG8gc28uPGJyPg0KPGJyPg0KQWxz bywgaW4gcG9raW5nIGFyb3VuZCwgSSBjYW4gb25seSBmaW5kIHBvc2l4IGRlZmluaXRpb25zIGJl aGluZDxicj4NCnBheS13YWxscywgd2hpY2ggbWF5IGJlIGFuIGlzc3VlIC0gYnV0IGFzIElBQiBp cyByZXNwb25zaWJsZSBmb3IgSUVURjxicj4NCmxpYWlzb25zLCBwZXJoYXBzIHlvdSBjb3VsZCBy dW4gdGhpcyBwYXJ0IHRvIGdyb3VuZCA7LSk8YnI+DQo8YnI+DQpJZiBLZW50IGlzIGFncmVlYWJs ZSwgSSdkIGJlIG9wZW4gdG8gaGF2aW5nIGFuIHByZXNlbnRhdGlvbiBhbmQ8YnI+DQpkaXNjdXNz aW9uIG9uIHRoaXMgKGV2ZW4gd2l0aG91dCBhIGRyYWZ0KSBhdCB0aGUgbmV4dCBtZWV0aW5nLjxi cj4NCjxicj4NCktlbnQ/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkxvdTxicj4NCjxi cj4NClsxXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0 aW9uLTkuNC41IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm Yzc5NTAjc2VjdGlvbi05LjQuNTwvYT48YnI+DQpPbiAyLzIwLzIwMTcgNzo1NSBQTSwgSmVmZiBU YW50c3VyYSB3cm90ZTo8YnI+DQomZ3Q7IEhJLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaGF2ZSBi ZWVuIGhhdmluZyBzb21lIGRpc2N1c3Npb24gd2l0aCBPQyBmb2xrcyAocHJpdmF0ZWx5KSwgSeKA mWQgcmVhbGx5IHdhbnQgdG8gc2VlIGNvbnZlcmdlbmNlIGJldHdlZW4gT0MgYW5kIElFVEYuPGJy Pg0KJmd0Ozxicj4NCiZndDsgQmVsb3cgaXMgdGhlIGV4cGxhbmF0aW9uIHdoeSBub3QgdG8gdXNl IElFVEYgdmVyc2lvbi4mbmJzcDsgRG8geW91IHRoaW5rIHRoZXJl4oCZcyBhbnl0aGluZyB3ZSBj b3VsZCBkbyAoTG91Pyk8YnI+DQomZ3Q7PGJyPg0KJmd0OyDigJxGb3IgdHlwZXMgbW9kdWxlcywg dGhlcmUncyBhIHByZXR0eSBpbnRlcmVzdGluZyBwcm9ibGVtIChBRkFJQ1MpLiBXZSBoYXZlIGZv dW5kIHRoYXQgdGhlIFczQyBzdGFuZGFyZCB0aGF0IGlzIGJlaW5nIHVzZWQgZm9yIHJlZ2V4cCBo YXMgdmVyeSBsaW1pdGVkIHN1cHBvcnQuIFdlJ3ZlIGFjdHVhbGx5IGZvcmtlZCBvdXIgdHlwZXMg bW9kdWxlcyB0byBzdG9wIHJlZmVyZW5jaW5nIElFVEYgb25lcywgc2luY2Ugd2UncmUgYWltaW5n IHRvIHVzZQ0KIGEgcmVnZXhwIHN0YW5kYXJkIHRoYXQgaXMgbW9yZSBjb21tb25seSBzdXBwb3J0 ZWQgKFBPU0lYKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXaGVuIEkndmUgcmFpc2VkIHRoaXMgcHJp dmF0ZWx5LCB0aGVyZSBzZWVtcyB0byBiZSBhIGJ1bmNoIG9mIG9wcG9zaXRpb24gdG8gZXZlbiBk aXNjdXNzaW5nIHN1Y2ggaW1wbGVtZW50YXRpb24gcXVlc3Rpb25zIC0gc3VjaCB0aGF0IGZvcmtp bmcgYW5kIG1vdmluZyBmb3J3YXJkIHNlZW1zIGEgbXVjaCBtb3JlIGVmZmVjdGl2ZSBzb2x1dGlv bi4gV2hpbHN0IEkgY2FuJ3Qgc3BlYWsgZm9yIE9DLCBwZXJzb25hbGx5LCBJJ2Qgb3Bwb3NlIHRy eWluZw0KIHRvIHNwbGl0IG91ciB0eXBlcyBhY3Jvc3MgSUVURiBhbmQgT0MgYXMgaXQgYWRkcyB0 byB0aGUgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQZXJo YXBzIHdpdGggeW91ciBuZXcgaGF0LCBpdCBtaWdodCBiZSBwb3NzaWJsZSBmb3IgdXMgdG8gZGlz Y3VzcyBmdXJ0aGVyIHdoYXQgSUVURidzIGludGVyZXN0IGlzIGluIHVzYWJpbGl0eSB2cy4gbG9u Zy13aW5kZWQgTkVUTU9EIGRpc2N1c3Npb25zIDotKSB0aGF0IHNlZW0gdG8gcmVhY2ggZmV3IGFu c3dlcnMu4oCdPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7 IEplZmY8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBSdGctZHQteWFu Zy1hcmNoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOlJ0Zy1kdC15YW5n LWFyY2hAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5SdGctZHQteWFuZy1hcmNoQGlldGYub3Jn PC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGctZHQteWFuZy1hcmNoIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy1kdC15YW5nLWFyY2g8L2E+PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpSdGctZHQt eWFuZy1hcmNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpSdGctZHQteWFuZy1h cmNoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnRnLWR0LXlhbmctYXJjaEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Zy1kdC15YW5nLWFyY2giIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3J0Zy1kdC15YW5nLWFyY2g8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJ0Zy1kdC15YW5nLWFyY2ggbWFpbGluZyBsaXN0 PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOlJ0Zy1kdC15YW5nLWFyY2hA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5SdGctZHQteWFuZy1hcmNoQGlldGYub3JnPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRnLWR0LXlhbmctYXJjaCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLWR0LXlhbmctYXJjaDwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp5YW5nLWRvY3RvcnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnlhbmctZG9jdG9yc0BpZXRmLm9yZyI+eWFuZy1kb2N0b3JzQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veWFuZy1kb2N0 b3JzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by95YW5nLWRvY3RvcnM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AF735E2B2EF64C3FA833E400BAE00A10junipernet_-- From nobody Tue Feb 21 09:39:00 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E46129517 for ; Tue, 21 Feb 2017 09:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.887 X-Spam-Level: X-Spam-Status: No, score=-3.887 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_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2mQ7cil543rq for ; Tue, 21 Feb 2017 09:38:53 -0800 (PST) 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 DA928129495 for ; Tue, 21 Feb 2017 09:38:53 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 7F3EA1E0F50 for ; Tue, 21 Feb 2017 10:38:53 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nVeo1u01D2SSUrH01Verm4; Tue, 21 Feb 2017 10:38:52 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=xskcdSivAAAA:8 a=NEAV23lmAAAA:8 a=AUd_NHdVAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=rl49wvpq8weab6kjruAA:9 a=YGjq_BjksBWdrE3q:21 a=OmhmhZcEN9HVQdzE:21 a=QEXdDO2ut3YA:10 a=B8SJYIqRPU5_XtF5Z38x:22 a=Bn2pgwyD2vrAyMmN8A2t:22 a=TSZmLRzkpGLBZRr3r8m8:22 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: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=3FyxMhXwlrbmmrWkdI2MPAO7RmWFij8KBN5w+4jv4oA=; b=SJIUcWuwXQJxQeGkKDquJUl7hI R3rlUHnobROnLgZ4sV+0MnOYFFQzpauGWtBc670Moy0WVXfBB2+3YJZjuDIw6G3DGxy8UNccLpiHb wpk2gmCuIYpu3nKcOpi2bCUz2; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:59600 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cgEOl-0004mC-44; Tue, 21 Feb 2017 10:38:48 -0700 To: Kent Watsen , Andy Bierman , Benoit Claise References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> From: Lou Berger Message-ID: <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> Date: Tue, 21 Feb 2017 12:38:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 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.85.191 X-Exim-ID: 1cgEOl-0004mC-44 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:59600 X-Source-Auth: lberger@labn.net X-Email-Count: 14 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: RTG YANG Design Team , Phil Shafer , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 17:38:56 -0000 Thanks kent - I read this as also being open to discussing in the WG. Jeff, You do you want to take the lead on putting something together on this to drive discussion in Chicago? If not, who is the right person? Thanks, Lou On 2/21/2017 12:33 PM, Kent Watsen wrote: > > [+phil] > > > > My chair response is that we'd need to see if there is sufficient WG > interest to propose making a change. Certainly, a solution that could > augment the existing solution in a way that didn't break existing > clients without warning would be good (e.g., YANG-next). > > > > My contributor response is that JUNOS also struggles to support XSD > regex. In fact, I think that it has always used POSIX regex and > continues to do so to this day. Phil might have more to say on this > point. > > > > Thanks, > > Kent > > > > > > > > On 2/21/17, 12:24 PM, "Andy Bierman" > wrote: > > > > Hi, > > > > > > Maybe the openconfig folks are just looking for reasons to ignore the > IETF modules. > > Implementation details such as regexp are not the type of thing the IETF > > discusses at length. libxml2 is widely deployed, so "lack of > implementations" > > does not seem true. > > > > Google has over 900 opensource projects listed on github: > > https://github.com/google > > > > You would think they would have an implementation of this regexp in > there somewhere. ;-) > > > > It would require a new version of YANG that breaks backward compatibility > > with v1.0 and 1.1 to change this. Not sure it is really worth it. > > > > > > Andy > > > > > > On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise > wrote: > > Including the YANG doctors on this important topic. > > Regards, Benoit > > As I wrote the initial email. I can probably add some comments > at the next meeting. > > > > We have examined multiple times rewriting of regexps from the > W3C standard to something that is more commonly supported. And > to be frank, it's not a useful task to spend time on. Worse, > the existing IETF types modules use elements such as \p{L} > when AFAICS, there is no reason not to use [a-zA-Z] for all > practical use cases (I know of no system that has an interface > that needs to be zoned to 🍺 for example). > > > > r. > > > > On Mon, 20 Feb 2017 at 17:49 Lou Berger > wrote: > > [Adding Kent as netmod co-chair, netmod AD is already on > the list.] > > Jeff, > > This is an important user perspective. I personally > am open to > changing the regexp reference in YANG (see [1]), *but* I > think this > would required rev'ing YANG (to 1.2, for example) to do so. > > Also, in poking around, I can only find posix definitions > behind > pay-walls, which may be an issue - but as IAB is > responsible for IETF > liaisons, perhaps you could run this part to ground ;-) > > If Kent is agreeable, I'd be open to having an > presentation and > discussion on this (even without a draft) at the next meeting. > > Kent? > > Thanks, > > Lou > > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > > HI, > > > > I have been having some discussion with OC folks > (privately), I’d really want to see convergence between OC > and IETF. > > > > Below is the explanation why not to use IETF version. > Do you think there’s anything we could do (Lou?) > > > > “For types modules, there's a pretty interesting problem > (AFAICS). We have found that the W3C standard that is > being used for regexp has very limited support. We've > actually forked our types modules to stop referencing IETF > ones, since we're aiming to use a regexp standard that is > more commonly supported (POSIX). > > > > When I've raised this privately, there seems to be a > bunch of opposition to even discussing such implementation > questions - such that forking and moving forward seems a > much more effective solution. Whilst I can't speak for OC, > personally, I'd oppose trying to split our types across > IETF and OC as it adds to the implementation complexity. > > > > Perhaps with your new hat, it might be possible for us > to discuss further what IETF's interest is in usability > vs. long-winded NETMOD discussions :-) that seem to reach > few answers.” > > > > > > Cheers, > > Jeff > > > > > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > From nobody Tue Feb 21 10:03:22 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5DA12948F; Tue, 21 Feb 2017 10:03:21 -0800 (PST) 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 ywYm2rujGtUp; Tue, 21 Feb 2017 10:03:19 -0800 (PST) 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 3235B129465; Tue, 21 Feb 2017 10:03:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B107974C; Tue, 21 Feb 2017 19:03:16 +0100 (CET) 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 Da17uLsIv2Gv; Tue, 21 Feb 2017 19:03:14 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Feb 2017 19:03:16 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4B1CF200CB; Tue, 21 Feb 2017 19:03:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m1H7Mc6FlVG5; Tue, 21 Feb 2017 19:03:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BC08200C9; Tue, 21 Feb 2017 19:03:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C38A43E80C65; Tue, 21 Feb 2017 19:03:13 +0100 (CET) Date: Tue, 21 Feb 2017 19:03:13 +0100 From: Juergen Schoenwaelder To: Christian Hopps Message-ID: <20170221180313.GA40049@elstar.local> Mail-Followup-To: Christian Hopps , Ladislav Lhotka , rtg-dt-yang-arch@ietf.org, Xufeng_Liu@jabil.com, lberger@labn.net, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, acee@cisco.com, yingzhen.qu@huawei.com References: <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> <20170221.122107.2124509611280123175.mbj@tail-f.com> <87a89fxxnd.fsf@chopps.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a89fxxnd.fsf@chopps.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:03:21 -0000 On Tue, Feb 21, 2017 at 12:27:02PM -0500, Christian Hopps wrote: > > Ladislav Lhotka writes: > > Martin Bjorklund writes: > >> I also note that while we can discuss individual datatypes, it seems > >> reasonable to pick a regexp dialect that supports unicode (which POSIX > >> doesn't do). > > > > This is a showstopper. > > I'm sympathetic to supporting unicode, and while I don't wish to debate > the point personally, it clearly is not stopping actual users. They > appear to be voting with their feet. There are multiple POSIX regex variants. If we were to pick one, some other people will say POSIX regex suck and we should at least do PCRE, which then comes in different flavours (with or without unicode/UTF8 support). It may be useful if someone does some detailed background reading. It might turn out that the XSD regex syntax YANG is using is not really a bad one once you want to handle unicode. Here is something for a start: http://www.regular-expressions.info/unicode.html https://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines /js PS: I actually do not know how far PCRE is from the XSD regex we use in YANG if you select the right options. PS: PCRE seems to do \p{L} like many of the more modern regular expression implementations seem to do. I guess you end up with this once you take unicode support serious. -- 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 Feb 21 10:52:33 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8917B129C76 for ; Tue, 21 Feb 2017 10:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 Tbow9E8dWcg1 for ; Tue, 21 Feb 2017 10:52:29 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 9C5D6129C74 for ; Tue, 21 Feb 2017 10:52:29 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id y135so64575807itc.1 for ; Tue, 21 Feb 2017 10:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8EEnKMbvMl0S2Tud9MXDMIOYi08OLr6hqoSTdUS2oN8=; b=FGez+YqnZrhiWU3CWec3z887jB/JSQU60P7VuSqFPnCdo7jojq8DZ7quyaFwawgvps 2GCtgMFL2sJcSBbBZAyJiUCZn0Zj4RQ6WTvK3PTp0kAbT12kk9pY/8bIlE3xmVioo4en fqddRHUWQA1lhbhnEMwWo2ixz1QxiTJ6gkSyxAfaqkUn0AFjBRLU/V6JA4jfH5XPhN33 M7kFLByd/hvpIZALgWQowJlZvUpvP0XuA4fx/zldNJXJf29jD/Pcn1ONMj32GP8jzSqQ 00uJRsGPYNc07PV/zMExPHrP2IKhm+TTZQERdqgXd2OvenK3Ni/d9ZLLYPldSMzPP/kO jzXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8EEnKMbvMl0S2Tud9MXDMIOYi08OLr6hqoSTdUS2oN8=; b=nCXhZ+jCO+Z97LGBftQdkWRpoZs2CvFnQD2lezJ+yHGihGk2WEg6LxFZuyxmyMFOZx Nd7MNLO3XVkqPdMhlfE11Rzu68Dmco6msHBefFZUtze6b+QmjKeiA55GhK3xPAFRfDiL 3sxp8GNGqDVmy6NrPa2IZphgR+a6gfM/ycuo3KKzxSURUY77aMjYFe/8WIkpciy70L1M hpFpoJed3F+o44MutYsbd5ePYR+oBfyALow/XJXbFdBDrm3OqLxf4NMS9qQdcuEQ9CJC jE/hdL8Y7pbvfqku6IiJ+PsYCnDbaHyFvQeTKI4gF/yR//YEE/jqQry4Z6FfhY4VG3D5 ZfJA== X-Gm-Message-State: AMke39kNMOfCkRzirpylUl/eF/fGkT0ny94lAqx3BAP0+YrHDh5oTEF8fzWTUvSg0AaELsG5w4l80m69vVaQnA== X-Received: by 10.107.180.8 with SMTP id d8mr21710299iof.101.1487703148880; Tue, 21 Feb 2017 10:52:28 -0800 (PST) MIME-Version: 1.0 References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> In-Reply-To: From: Rob Shakir Date: Tue, 21 Feb 2017 18:52:18 +0000 Message-ID: To: Andy Bierman , Benoit Claise Content-Type: multipart/alternative; boundary=94eb2c05a656b87f9f05490ee125 Archived-At: Cc: RTG YANG Design Team , Xufeng Liu , Yingzhen Qu , Alia Atlas , YANG Doctors , Jeff Tantsura , Lou Berger , "Acee Lindem \(acee\)" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 18:52:31 -0000 --94eb2c05a656b87f9f05490ee125 Content-Type: text/plain; charset=UTF-8 Skipping some elements of this message that I'm not sure are constructive to respond to. Until very recently, OpenConfig models did use ietf imports. This would appear to me to be exactly counter to the "looking for excuses" comment. On Tue, 21 Feb 2017 at 09:24 Andy Bierman wrote: > > Implementation details such as regexp are not the type of thing the IETF > discusses at length. > That's fine. Other than the specification mandates an implementation of a particular regexp set of functionality. Driving specific implementations and code maintenance for a standard negatively impacts its adoption. RFC5218 did a good job of talking about this - https://tools.ietf.org/html/rfc5218#section-2.1.3 r. --94eb2c05a656b87f9f05490ee125 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c05a656b87f9f05490ee125-- From nobody Tue Feb 21 11:28:32 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB15129448; Tue, 21 Feb 2017 11:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 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=-1.887, 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 F7LB4425n_8e; Tue, 21 Feb 2017 11:28:25 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0131.outbound.protection.outlook.com [104.47.33.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6D7127A90; Tue, 21 Feb 2017 11:28:25 -0800 (PST) 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=HW7S69HILCzNonqUujlDX5i404YvZn98NypY7H95IW4=; b=NmMsW3cBJY/bD3a5Z6uW1DQKgAqOgUtUdLFTw2kCV4B0pEJNPPgcZ+Ol4OS7hODFOjLPP1jL2BFH0rwuL+08eEvqsmK5mSTXG0msK8eXQLMcQG9ik8OmTxjQoU6/j4z5RPCnDuA6kGJqPuz2xvkUMXMemJf65vTiTOAQwjyZUHc= 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_256_CBC_SHA384_P384) id 15.1.919.10; Tue, 21 Feb 2017 19:28:22 +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.0919.018; Tue, 21 Feb 2017 19:28:22 +0000 From: Kent Watsen To: Rob Shakir , Andy Bierman , Benoit Claise Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types Thread-Index: AQHSi+StkdIR7osOm0ei4kB8g34eIqFzEfkAgAAXggCAAI2VAIAAGGYA//+2QYA= Date: Tue, 21 Feb 2017 19:28:22 +0000 Message-ID: References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.13] x-ms-office365-filtering-correlation-id: ecd84412-70ee-427a-7109-08d45a8fccbc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:/FnlWGjs7ZQCpkV1yMEfzjLUi1/W9DlJH15LSvTW9TVM/JoWL7MMhDxQU8sO9ouwlzl208M8U1r+NOms2gyxBbxRC2i/7I4conQhhXl/z/B/MFw5sgsV1vHUpY05jREZh21B+SMbfY/ay9s3CQ1cQCfkkbaJc2SLrYGT8Nag2DmWL25Ga9FmWyzMhyG0sltVTBxvVRa7L9WQuDm4VrFg4HofK/jgaTuZZdHDNrrBvSYgy7Y5lcTZ8ECyvRxRRXsqy4hgqFOxpE9r+WYeEJYavrDBwcgQu8FKlJbLrtiuoMfVP8IoNDLNgsD8gozBJtHHUbau7kBTAFXY7L4/ctueng== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39410400002)(39860400002)(39450400003)(39850400002)(189002)(199003)(2950100002)(7416002)(39060400002)(86362001)(6246003)(36756003)(54356999)(76176999)(6306002)(4326007)(2906002)(38730400002)(122556002)(50986999)(54906002)(6512007)(101416001)(53936002)(54896002)(7736002)(2900100001)(6486002)(6116002)(102836003)(3846002)(8676002)(83716003)(8936002)(99286003)(6506006)(5660300001)(77096006)(6436002)(25786008)(92566002)(4001350100001)(81166006)(66066001)(97736004)(3280700002)(106356001)(33656002)(229853002)(105586002)(3660700001)(230783001)(106116001)(83506001)(82746002)(189998001)(93886004)(68736007)(81156014)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A3F04B5EA70B482B901BA0833661433Ejunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 19:28:22.6446 (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: Cc: RTG YANG Design Team , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Lou Berger , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:28:27 -0000 --_000_A3F04B5EA70B482B901BA0833661433Ejunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj4gU2tpcHBpbmcgc29tZSBlbGVtZW50cyBvZiB0aGlzIG1lc3NhZ2UgdGhhdCBJJ20gbm90 IHN1cmUgYXJlIGNvbnN0cnVjdGl2ZSB0byByZXNwb25kIHRvLg0KPg0KPlVudGlsIHZlcnkgcmVj ZW50bHksIE9wZW5Db25maWcgbW9kZWxzIGRpZCB1c2UgaWV0ZiBpbXBvcnRzLiBUaGlzIHdvdWxk IGFwcGVhciB0byBtZSB0byBiZSA+ZXhhY3RseSBjb3VudGVyIHRvIHRoZSAibG9va2luZyBmb3Ig ZXhjdXNlcyIgY29tbWVudC4NCg0KQWdyZWVkLiAgQW5keSwgdGhhdCB3YXMgYSBiaXQgb3ZlciB0 aGUgdG9wLiAgUGxlYXNlIGNoZWNrIHRvbmUgYmVmb3JlIGhpdHRpbmcgc2VuZC4NCg0KS2VudCAv LyBwaWNrIGEgaGF0DQoNCg0K --_000_A3F04B5EA70B482B901BA0833661433Ejunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsgU2tpcHBpbmcgc29tZSBlbGVtZW50cyBvZiB0aGlzIG1lc3NhZ2UgdGhhdCBJJ20gbm90IHN1 cmUgYXJlIGNvbnN0cnVjdGl2ZSB0byByZXNwb25kIHRvLiZuYnNwOw0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0O1VudGlsIHZlcnkgcmVjZW50 bHksIE9wZW5Db25maWcgbW9kZWxzIGRpZCB1c2UgaWV0ZiBpbXBvcnRzLiBUaGlzIHdvdWxkIGFw cGVhciB0byBtZSB0byBiZSAmZ3Q7ZXhhY3RseSBjb3VudGVyIHRvIHRoZSAmcXVvdDtsb29raW5n IGZvciBleGN1c2VzJnF1b3Q7IGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFncmVlZC4mbmJzcDsgQW5keSwgdGhhdCB3YXMgYSBiaXQgb3ZlciB0 aGUgdG9wLiZuYnNwOyBQbGVhc2UgY2hlY2sgdG9uZSBiZWZvcmUgaGl0dGluZyBzZW5kLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5LZW50IC8vIHBpY2sgYSBoYXQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A3F04B5EA70B482B901BA0833661433Ejunipernet_-- From nobody Tue Feb 21 11:54:27 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C2B129502; Tue, 21 Feb 2017 11:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, MIME_QP_LONG_LINE=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 Dl22Caa-1CDw; Tue, 21 Feb 2017 11:54:18 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 74BDD1294E7; Tue, 21 Feb 2017 11:54:18 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id e137so17900518itc.0; Tue, 21 Feb 2017 11:54:18 -0800 (PST) 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; bh=fON7AxgR2vwIDotovY90ASc3mYnYZ1wg5L7lX30dqs0=; b=hgjtxizLHIuQupolKXpWjbrl/hHK2YyDfivIS5Ee0Cus+h0EW6MQJo1SWsIaaiRjv0 /68y/Xp8nnEhZBxjXIOtJmixw4ivfaYeCFvHdTvJrnTbvnAcSpWoUSNtqPLh7/GECPPi R1VBcPKSB/7Ctc/rHYlfI6m0Gqyf2GsTOjgH1/UqCdX1qV0gA7yQ26MY+8AVH4CBHZEk F6VZbF5iJEMdjAKlPSQPSMaFMV/NTQB8/USChOSxf8UaLu56/24mMzviE2uZGulnKC0r 4HXhnPfLGdTlUiVDDzldkCvXiw9oZhJtgN/KuLSMs4HHf65xsGEun/NMBS1f7Qkrqp9S vEjQ== 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; bh=fON7AxgR2vwIDotovY90ASc3mYnYZ1wg5L7lX30dqs0=; b=TMphyjCl9ShHU1e4Xbv9rqGV9s+oju5F7QY7+X0QXMNetDt9w6lgsPJMrpqYX5cFyj THy7QNl5r09Vb2R4CzMlY4RXU9bxO7+X+/x6o3IwAlmXkyQ6RWY1PC7XMPB/VdoVxobp V80tqlqMVlIzSAndQDkj+35C/kAowYSbFWPfBhHQWCRkoL48bU4IZrlbC50RBY9UOdV5 Y2N+O9VPnjPugGcAXnJ3LyQA7UqO/u8LMpr3KFe+gxn3oYW+P+7bslNeYseaHv6a3GHc 6uH4Ve2IZy/EnlPxRKluXqQnucQSWoKOjkuuFX2H8pdJTbHVtxE3JjKjKnotJBBdkDn7 f5fA== X-Gm-Message-State: AMke39l+MQ7ZsHpxdJMpWbCFSbeHWLY2F/kw0+cQfGtLhyxJDD2BvFoZWOX6LBkJfaRhNw== X-Received: by 10.36.20.216 with SMTP id 207mr30109929itg.61.1487706856771; Tue, 21 Feb 2017 11:54:16 -0800 (PST) Received: from [10.36.249.107] (sccc-66-78-236-243.smartcity.com. [66.78.236.243]) by smtp.gmail.com with ESMTPSA id 62sm7956416itl.1.2017.02.21.11.54.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 11:54:15 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 21 Feb 2017 11:54:12 -0800 From: Jeff Tantsura To: Andy Bierman , Benoit Claise Message-ID: Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3570522854_1379732708" Archived-At: Cc: RTG YANG Design Team , Lou Berger , Xufeng Liu , Yingzhen Qu , Alia Atlas , YANG Doctors , Rob Shakir , "Acee Lindem \(acee\)" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 19:54:22 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3570522854_1379732708 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable /wearing my new IAB hat =20 Andy, =20 This conversation has been started to find common pain points and come up w= ith a solution that works for all of the parties involved. What is not part of it is: =20 -I know better -not made here -passive-aggressive behavior =20 -discussing to death and finger-pointing=20 =20 Your knowledge and expertise are highly valued in the industry, your help t= o solve the issues is very much needed and more than welcome. =20 Cheers, Jeff =20 From: Andy Bierman Date: Tuesday, February 21, 2017 at 09:24 To: Benoit Claise Cc: Rob Shakir , Lou Berger , Jeff Tantsura <= jefftant.ietf@gmail.com>, "Acee Lindem (acee)" , RTG YANG De= sign Team , Xufeng Liu , Yi= ngzhen Qu , "yang-doctors@ietf.org" , Alia Atlas Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-= types =20 Hi, =20 =20 Maybe the openconfig folks are just looking for reasons to ignore the IETF = modules. Implementation details such as regexp are not the type of thing the IETF discusses at length. libxml2 is widely deployed, so "lack of implementatio= ns" does not seem true. =20 Google has over 900 opensource projects listed on github: https://github.com/google =20 You would think they would have an implementation of this regexp in there s= omewhere. ;-) =20 It would require a new version of YANG that breaks backward compatibility with v1.0 and 1.1 to change this. Not sure it is really worth it. =20 =20 Andy =20 =20 On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise wrote: Including the YANG doctors on this important topic. Regards, Benoit As I wrote the initial email. I can probably add some comments at the next = meeting.=20 =20 We have examined multiple times rewriting of regexps from the W3C standard = to something that is more commonly supported. And to be frank, it's not a us= eful task to spend time on. Worse, the existing IETF types modules use eleme= nts such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z] for al= l practical use cases (I know of no system that has an interface that needs = to be zoned to =F0=9F=8D=BA for example). =20 r. =20 On Mon, 20 Feb 2017 at 17:49 Lou Berger wrote: [Adding Kent as netmod co-chair, netmod AD is already on the list.] Jeff, This is an important user perspective. I personally am open to changing the regexp reference in YANG (see [1]), *but* I think this would required rev'ing YANG (to 1.2, for example) to do so. Also, in poking around, I can only find posix definitions behind pay-walls, which may be an issue - but as IAB is responsible for IETF liaisons, perhaps you could run this part to ground ;-) If Kent is agreeable, I'd be open to having an presentation and discussion on this (even without a draft) at the next meeting. Kent? Thanks, Lou [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > HI, > > I have been having some discussion with OC folks (privately), I=E2=80=99d reall= y want to see convergence between OC and IETF. > > Below is the explanation why not to use IETF version. Do you think there= =E2=80=99s anything we could do (Lou?) > > =E2=80=9CFor types modules, there's a pretty interesting problem (AFAICS). We h= ave found that the W3C standard that is being used for regexp has very limit= ed support. We've actually forked our types modules to stop referencing IETF= ones, since we're aiming to use a regexp standard that is more commonly sup= ported (POSIX). > > When I've raised this privately, there seems to be a bunch of opposition = to even discussing such implementation questions - such that forking and mov= ing forward seems a much more effective solution. Whilst I can't speak for O= C, personally, I'd oppose trying to split our types across IETF and OC as it= adds to the implementation complexity. > > Perhaps with your new hat, it might be possible for us to discuss further= what IETF's interest is in usability vs. long-winded NETMOD discussions :-)= that seem to reach few answers.=E2=80=9D > > > Cheers, > Jeff > > > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch _______________________________________________ Rtg-dt-yang-arch mailing list Rtg-dt-yang-arch@ietf.org https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch _______________________________________________ Rtg-dt-yang-arch mailing list Rtg-dt-yang-arch@ietf.org https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch =20 _______________________________________________ yang-doctors mailing list yang-doctors@ietf.org https://www.ietf.org/mailman/listinfo/yang-doctors =20 --B_3570522854_1379732708 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

/wearing my new IAB hat

 

= Andy,

 

This conversation has been starte= d to find common pain points and come up with a solution that works for all = of the parties involved.

What is not part of it is:

 

-I know better

-not made here

-passive-aggressive behavior

 

-discussing to death and finger-pointing

 =

Your knowledge and expertise are highly valued in the industry, your he= lp to solve the issues is very much needed and more than welcome.=

 

Cheers,

Jeff

 

<= p class=3DMsoNormal>From: Andy Bierman <andy@= yumaworks.com>
Date: Tuesday, February 21, 2017 at 09:24
= To: Benoit Claise <bclaise@cisco.com>
Cc: Rob Shakir <= ;rjs@rob.sh>, Lou Berger <lberger@labn.net>, Jeff Tantsura <jeff= tant.ietf@gmail.com>, "Acee Lindem (acee)" <acee@cisco.com&g= t;, RTG YANG Design Team <rtg-dt-yang-arch@ietf.org>, Xufeng Liu <X= ufeng_Liu@jabil.com>, Yingzhen Qu <yingzhen.qu@huawei.com>, "y= ang-doctors@ietf.org" <yang-doctors@ietf.org>, Alia Atlas <aka= tlas@gmail.com>
Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] = Open Config on ietf-routing-types

 

Hi,

 

 

Maybe the openconfig fol= ks are just looking for reasons to ignore the IETF modules.

Implementation details such as regexp are not th= e type of thing the IETF

discuss= es at length.  libxml2 is widely deployed, so "lack of implementat= ions"

does not seem true.

 

<= p class=3DMsoNormal>Google has over 900 opensource projects listed on github:<= o:p>

 

You would think they wo= uld have an implementation of this regexp in there somewhere. ;-)=

 

It would require a new version of YANG that breaks backward compati= bility

with v1.0 and 1.1 to chan= ge this. Not sure it is really worth it.

 

 

Andy

 

 =

On Tue, Feb 21, 2017 at 12:58 AM, Benoit C= laise <bclaise@cisco.c= om> wrote:

Including the YANG doctors on this importa= nt topic.

Regards, Benoit

As I wrote the ini= tial email. I can probably add some comments at the next meeting.

 

We have examined multiple times rewriting of regexps from the W3C standa= rd to something that is more commonly supported. And to be frank, it's not a= useful task to spend time on. Worse, the existing IETF types modules use el= ements such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z] for= all practical use cases (I know of no system that has an interface that nee= ds to be zoned to 🍺  for example).

&n= bsp;

r.

 

On Mon, 20= Feb 2017 at 17:49 Lou Berger <lberger@labn.net> wrote:

[Adding Kent as netmod c= o-chair, netmod AD is already on the list.]

Jeff,

   = ; This is an important user perspective.  I personally am open to
ch= anging the regexp reference in YANG (see [1]), *but* I think this
would r= equired rev'ing YANG (to 1.2, for example) to do so.

Also, in poking = around, I can only find posix definitions behind
pay-walls, which may be = an issue - but as IAB is responsible for IETF
liaisons, perhaps you could= run this part to ground ;-)

If Kent is agreeable, I'd be open to hav= ing an presentation and
discussion on this (even without a draft) at the = next meeting.

Kent?

Thanks,

Lou

[1] https://tool= s.ietf.org/html/rfc7950#section-9.4.5
On 2/20/2017 7:55 PM, Jeff Tant= sura wrote:
> HI,
>
> I have been having some discussion w= ith OC folks (privately), I’d really want to see convergence between O= C and IETF.
>
> Below is the explanation why not to use = IETF version.  Do you think there’s anything we could do (Lou?)
>
> “For types modules, there's a pretty interestin= g problem (AFAICS). We have found that the W3C standard that is being used f= or regexp has very limited support. We've actually forked our types modules = to stop referencing IETF ones, since we're aiming to use a regexp standard t= hat is more commonly supported (POSIX).
>
> When I've raised thi= s privately, there seems to be a bunch of opposition to even discussing such= implementation questions - such that forking and moving forward seems a muc= h more effective solution. Whilst I can't speak for OC, personally, I'd oppo= se trying to split our types across IETF and OC as it adds to the implementa= tion complexity.
>
> Perhaps with your new hat, it might be poss= ible for us to discuss further what IETF's interest is in usability vs. long= -winded NETMOD discussions :-) that seem to reach few answers.”
>
>
> Cheers,<= span style=3D'font-family:PMingLiU'>
> Jeff
>
&g= t;
>
> _______________________________________________> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https= ://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

_______________= ________________________________
Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.or= g
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch



_______________________________________________
Rtg-dt=
-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

 


__________________________________= _____________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo= /yang-doctors

&= nbsp;

--B_3570522854_1379732708-- From nobody Tue Feb 21 12:41:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0A912975C for ; Tue, 21 Feb 2017 12:41:53 -0800 (PST) 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 QmeGO23ASBNW for ; Tue, 21 Feb 2017 12:41:52 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 DC1A1129490 for ; Tue, 21 Feb 2017 12:41:51 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id c85so123005410wmi.1 for ; Tue, 21 Feb 2017 12:41:51 -0800 (PST) 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=UKSvkTZiN+L3qM4+03BPCAW/Mg3vXOQAqXem+Xslg+s=; b=R3XtuYVByQDduHyRidnuxblLhrs8F5/XrM28+Dp5tH8who/sY2YXeobILo+dnceB7A J+SFH1guBEcLn2dYrl2pSMxg3JmBD6wU26RYXa0iIGoC9/EiR9xtW9sMlukxCe+eDaRb A1FGqOZhMqpr8GbggIaqvNtl3GsC8kZWq7PXrNyuTxlpRH5BX7nzc1oPcsmCiskNFABU D7zWe/H7ONxXbT7ZHNFvenN4NyoYOTPEdxM05+GrOy6hYrCE4+hVtmFUr9p8vag8HJje iNXIX1m+PXTLMD7Vq1Wgx2kiMr+f03BpsnTNnx7xM+2foD1E27TUHaDJFXkhlu44g4qJ nVdQ== 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=UKSvkTZiN+L3qM4+03BPCAW/Mg3vXOQAqXem+Xslg+s=; b=Q/Ly30NB2ZoUvdvBc4gFSjg4ki4MtCKsg7wvra0QSnDXLriJEplu1YOeO65OyTGFqb yDyK50B+laV5x7tymyfJk4szrbqOzDuGtqdpLhBoB855BaFOO0C4+GPiC/kmjfD6DOkp 5P4rFwxViPa3NavmVB0ylPayKr+HnkSjSwI2pfmYgIdzwtx8dQpdwrQqY2Far2UGJF+E Csvhf27q8432bKcINE2D1iakEkf/9izPeMAT9FTl2vHwOOLQftSLnTFnjGlwiFmkTLuM 4jYeIeD2iOSECbORR56NFYTyQTtq7ApXUzDOKAkcuVWpthVpbEO1D/TjP5mlzCfAlhMX VGBg== X-Gm-Message-State: AMke39nqi+owhwsKSPUqW7j6y0UZnkXhzc1ckP3X21jdPJt7HAK6MjVEoEpR6xZoC4RwmHnGM8JFqH5AoOimiA== X-Received: by 10.28.109.27 with SMTP id i27mr15153780wmc.54.1487709710438; Tue, 21 Feb 2017 12:41:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Tue, 21 Feb 2017 12:41:49 -0800 (PST) In-Reply-To: References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> From: Andy Bierman Date: Tue, 21 Feb 2017 12:41:49 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11478e80d1f0fc054910681d Archived-At: Cc: RTG YANG Design Team , Lou Berger , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:41:53 -0000 --001a11478e80d1f0fc054910681d Content-Type: text/plain; charset=UTF-8 OK -- sorry. I'm not interested in a new version of YANG, but if that's what the WG wants to do, that's fine. Andy On Tue, Feb 21, 2017 at 11:28 AM, Kent Watsen wrote: > > > > > > Skipping some elements of this message that I'm not sure are > constructive to respond to. > > > > > >Until very recently, OpenConfig models did use ietf imports. This would > appear to me to be >exactly counter to the "looking for excuses" comment. > > > > Agreed. Andy, that was a bit over the top. Please check tone before > hitting send. > > > > Kent // pick a hat > > > > > --001a11478e80d1f0fc054910681d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK -- sorry.
I'm not interested in a new version o= f YANG,
but if that's what the WG wants to do, that's fin= e.


Andy

<= div class=3D"gmail_extra">
On Tue, Feb 21, 20= 17 at 11:28 AM, Kent Watsen <kwatsen@juniper.net> wrote:

=C2=A0

=C2=A0

> Skipping some elements of this message that I&#= 39;m not sure are constructive to respond to.=C2=A0

>=C2=A0

>Until very recently, OpenConfig models did use i= etf imports. This would appear to me to be >exactly counter to the "= ;looking for excuses" comment.

=C2=A0

Agreed.=C2=A0 Andy, that was a bit over the top.=C2= =A0 Please check tone before hitting send.

=C2=A0

Kent // pick a hat

=C2=A0

=C2=A0


--001a11478e80d1f0fc054910681d-- From nobody Tue Feb 21 12:59:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E371297C1; Tue, 21 Feb 2017 12:59:09 -0800 (PST) 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 sLXrRtXlwswL; Tue, 21 Feb 2017 12:59:07 -0800 (PST) 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 B93841294B5; Tue, 21 Feb 2017 12:59:07 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:b118:c8ca:3862:2dff] (unknown [IPv6:2a01:5e0:29:ffff:b118:c8ca:3862:2dff]) by mail.nic.cz (Postfix) with ESMTPSA id EFEE060168; Tue, 21 Feb 2017 21:59:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487710746; bh=SaRm0/q4L5BPi8vwp7dlBeapfV1wysnhx9VUkfkjoDQ=; h=From:Date:To; b=M/9YDW6N0niHFI2BT+iSBooD4BdnpGjl8Ye28h3QoX1QBOZo+AClnZT0gYMPg1Juo 9c5//gfoNclYYvE8fvKS1svOddyhj3UsONlsvpxmx8P3sMDxa6Yqc4b034ro2sIXad VxFILu+e43fPal8LSUHoMo4F+LdAd8tP43p6hz0o= 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: Tue, 21 Feb 2017 21:59:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57416204-BA10-4147-87F5-F66579EB47BB@nic.cz> References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> To: Rob Shakir X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: RTG YANG Design Team , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , Benoit Claise , Jeff Tantsura , Lou Berger , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:59:10 -0000 > On 21 Feb 2017, at 19:52, Rob Shakir wrote: >=20 > Skipping some elements of this message that I'm not sure are = constructive to respond to.=20 >=20 > Until very recently, OpenConfig models did use ietf imports. This = would appear to me to be exactly counter to the "looking for excuses" = comment. >=20 > On Tue, 21 Feb 2017 at 09:24 Andy Bierman wrote: >=20 > Implementation details such as regexp are not the type of thing the = IETF > discusses at length.=20 >=20 > That's fine. Other than the specification mandates an implementation = of a particular regexp set of functionality. Driving specific = implementations and code maintenance for a standard negatively impacts = its adoption. RFC5218 did a good job of talking about this - = https://tools.ietf.org/html/rfc5218#section-2.1.3 It is not that the specification mandates an implementation, but it = obviously has to standardize a particular language of regular = expressions so that everybody's notion of whether a given string is a = valid value for a given type is the same. Of course we can discuss what language to use but I don't see any = clearly superior alternative. It is true that XSD regular expressions = deviate in some aspects from the mainstream but at least they are = defined in an open standard, very readable textbook-style descriptions = are freely available [1], and open source implementations do exist. Lada [1] http://books.xmlschemata.org/relaxng/relax-CHP-9.html > =20 >=20 > r. > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Feb 21 19:07:18 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A278129545 for ; Tue, 21 Feb 2017 19:07:17 -0800 (PST) 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 KUrG3h3JJ6qj for ; Tue, 21 Feb 2017 19:07:15 -0800 (PST) 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 CE23E129544 for ; Tue, 21 Feb 2017 19:07:14 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id v77so711733wmv.0 for ; Tue, 21 Feb 2017 19:07:14 -0800 (PST) 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=3jAgVdKt5VEwei9oMuXQLfP7iKV1ryM+GiUZRv51gk0=; b=niwMmh3do3PFhkPBAf4xM1WnOo0BkbwFToRdNzjNqzvkmRRMKX0KvBf9wPlfMCvRd5 X8HN1/zxSf+o+5bJsjYle7aDrHwSFiPZ04/xpPppR77EvsEpHmqrt0wxmY9sSSW7vrCK 3fUzlcZz2qvPLJpqoVUE0b0kfiDxiwySFAIx0tgJJiTfs/U9LyQ3Oxs+InQ2HsUw7H42 9YOJmvbIMWrmPcrCmsyDhA4AGPpoFG+Msvk2UzTRw2UElmMZnCchTxtfUWs93OsNGhPy UiKCdcQXH3F4Ea5tfegdJsPfMKxgIt3vpnIgy66X7WxnjeOGPTD6Wu256fFSMQapXxib 4bCQ== 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=3jAgVdKt5VEwei9oMuXQLfP7iKV1ryM+GiUZRv51gk0=; b=Jnk1zk86ozeCp4Ot7SlcdHwUFohGcYfLlYeGIltTT75/nhQOSWTJ/Y+e+1Az3wwcxH Z6VbB8dzfZeKnkUTeweW7T+c9M49kwqWbX7dGu7GpqOzKhnCbJ5rbGkgxO8hCdYTIfCQ C37B+LY4BylznCDYX4zyBz87Gq+jdgg2PFJJZQRlGBrJjOK+vIjo/w7rD8sR0qgxrL0u dCzHhyqWiuB/sYHkqFJyWKMfluOUZRrbFe+Z8ZhLXUD8m7C1YVb4WrgfPVma6BgdQa4W L2EFo1AbYNnln3dFV4A08xO/6vrxSvNR7G3/VW8vybtYXL/JOacNR6sVhWugcdRaD7WS ThtQ== X-Gm-Message-State: AMke39m8OE8reyFi01EgytyZQ61grqOeH1ooCf4PDbPO+d4HA63QZLKQ80pD7hg/Qd/x65CWBPo03X2nAdBk3A== X-Received: by 10.28.46.73 with SMTP id u70mr260526wmu.54.1487732833304; Tue, 21 Feb 2017 19:07:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Tue, 21 Feb 2017 19:07:12 -0800 (PST) In-Reply-To: References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> From: Andy Bierman Date: Tue, 21 Feb 2017 19:07:12 -0800 Message-ID: To: Jeff Tantsura Content-Type: multipart/alternative; boundary=001a114240b00cdae6054915cb46 Archived-At: Cc: RTG YANG Design Team , Lou Berger , Xufeng Liu , Yingzhen Qu , Alia Atlas , YANG Doctors , Rob Shakir , "Acee Lindem \(acee\)" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 03:07:17 -0000 --001a114240b00cdae6054915cb46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The pattern syntax has not really changed since the early drafts in 2008, so it is a bit surprising to hear that it is a show-stopper in 2017. Seems to me that changing the pattern syntax would require a new version of YANG. Modules written in version 1.0 and 1.1 might not conform t= o the new pattern syntax, which seems like a problem. It is expensive to introduce a new version of a programming language. Some people might prefer stability over incremental features. Andy On Tue, Feb 21, 2017 at 11:54 AM, Jeff Tantsura wrote: > /wearing my new IAB hat > > > > Andy, > > > > This conversation has been started to find common pain points and come up > with a solution that works for all of the parties involved. > > What is not part of it is: > > > > -I know better > > -not made here > > -passive-aggressive behavior > > > > -discussing to death and finger-pointing > > > > Your knowledge and expertise are highly valued in the industry, your help > to solve the issues is very much needed and more than welcome. > > > > Cheers, > > Jeff > > > > *From: *Andy Bierman > *Date: *Tuesday, February 21, 2017 at 09:24 > *To: *Benoit Claise > *Cc: *Rob Shakir , Lou Berger , Jeff > Tantsura , "Acee Lindem (acee)" = , > RTG YANG Design Team , Xufeng Liu < > Xufeng_Liu@jabil.com>, Yingzhen Qu , " > yang-doctors@ietf.org" , Alia Atlas < > akatlas@gmail.com> > *Subject: *Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on > ietf-routing-types > > > > Hi, > > > > > > Maybe the openconfig folks are just looking for reasons to ignore the IET= F > modules. > > Implementation details such as regexp are not the type of thing the IETF > > discusses at length. libxml2 is widely deployed, so "lack of > implementations" > > does not seem true. > > > > Google has over 900 opensource projects listed on github: > > https://github.com/google > > > > You would think they would have an implementation of this regexp in there > somewhere. ;-) > > > > It would require a new version of YANG that breaks backward compatibility > > with v1.0 and 1.1 to change this. Not sure it is really worth it. > > > > > > Andy > > > > > > On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise wrote= : > > Including the YANG doctors on this important topic. > > Regards, Benoit > > As I wrote the initial email. I can probably add some comments at the nex= t > meeting. > > > > We have examined multiple times rewriting of regexps from the W3C standar= d > to something that is more commonly supported. And to be frank, it's not a > useful task to spend time on. Worse, the existing IETF types modules use > elements such as \p{L} when AFAICS, there is no reason not to use [a-zA-Z= ] > for all practical use cases (I know of no system that has an interface th= at > needs to be zoned to =F0=9F=8D=BA for example). > > > > r. > > > > On Mon, 20 Feb 2017 at 17:49 Lou Berger wrote: > > [Adding Kent as netmod co-chair, netmod AD is already on the list.] > > Jeff, > > This is an important user perspective. I personally am open to > changing the regexp reference in YANG (see [1]), *but* I think this > would required rev'ing YANG (to 1.2, for example) to do so. > > Also, in poking around, I can only find posix definitions behind > pay-walls, which may be an issue - but as IAB is responsible for IETF > liaisons, perhaps you could run this part to ground ;-) > > If Kent is agreeable, I'd be open to having an presentation and > discussion on this (even without a draft) at the next meeting. > > Kent? > > Thanks, > > Lou > > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > > HI, > > > > I have been having some discussion with OC folks (privately), I=E2=80= =99d really > want to see convergence between OC and IETF. > > > > Below is the explanation why not to use IETF version. Do you think > there=E2=80=99s anything we could do (Lou?) > > > > =E2=80=9CFor types modules, there's a pretty interesting problem (AFAIC= S). We > have found that the W3C standard that is being used for regexp has very > limited support. We've actually forked our types modules to stop > referencing IETF ones, since we're aiming to use a regexp standard that i= s > more commonly supported (POSIX). > > > > When I've raised this privately, there seems to be a bunch of oppositio= n > to even discussing such implementation questions - such that forking and > moving forward seems a much more effective solution. Whilst I can't speak > for OC, personally, I'd oppose trying to split our types across IETF and = OC > as it adds to the implementation complexity. > > > > Perhaps with your new hat, it might be possible for us to discuss > further what IETF's interest is in usability vs. long-winded NETMOD > discussions :-) that seem to reach few answers.=E2=80=9D > > > > > > Cheers, > > Jeff > > > > > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > --001a114240b00cdae6054915cb46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The pattern syntax has not really c= hanged since the early drafts in 2008,
so it is a bit surprising = to hear that it is a show-stopper in 2017.
Seems to me that chang= ing the pattern syntax would require a new
version of YANG. Modul= es written in version 1.0 and 1.1 might not conform to
the new pa= ttern syntax, which seems like a problem.

It is ex= pensive to introduce a new version of a programming language.
Som= e people might prefer stability over incremental features.


Andy


On Tue, Feb 21, 2017 at 11:54 AM, Jef= f Tantsura <jefftant.ietf@gmail.com> wrote:

/wearin= g my new IAB hat

=C2=A0

A= ndy,

=C2=A0

This conversa= tion has been started to find common pain points and come up with a solutio= n that works for all of the parties involved.

What= is not part of it is:

=C2=A0=

-I know better

-not made here

-passive-aggressive behavior

=C2= =A0

-discussing to death and finger-pointing

=C2=A0

Your knowledge and expertise = are highly valued in the industry, your help to solve the issues is very mu= ch needed and more than welcome.

= =C2=A0

Cheers,

Jeff

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 21, 2017 at = 09:24
To: Benoit Claise <bclaise@cisco.com>
Cc: Rob Shakir <rj= s@rob.sh>, Lou Berger <lberger@labn.net>, Jeff Tantsura <jefftant.ietf@gmail.com>, &quo= t;Acee Lindem (acee)" <acee@cisco.com>, RTG YANG Design Team <rtg-dt-yang-arch@ietf.org&= gt;, Xufeng Liu <Xufeng_Liu@jabil.com>, Yingzhen Qu <yingzhen.qu@huawei.com>, "yang-doctors@ietf.o= rg" <yang-doctors@ietf.org>, Alia Atlas <akatlas@gmail.com>
Subject: Re:= [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types=

=C2=A0

Hi,

=C2=A0

= =C2=A0

Maybe the openconfig fol= ks are just looking for reasons to ignore the IETF modules.

Implementation details such as regexp a= re not the type of thing the IETF

discusses at length. =C2=A0libxml2 is widely deployed, so "l= ack of implementations"

does not seem true.

=C2=A0

Google has over = 900 opensource projects listed on github:

=C2=A0

You would th= ink they would have an implementation of this regexp in there somewhere. ;-= )

=C2=A0

It would require a new version of YANG = that breaks backward compatibility

with v1.0 and 1.1 to change this. Not sure it is really worth it= .

=C2=A0

=C2=A0

Andy

= =C2=A0

=C2= =A0

On Tue, Feb 21, 2017 at 12:58 AM,= Benoit Claise <b= claise@cisco.com> wrote:

Including the YA= NG doctors on this important topic.

Regards, Benoit

As I wrote the initial email. I can probably add some co= mments at the next meeting.

<= u>=C2=A0

We have examined m= ultiple times rewriting of regexps from the W3C standard to something that = is more commonly supported. And to be frank, it's not a useful task to = spend time on. Worse, the existing IETF types modules use elements such as = \p{L} when AFAICS, there is no reason not to use [a-zA-Z] for all practical= use cases (I know of no system that has an interface that needs to be zone= d to =F0=9F=8D=BA= =C2=A0for example).

=C2=A0

r.<= /u>

=C2=A0

On Mon, 20 Feb 2017 at 17:49 Lou Berger <lberger@labn.net> wro= te:

[Adding Kent as netmod co-chair, netmod AD is al= ready on the list.]

Jeff,

=C2=A0 =C2=A0 This is an important = user perspective.=C2=A0 I personally am open to
changing the regexp refe= rence in YANG (see [1]), *but* I think this
would required rev'ing Y= ANG (to 1.2, for example) to do so.

Also, in poking around, I can on= ly find posix definitions behind
pay-walls, which may be an issue - but = as IAB is responsible for IETF
liaisons, perhaps you could run this part= to ground ;-)

If Kent is agreeable, I'd be open to having an pr= esentation and
discussion on this (even without a draft) at the next mee= ting.

Kent?

Thanks,

Lou

[1] https://tools.= ietf.org/html/rfc7950#section-9.4.5
On 2/20/2017 7:55 PM, Jeff = Tantsura wrote:
> HI,
>
> I have been having some discuss= ion with OC folks (privately), I=E2=80=99d really want to see convergence b= etween OC and IETF.
>
> Below is the explanation w= hy not to use IETF version.=C2=A0 Do you think there=E2=80=99s anything we = could do (Lou?)
>
> =E2=80=9CFor types modules, th= ere's a pretty interesting problem (AFAICS). We have found that the W3C= standard that is being used for regexp has very limited support. We've= actually forked our types modules to stop referencing IETF ones, since we&= #39;re aiming to use a regexp standard that is more commonly supported (POS= IX).
>
> When I've raised this privately, there seems to be= a bunch of opposition to even discussing such implementation questions - s= uch that forking and moving forward seems a much more effective solution. W= hilst I can't speak for OC, personally, I'd oppose trying to split = our types across IETF and OC as it adds to the implementation complexity.>
> Perhaps with your new hat, it might be possible for us to di= scuss further what IETF's interest is in usability vs. long-winded NETM= OD discussions :-) that seem to reach few answers.=E2=80=9D
>>
> Cheers,
> Jeff
>
>
>
> _______________________________= ________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.or= g
> https://www.ietf.org/mailman/listinfo/rtg-dt-y= ang-arch

_______________________________________________Rtg-dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/rtg-dt-yang-arch



______=
_________________________________________
Rtg-=
dt-yang-arch mailing list
Rtg-dt-yang-arch@ietf.org<=
u>
https://www.ietf.org/mailman/listinfo/rtg-d=
t-yang-arch

<= /u>=C2=A0


_______________________________________________
yang-docto= rs mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/lis= tinfo/yang-doctors

=C2=A0


--001a114240b00cdae6054915cb46-- From nobody Tue Feb 21 23:57:32 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3278D129457; Tue, 21 Feb 2017 23:57:31 -0800 (PST) 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, MIME_QP_LONG_LINE=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 k-4rxCFFxwkS; Tue, 21 Feb 2017 23:57:29 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 11CC5129422; Tue, 21 Feb 2017 23:57:29 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id z128so1037825pgb.3; Tue, 21 Feb 2017 23:57:29 -0800 (PST) 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=gk5rG40xs7s5KGT3TpJ8xHo+zLbI3P1JZB1HjmsDFFw=; b=AAFYCCLbc8psx3uPvH0Gi7uWGPywMn9kjG3FPTiBkG/02cxVLBpQJK4lUEwd1ro06w KFbU0xfUBx91a8+m6rPgRNXJWIE2D7+EzpB4/lHkw//sWwoj9NmLniPBhZZeTEq7+Tqx qrgHOZ8VCIMSnDQq9fIESAYcov2CLClrZeV9nsrhOe7XKSAnhT/wsvADJgqcfR90LWYk SlGsunbk9+E8Q1x42Z1BsBgUjBB/NoA6W29QbJlDrOzywjWH5Ht1Up/fdape7ph0HMHQ l/v7BfyTXV6FPBCfkTDxWM922Th4xpomFr9W+LPEJBrfhZ9AqVpxiTUSMTcrD7Y/sa7d pm9Q== 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=gk5rG40xs7s5KGT3TpJ8xHo+zLbI3P1JZB1HjmsDFFw=; b=sMvxZH1SYaQMx5L3Y+y3nm9oMVSyBVVSuTi7XQkZshdieRYX42oCenBridj5zuegUd xnPP0D1NRAF1Df/Psip+01KLj3x/74KnKIA5GSTMquoMyAieKCE4Zx176NM5B5nxvFy/ SlRWOMIa2Z9+cdunEaIutYcDXMlM2YL04quRFRFxgCUE2lM32ILOTo+RQqr1NDr9AP2x FwJTzdG0kWaF8ehWEg1y2OV5ooTsAh+0S0F6hFN+RgDVzIf3hQCL2zIDHduK12Bq44ie K1ieoJtR8uZ3b4D4bZ+tlS0WhomahNttiOgBr/jsUv+jDSyQ1mqoqHtVe7U5kpUoVcmo 7DAg== X-Gm-Message-State: AMke39lQGNOUDf7yCA0dzDKsPoLiev/jn32Oa9FJM3BPQsnIz9RPxr7sQSenuPSq8YnZvA== X-Received: by 10.98.153.25 with SMTP id d25mr38809838pfe.15.1487750248529; Tue, 21 Feb 2017 23:57:28 -0800 (PST) Received: from [192.168.1.4] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id q19sm1650298pfl.21.2017.02.21.23.57.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Feb 2017 23:57:27 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Tue, 21 Feb 2017 23:57:25 -0800 From: Jeff Tantsura To: Lou Berger , Kent Watsen , Andy Bierman , Benoit Claise , Anees Shaikh Message-ID: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> In-Reply-To: <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: RTG YANG Design Team , Phil Shafer , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 07:57:31 -0000 Lou, Yes, absolutely! Please note - my goal is NOT to create more formal documents/YANG versions/= etc =E2=80=93 it is to get to the point we could reduce (eliminate would be the gr= and goal) discrepancy between IETF and OpenConfig (by now implemented by eve= ry vendor out there) models. Having OC using ietf-routing-types without sacr= ificing functionality would be a great starting point, tangible deliverable,= achievable given both sides are willing to co-operate. I=E2=80=99ll be talking to some of you during this and next week. I believe RTGWG should provide venue for the discussion, let me discuss thi= s with co-chair and AD =20 Thanks, Jeff =20 On 2/21/17, 09:38, "Lou Berger" wrote: Thanks kent - I read this as also being open to discussing in the WG. =20 Jeff, =20 You do you want to take the lead on putting something together on this to drive discussion in Chicago? If not, who is the right person? =20 Thanks, =20 Lou =20 =20 On 2/21/2017 12:33 PM, Kent Watsen wrote: > > [+phil] > > =20 > > My chair response is that we'd need to see if there is sufficient WG > interest to propose making a change. Certainly, a solution that coul= d > augment the existing solution in a way that didn't break existing > clients without warning would be good (e.g., YANG-next). > > =20 > > My contributor response is that JUNOS also struggles to support XSD > regex. In fact, I think that it has always used POSIX regex and > continues to do so to this day. Phil might have more to say on this > point. > > =20 > > Thanks, > > Kent > > =20 > > =20 > > =20 > > On 2/21/17, 12:24 PM, "Andy Bierman" > wrote: > > =20 > > Hi, > > =20 > > =20 > > Maybe the openconfig folks are just looking for reasons to ignore the > IETF modules. > > Implementation details such as regexp are not the type of thing the I= ETF > > discusses at length. libxml2 is widely deployed, so "lack of > implementations" > > does not seem true. > > =20 > > Google has over 900 opensource projects listed on github: > > https://github.com/google > > =20 > > You would think they would have an implementation of this regexp in > there somewhere. ;-) > > =20 > > It would require a new version of YANG that breaks backward compatibi= lity > > with v1.0 and 1.1 to change this. Not sure it is really worth it. > > =20 > > =20 > > Andy > > =20 > > =20 > > On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise > wrote: > > Including the YANG doctors on this important topic. > > Regards, Benoit > > As I wrote the initial email. I can probably add some comment= s > at the next meeting. > > =20 > > We have examined multiple times rewriting of regexps from the > W3C standard to something that is more commonly supported. An= d > to be frank, it's not a useful task to spend time on. Worse, > the existing IETF types modules use elements such as \p{L} > when AFAICS, there is no reason not to use [a-zA-Z] for all > practical use cases (I know of no system that has an interfac= e > that needs to be zoned to =F0=9F=8D=BA for example). > > =20 > > r. > > =20 > > On Mon, 20 Feb 2017 at 17:49 Lou Berger > wrote: > > [Adding Kent as netmod co-chair, netmod AD is already on > the list.] > > Jeff, > > This is an important user perspective. I personally > am open to > changing the regexp reference in YANG (see [1]), *but* I > think this > would required rev'ing YANG (to 1.2, for example) to do s= o. > > Also, in poking around, I can only find posix definitions > behind > pay-walls, which may be an issue - but as IAB is > responsible for IETF > liaisons, perhaps you could run this part to ground ;-) > > If Kent is agreeable, I'd be open to having an > presentation and > discussion on this (even without a draft) at the next mee= ting. > > Kent? > > Thanks, > > Lou > > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > > HI, > > > > I have been having some discussion with OC folks > (privately), I=E2=80=99d really want to see convergence between= OC > and IETF. > > > > Below is the explanation why not to use IETF version.=20 > Do you think there=E2=80=99s anything we could do (Lou?) > > > > =E2=80=9CFor types modules, there's a pretty interesting prob= lem > (AFAICS). We have found that the W3C standard that is > being used for regexp has very limited support. We've > actually forked our types modules to stop referencing IET= F > ones, since we're aiming to use a regexp standard that is > more commonly supported (POSIX). > > > > When I've raised this privately, there seems to be a > bunch of opposition to even discussing such implementatio= n > questions - such that forking and moving forward seems a > much more effective solution. Whilst I can't speak for OC= , > personally, I'd oppose trying to split our types across > IETF and OC as it adds to the implementation complexity. > > > > Perhaps with your new hat, it might be possible for us > to discuss further what IETF's interest is in usability > vs. long-winded NETMOD discussions :-) that seem to reach > few answers.=E2=80=9D > > > > > > Cheers, > > Jeff > > > > > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > =20 > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > =20 > =20 =20 From nobody Wed Feb 22 00:25:29 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A19812966A; Wed, 22 Feb 2017 00:25:25 -0800 (PST) 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 i5cQdxirO5mT; Wed, 22 Feb 2017 00:25:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F13D21294ED; Wed, 22 Feb 2017 00:25:23 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 6204B1AE0187; Wed, 22 Feb 2017 09:25:21 +0100 (CET) Date: Wed, 22 Feb 2017 09:25:22 +0100 (CET) Message-Id: <20170222.092522.195034997221928672.mbj@tail-f.com> To: jefftant.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> References: <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> <15D625FF-F977-437D-8439-C485F7324267@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:25:25 -0000 SGksDQoNCkplZmYgVGFudHN1cmEgPGplZmZ0YW50LmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4g TG91LA0KPiANCj4gWWVzLCBhYnNvbHV0ZWx5IQ0KPiANCj4gUGxlYXNlIG5vdGUgLSBteSBnb2Fs IGlzIE5PVCB0byBjcmVhdGUgbW9yZSBmb3JtYWwgZG9jdW1lbnRzL1lBTkcNCj4gdmVyc2lvbnMv ZXRjIOKAkyBpdCBpcyB0byBnZXQgdG8gdGhlIHBvaW50IHdlIGNvdWxkIHJlZHVjZSAoZWxpbWlu YXRlDQo+IHdvdWxkIGJlIHRoZSBncmFuZCBnb2FsKSBkaXNjcmVwYW5jeSBiZXR3ZWVuIElFVEYg YW5kIE9wZW5Db25maWcgKGJ5DQo+IG5vdyBpbXBsZW1lbnRlZCBieSBldmVyeSB2ZW5kb3Igb3V0 IHRoZXJlKSBtb2RlbHMuDQoNCkkganVzdCB3YW50IHRvIGNvbW1lbnQgb24gdGhpcyBsYXN0IHBv aW50LiAgSXQgaXMgc2ltcGx5IG5vdCB0cnVlLg0KWUFORyBpcyBkZXNpZ25lZCBmb3IgYW5kIHVz ZWQgaW4gKmxvdHMqIG9mIG90aGVyIHR5cGVzIG9mIGRldmljZXMgdGhhbg0Kcm91dGVycywgbWFu eSBvZiB3aGljaCBkbyBub3QgaW1wbGVtZW50IHRoZSBPQyBtb2RlbHMuDQoNCj4gSGF2aW5nIE9D IHVzaW5nDQo+IGlldGYtcm91dGluZy10eXBlcyB3aXRob3V0IHNhY3JpZmljaW5nIGZ1bmN0aW9u YWxpdHkgd291bGQgYmUgYSBncmVhdA0KPiBzdGFydGluZyBwb2ludCwgdGFuZ2libGUgZGVsaXZl cmFibGUsIGFjaGlldmFibGUgZ2l2ZW4gYm90aCBzaWRlcyBhcmUNCj4gd2lsbGluZyB0byBjby1v cGVyYXRlLg0KDQpNeSBxdWVzdGlvbiBhYm91dCB3aGF0IHRoZSBwcm9ibGVtIGlzIGlzIHN0aWxs IG5vdCBhbnN3ZXJlZC4gIElzIHRoZQ0KcHJvYmxlbSB0aGF0IHRoZSBYU0QgcmVnZXhwIGRpYWxl Y3QgaXMgdG9vIHByaW1pdGl2ZSwgb3IgaXMgaXQgdGhhdA0KdGhlIG9wZW4gaW1wbGVtZW50YXRp b25zIHRoYXQgZXhpc3QgY2Fubm90IGJlIHVzZWQ/DQoNCj4gSeKAmWxsIGJlIHRhbGtpbmcgdG8g c29tZSBvZiB5b3UgZHVyaW5nIHRoaXMgYW5kIG5leHQgd2Vlay4NCj4gDQo+IEkgYmVsaWV2ZSBS VEdXRyBzaG91bGQgcHJvdmlkZSB2ZW51ZSBmb3IgdGhlIGRpc2N1c3Npb24sIGxldCBtZQ0KPiBk aXNjdXNzIHRoaXMgd2l0aCBjby1jaGFpciBhbmQgQUQNCg0KQSBjbGFyaWZ5aW5nIHF1ZXN0aW9u ICAtIHdoYXQgZG9lcyAidGhlIGRpc2N1c3Npb24iIHJlZmVyIHRvPyAgSXMgaXQNCmFib3V0IG1h a2luZyBzdXJlIGlldGYtcm91dGluZy10eXBlcyBjYW4gYmUgdXNlZCBieSBvdGhlcnMsIG9yIGlz IGl0DQphYm91dCBtYWtpbmcgY2hhbmdlcyB0byB0aGUgWUFORyBsYW5ndWFnZT8NCg0KDQovbWFy dGluDQo= From nobody Wed Feb 22 00:44:42 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126F012968C; Wed, 22 Feb 2017 00:44:40 -0800 (PST) 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, MIME_QP_LONG_LINE=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 ke08YEFGfQ39; Wed, 22 Feb 2017 00:44:38 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 D422D1293DF; Wed, 22 Feb 2017 00:44:38 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id s67so1272188pgb.1; Wed, 22 Feb 2017 00:44:38 -0800 (PST) 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=yi90PohzodfA0f0F3opdU5Y7KIM7BsQWXsTZumhFpws=; b=DuqfED/iM+/dCIQnX3zr/dSUE64SbKXQrSir6gC6dtoIP2zsxeSqICtbAi8IEVQXUh lK7tSNQJfrzef7S794FSnkIisZqPmp7INFNzyLlCf52gHFq21oL6mMNt6MZYMi8vtlG8 mYSzCcvtPRDaKB7brnh2NG5YZ+pMmYoXmFJr/py3R+o1JH4ee+TjCnt3v+jfO/FAAAaR DGv3a2JesqEmqw5HGGCBltH866jAZTo7lUssOlf4LIF0mV9Ng2VuHtLPIbi/2258oL6F Ieoh6LcG6GYgSKjZCTFySlomYNHv8B0d9eAu+MoV77VFeE98arEipG28haK0tNo2ea4t B4ig== 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=yi90PohzodfA0f0F3opdU5Y7KIM7BsQWXsTZumhFpws=; b=EDP5E/ViZjWVVz5h683ksk9pecdbOWaU0OUKSQrFIT/Kg5R/SwFopq2RxPlkoJVhnm kSxXPUN85F3Q+JrFRiKLAwXE4mJwg/sk69bGKzLOj+1pfRw2V3+JL2E6FVhoF+Q3pJ3Y On6qehlUK2Qnj6HD2kaUlgMcGKL5Ps7Z32Zz8RlpGzmrrAscucgSgb0c+tw77QxQGug1 BaKAvc9ki5RHlbtT1TK1vEgPo/6KoGFSsHyC/Cp7nP9cMNbNP3XYhS1/+juVpl77E/BA 4nblmOvP4IJbksdZA6D/gClSqq6ySVDtyHQNb6XNBAW1OuuhGqPSm5vAzfr6780VUyb4 oo2g== X-Gm-Message-State: AMke39lUtT1MLviGqglUHjPgdOSBJDum1ZR3SiqeFo7YonTkigPGM6MW2uNUCCrOSaVqyg== X-Received: by 10.99.2.86 with SMTP id 83mr8781359pgc.5.1487753078388; Wed, 22 Feb 2017 00:44:38 -0800 (PST) Received: from [192.168.1.4] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id l22sm1979891pgc.35.2017.02.22.00.44.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 00:44:37 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 00:44:35 -0800 From: Jeff Tantsura To: Martin Bjorklund Message-ID: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types References: <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> In-Reply-To: <20170222.092522.195034997221928672.mbj@tail-f.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 08:44:40 -0000 Martin, please see inline Given your deep YANG expertise and contributions to both sides, I=E2=80=99d reall= y appreciate your advice. Cheers, Jeff =20 On 2/22/17, 00:25, "Martin Bjorklund" wrote: Hi, =20 Jeff Tantsura wrote: > Lou, >=20 > Yes, absolutely! >=20 > Please note - my goal is NOT to create more formal documents/YANG > versions/etc =E2=80=93 it is to get to the point we could reduce (eliminate > would be the grand goal) discrepancy between IETF and OpenConfig (by > now implemented by every vendor out there) models. =20 I just want to comment on this last point. It is simply not true. YANG is designed for and used in *lots* of other types of devices than routers, many of which do not implement the OC models. [jeff] This discussion has started in context of OC using ietf-routing-type= s, which is a product of RTGWG and meant to be used in routing realm =20 > Having OC using > ietf-routing-types without sacrificing functionality would be a great > starting point, tangible deliverable, achievable given both sides are > willing to co-operate. =20 My question about what the problem is is still not answered. Is the problem that the XSD regexp dialect is too primitive, or is it that the open implementations that exist cannot be used? [jeff] Rob did shed some light, I=E2=80=99ll be working towards a better problem = definition, please give me some time =20 > I=E2=80=99ll be talking to some of you during this and next week. >=20 > I believe RTGWG should provide venue for the discussion, let me > discuss this with co-chair and AD =20 A clarifying question - what does "the discussion" refer to? Is it about making sure ietf-routing-types can be used by others, or is it about making changes to the YANG language? [jeff] obviously, RTGWG is not the right place to decide on any YANG change= s, it is to discuss what is the problem and potential solution. [jeff] /*routing context*/ the fact that part of the industry can=E2=80=99t use w= hat has been produced by IETF is a serious issue that needs to be resolved, = it doesn=E2=80=99t do any good to either implementers or users. Rather than keepin= g on duplicating the work, and calling each other names we should work toget= her! =20 Jeff=20 =20 /martin =20 From nobody Wed Feb 22 01:12:24 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB52F129457; Wed, 22 Feb 2017 01:12:19 -0800 (PST) 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 8nzohXlWEjhe; Wed, 22 Feb 2017 01:12:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD701293DF; Wed, 22 Feb 2017 01:12:18 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id CEA721AE0187; Wed, 22 Feb 2017 10:12:15 +0100 (CET) Date: Wed, 22 Feb 2017 10:12:17 +0100 (CET) Message-Id: <20170222.101217.1995562365191986711.mbj@tail-f.com> To: jefftant.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 09:12:19 -0000 SmVmZiBUYW50c3VyYSA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiBNYXJ0aW4s DQo+IA0KPiBwbGVhc2Ugc2VlIGlubGluZQ0KPiANCj4gR2l2ZW4geW91ciBkZWVwIFlBTkcgZXhw ZXJ0aXNlIGFuZCBjb250cmlidXRpb25zIHRvIGJvdGggc2lkZXMsIEnigJlkDQo+IHJlYWxseSBh cHByZWNpYXRlIHlvdXIgYWR2aWNlLg0KPiANCj4gQ2hlZXJzLA0KPiBKZWZmDQo+ICANCj4gDQo+ IE9uIDIvMjIvMTcsIDAwOjI1LCAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWlsLWYuY29tPiB3 cm90ZToNCj4gDQo+ICAgICBIaSwNCj4gICAgIA0KPiAgICAgSmVmZiBUYW50c3VyYSA8amVmZnRh bnQuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiAgICAgPiBMb3UsDQo+ICAgICA+IA0KPiAgICAg PiBZZXMsIGFic29sdXRlbHkhDQo+ICAgICA+IA0KPiAgICAgPiBQbGVhc2Ugbm90ZSAtIG15IGdv YWwgaXMgTk9UIHRvIGNyZWF0ZSBtb3JlIGZvcm1hbCBkb2N1bWVudHMvWUFORw0KPiAgICAgPiB2 ZXJzaW9ucy9ldGMg4oCTIGl0IGlzIHRvIGdldCB0byB0aGUgcG9pbnQgd2UgY291bGQgcmVkdWNl IChlbGltaW5hdGUNCj4gICAgID4gd291bGQgYmUgdGhlIGdyYW5kIGdvYWwpIGRpc2NyZXBhbmN5 IGJldHdlZW4gSUVURiBhbmQgT3BlbkNvbmZpZyAoYnkNCj4gICAgID4gbm93IGltcGxlbWVudGVk IGJ5IGV2ZXJ5IHZlbmRvciBvdXQgdGhlcmUpIG1vZGVscy4NCj4gICAgIA0KPiAgICAgSSBqdXN0 IHdhbnQgdG8gY29tbWVudCBvbiB0aGlzIGxhc3QgcG9pbnQuICBJdCBpcyBzaW1wbHkgbm90IHRy dWUuDQo+ICAgICBZQU5HIGlzIGRlc2lnbmVkIGZvciBhbmQgdXNlZCBpbiAqbG90cyogb2Ygb3Ro ZXIgdHlwZXMgb2YgZGV2aWNlcyB0aGFuDQo+ICAgICByb3V0ZXJzLCBtYW55IG9mIHdoaWNoIGRv IG5vdCBpbXBsZW1lbnQgdGhlIE9DIG1vZGVscy4NCj4gW2plZmZdIFRoaXMgZGlzY3Vzc2lvbiBo YXMgc3RhcnRlZCBpbiBjb250ZXh0IG9mIE9DIHVzaW5nDQo+IGlldGYtcm91dGluZy10eXBlcywg d2hpY2ggaXMgYSBwcm9kdWN0IG9mIFJUR1dHIGFuZCBtZWFudCB0byBiZSB1c2VkDQo+IGluIHJv dXRpbmcgcmVhbG0NCg0KT2suDQoNCg0KPiAgICAgPiBIYXZpbmcgT0MgdXNpbmcNCj4gICAgID4g aWV0Zi1yb3V0aW5nLXR5cGVzIHdpdGhvdXQgc2FjcmlmaWNpbmcgZnVuY3Rpb25hbGl0eSB3b3Vs ZCBiZSBhIGdyZWF0DQo+ICAgICA+IHN0YXJ0aW5nIHBvaW50LCB0YW5naWJsZSBkZWxpdmVyYWJs ZSwgYWNoaWV2YWJsZSBnaXZlbiBib3RoIHNpZGVzIGFyZQ0KPiAgICAgPiB3aWxsaW5nIHRvIGNv LW9wZXJhdGUuDQo+ICAgICANCj4gICAgIE15IHF1ZXN0aW9uIGFib3V0IHdoYXQgdGhlIHByb2Js ZW0gaXMgaXMgc3RpbGwgbm90IGFuc3dlcmVkLiAgSXMgdGhlDQo+ICAgICBwcm9ibGVtIHRoYXQg dGhlIFhTRCByZWdleHAgZGlhbGVjdCBpcyB0b28gcHJpbWl0aXZlLCBvciBpcyBpdCB0aGF0DQo+ ICAgICB0aGUgb3BlbiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBleGlzdCBjYW5ub3QgYmUgdXNlZD8N Cj4gW2plZmZdIFJvYiBkaWQgc2hlZCBzb21lIGxpZ2h0LCBJ4oCZbGwgYmUgd29ya2luZyB0b3dh cmRzIGEgYmV0dGVyDQo+IHByb2JsZW0gZGVmaW5pdGlvbiwgcGxlYXNlIGdpdmUgbWUgc29tZSB0 aW1lDQoNCkkgZGlkbid0IHF1aXRlIHVuZGVyc3RhbmQgUm9iJ3MgY29tbWVudCwgc28gSSBsb29r IGZvcndhcmQgdG8gYQ0KcHJvYmxlbSBkZWZpbml0aW9uLg0KDQo+ICAgICA+IEnigJlsbCBiZSB0 YWxraW5nIHRvIHNvbWUgb2YgeW91IGR1cmluZyB0aGlzIGFuZCBuZXh0IHdlZWsuDQo+ICAgICA+ IA0KPiAgICAgPiBJIGJlbGlldmUgUlRHV0cgc2hvdWxkIHByb3ZpZGUgdmVudWUgZm9yIHRoZSBk aXNjdXNzaW9uLCBsZXQgbWUNCj4gICAgID4gZGlzY3VzcyB0aGlzIHdpdGggY28tY2hhaXIgYW5k IEFEDQo+ICAgICANCj4gICAgIEEgY2xhcmlmeWluZyBxdWVzdGlvbiAgLSB3aGF0IGRvZXMgInRo ZSBkaXNjdXNzaW9uIiByZWZlciB0bz8gIElzIGl0DQo+ICAgICBhYm91dCBtYWtpbmcgc3VyZSBp ZXRmLXJvdXRpbmctdHlwZXMgY2FuIGJlIHVzZWQgYnkgb3RoZXJzLCBvciBpcyBpdA0KPiAgICAg YWJvdXQgbWFraW5nIGNoYW5nZXMgdG8gdGhlIFlBTkcgbGFuZ3VhZ2U/DQo+IFtqZWZmXSBvYnZp b3VzbHksIFJUR1dHIGlzIG5vdCB0aGUgcmlnaHQgcGxhY2UgdG8gZGVjaWRlIG9uIGFueSBZQU5H DQo+IGNoYW5nZXMsIGl0IGlzIHRvIGRpc2N1c3Mgd2hhdCBpcyB0aGUgcHJvYmxlbSBhbmQgcG90 ZW50aWFsIHNvbHV0aW9uLg0KDQpPay4NCg0KPiBbamVmZl0gLypyb3V0aW5nIGNvbnRleHQqLyB0 aGUgZmFjdCB0aGF0IHBhcnQgb2YgdGhlIGluZHVzdHJ5IGNhbuKAmXQNCj4gdXNlIHdoYXQgaGFz IGJlZW4gcHJvZHVjZWQgYnkgSUVURiBpcyBhIHNlcmlvdXMgaXNzdWUgdGhhdCBuZWVkcyB0byBi ZQ0KPiByZXNvbHZlZCwgaXQgZG9lc27igJl0IGRvIGFueSBnb29kIHRvIGVpdGhlciBpbXBsZW1l bnRlcnMgb3INCj4gdXNlcnMuIFJhdGhlciB0aGFuIGtlZXBpbmcgb24gZHVwbGljYXRpbmcgdGhl IHdvcmssIGFuZCBjYWxsaW5nIGVhY2gNCj4gb3RoZXIgbmFtZXMgd2Ugc2hvdWxkIHdvcmsgdG9n ZXRoZXIhDQoNCkkgZG9uJ3QgdGhpbmsgSSBoYXZlIGJlZW4gY2FsbGluZyBhbnlvbmUgbmFtZXMu ICBJIGFsd2F5cyB0cnkgaGFyZCB0bw0Ka2VlcCB0aGUgZGlzY3Vzc2lvbnMgYXQgYSB0ZWNobmlj YWwgbGV2ZWwuDQoNCkdvaW5nIGJhY2sgdG8gdGhlIGlzc3VlIG9uIHJlZ2V4cHMsIEkgKGFuZCBw cm9iYWJseSBvdGhlcnMpIGhhdmUNCnByb3Bvc2VkIGEgd2F5IGZvciBPQyB0byB3b3JrIGFyb3Vu ZCB0aGUgcHJvYmxlbSAtIHVzZSBhbiBvYy1zcGVjaWZpYw0KZXh0ZW5zaW9uIHN0YXRlbWVudCwg c28gaW5zdGVhZCBvZiBkb2luZzoNCg0KICB0eXBlIHN0cmluZyB7DQogICAgICBwYXR0ZXJuICde WzAtOWEtZkEtRl17Mn0oOlswLTlhLWZBLUZdezJ9KXs1fSQnOw0KICB9DQoNCm9uZSBjb3VsZCBk bzoNCg0KICB0eXBlIHN0cmluZyB7DQogICAgICBvYzpwYXR0ZXJuICdeWzAtOWEtZkEtRl17Mn0o OlswLTlhLWZBLUZdezJ9KXs1fSQnOw0KICB9DQoNCg0KVGhpcyB3b3VsZCBhdm9pZCB0aGUgZm9y ayBvZiBZQU5HIHRoYXQgYWN0dWFsbHkgaGFzIGhhcHBlbmVkIG5vdy4NCg0KDQovbWFydGluDQo= From nobody Wed Feb 22 03:52:50 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56687129713 for ; Wed, 22 Feb 2017 03:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 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_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable 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 Jw1aViJr9Ybe for ; Wed, 22 Feb 2017 03:52:47 -0800 (PST) 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 048CB129702 for ; Wed, 22 Feb 2017 03:52:47 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id B690D1E088C for ; Wed, 22 Feb 2017 04:52:46 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nnsi1u00e2SSUrH01nslV8; Wed, 22 Feb 2017 04:52:46 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=n2v9WMKugxEA:10 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=xskcdSivAAAA:8 a=NEAV23lmAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=ITZAD2doMzyLMILuwRwA:9 a=8QDxolFdt2zxilha:21 a=tPCiYej8whfJXTjo:21 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=B8SJYIqRPU5_XtF5Z38x:22 a=Bn2pgwyD2vrAyMmN8A2t:22 a=TSZmLRzkpGLBZRr3r8m8: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=7q4UoBOpD6hq+jk9k3uLBhZ1Ik/88/5rdJ/M4eRHlzo=; b=SihSD+ehhHjPUGm9pK+pcyQgWZ yFRMSXEvnB6kDbTTh2zz1Z//l9XslH7842zHes4HqPKsaJm5vCd2K48aFsAnIl3Z5qnE1pZE0A46y 4VlMTL3TZZoN2dyiTV4VuGhl3; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:45176 helo=[11.4.0.102]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cgVTL-0002Sy-Hq; Wed, 22 Feb 2017 04:52:39 -0700 From: Lou Berger To: Jeff Tantsura , Kent Watsen , Andy Bierman , Benoit Claise , Anees Shaikh Date: Wed, 22 Feb 2017 06:52:42 -0500 Message-ID: <15a65aa9310.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> <5e1c7fb8-2ca3-35bc-3de2-d506fc1a7523@labn.net> <15D625FF-F977-437D-8439-C485F7324267@gmail.com> User-Agent: AquaMail/1.7.2-121 (build: 100700200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" 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.85.191 X-Exim-ID: 1cgVTL-0002Sy-Hq X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([11.4.0.102]) [100.15.85.191]:45176 X-Source-Auth: lberger@labn.net X-Email-Count: 12 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: RTG YANG Design Team , Phil Shafer , Xufeng Liu , Yingzhen Qu , Alia Atlas , YANG Doctors , Rob Shakir , "Acee Lindem \(acee\)" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 11:52:48 -0000 Jeff, On February 22, 2017 2:58:10 AM Jeff Tantsura wrote: > Lou, > > Yes, absolutely! > Glad to hear that you'll lead this discussion. .... > > I believe RTGWG should provide venue for the discussion, let me discuss > this with co-chair and AD > I may have misunderstood something here. If the issue is specific to routing types, it certainly should be discussed in the context of the rtg area dt and the routing wg. But if the context is yang in general, which I thought was your point, the discussion belongs in the netmod working group. This will ensure that the right expertise is in the room to help *solve* the issue being raised. I of course will defer to the ADs on this. Lou > Thanks, > Jeff > > > On 2/21/17, 09:38, "Lou Berger" wrote: > > Thanks kent - I read this as also being open to discussing in the WG. > > Jeff, > > You do you want to take the lead on putting something together on > this to drive discussion in Chicago? If not, who is the right person? > > Thanks, > > Lou > > > On 2/21/2017 12:33 PM, Kent Watsen wrote: > > > > [+phil] > > > > > > > > My chair response is that we'd need to see if there is sufficient WG > > interest to propose making a change. Certainly, a solution that could > > augment the existing solution in a way that didn't break existing > > clients without warning would be good (e.g., YANG-next). > > > > > > > > My contributor response is that JUNOS also struggles to support XSD > > regex. In fact, I think that it has always used POSIX regex and > > continues to do so to this day. Phil might have more to say on this > > point. > > > > > > > > Thanks, > > > > Kent > > > > > > > > > > > > > > > > On 2/21/17, 12:24 PM, "Andy Bierman" > > wrote: > > > > > > > > Hi, > > > > > > > > > > > > Maybe the openconfig folks are just looking for reasons to ignore the > > IETF modules. > > > > Implementation details such as regexp are not the type of thing the IETF > > > > discusses at length. libxml2 is widely deployed, so "lack of > > implementations" > > > > does not seem true. > > > > > > > > Google has over 900 opensource projects listed on github: > > > > https://github.com/google > > > > > > > > You would think they would have an implementation of this regexp in > > there somewhere. ;-) > > > > > > > > It would require a new version of YANG that breaks backward compatibility > > > > with v1.0 and 1.1 to change this. Not sure it is really worth it. > > > > > > > > > > > > Andy > > > > > > > > > > > > On Tue, Feb 21, 2017 at 12:58 AM, Benoit Claise > > wrote: > > > > Including the YANG doctors on this important topic. > > > > Regards, Benoit > > > > As I wrote the initial email. I can probably add some comments > > at the next meeting. > > > > > > > > We have examined multiple times rewriting of regexps from the > > W3C standard to something that is more commonly supported. And > > to be frank, it's not a useful task to spend time on. Worse, > > the existing IETF types modules use elements such as \p{L} > > when AFAICS, there is no reason not to use [a-zA-Z] for all > > practical use cases (I know of no system that has an interface > > that needs to be zoned to 🍺 for example). > > > > > > > > r. > > > > > > > > On Mon, 20 Feb 2017 at 17:49 Lou Berger > > wrote: > > > > [Adding Kent as netmod co-chair, netmod AD is already on > > the list.] > > > > Jeff, > > > > This is an important user perspective. I personally > > am open to > > changing the regexp reference in YANG (see [1]), *but* I > > think this > > would required rev'ing YANG (to 1.2, for example) to do so. > > > > Also, in poking around, I can only find posix definitions > > behind > > pay-walls, which may be an issue - but as IAB is > > responsible for IETF > > liaisons, perhaps you could run this part to ground ;-) > > > > If Kent is agreeable, I'd be open to having an > > presentation and > > discussion on this (even without a draft) at the next meeting. > > > > Kent? > > > > Thanks, > > > > Lou > > > > [1] https://tools.ietf.org/html/rfc7950#section-9.4.5 > > On 2/20/2017 7:55 PM, Jeff Tantsura wrote: > > > HI, > > > > > > I have been having some discussion with OC folks > > (privately), I’d really want to see convergence between OC > > and IETF. > > > > > > Below is the explanation why not to use IETF version. > > Do you think there’s anything we could do (Lou?) > > > > > > “For types modules, there's a pretty interesting problem > > (AFAICS). We have found that the W3C standard that is > > being used for regexp has very limited support. We've > > actually forked our types modules to stop referencing IETF > > ones, since we're aiming to use a regexp standard that is > > more commonly supported (POSIX). > > > > > > When I've raised this privately, there seems to be a > > bunch of opposition to even discussing such implementation > > questions - such that forking and moving forward seems a > > much more effective solution. Whilst I can't speak for OC, > > personally, I'd oppose trying to split our types across > > IETF and OC as it adds to the implementation complexity. > > > > > > Perhaps with your new hat, it might be possible for us > > to discuss further what IETF's interest is in usability > > vs. long-winded NETMOD discussions :-) that seem to reach > > few answers.” > > > > > > > > > Cheers, > > > Jeff > > > > > > > > > > > > _______________________________________________ > > > Rtg-dt-yang-arch mailing list > > > Rtg-dt-yang-arch@ietf.org > > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > _______________________________________________ > > Rtg-dt-yang-arch mailing list > > Rtg-dt-yang-arch@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > > > > > _______________________________________________ > > > > Rtg-dt-yang-arch mailing list > > > > Rtg-dt-yang-arch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > > > > > > > > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > > > > > > > > > > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch From nobody Wed Feb 22 04:02:39 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330A1129717 for ; Wed, 22 Feb 2017 04:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 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_H2=-1.887, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable 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 Pq6YyMO7TAPh for ; Wed, 22 Feb 2017 04:02:36 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id DB439129713 for ; Wed, 22 Feb 2017 04:02:35 -0800 (PST) Received: (qmail 1405 invoked by uid 0); 22 Feb 2017 12:02:32 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 22 Feb 2017 12:02:32 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id no2G1u0132SSUrH01o2K9k; Wed, 22 Feb 2017 05:02:20 -0700 X-Authority-Analysis: v=2.1 cv=GtPRpCFC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=n2v9WMKugxEA:10 a=u07AKapRAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=B3rNQ6RLTAEPLWEZUMEA:9 a=4kMiN320KSdRnd1-:21 a=oYvM9SUcEqGeQZXQ:21 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 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: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=QX2lMCAVvMPmgBbroyX8vlbTEIEDsQvE5oCzXjmMdmI=; b=jRbsBPj5ecD9T9wecionV+EByY 89bUxr+323sXgaIFhEivlQL5yh7YQbU2OqmIf2yMMWzjUSrB0OaAaO5hL4gWv0DCsYut7dqin8jtx 59Moa2J2ilLhP3mtj7j9V1ouI; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:45188 helo=[11.4.0.102]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cgVcM-00047O-QC; Wed, 22 Feb 2017 05:01:59 -0700 From: Lou Berger To: Martin Bjorklund , Date: Wed, 22 Feb 2017 07:02:01 -0500 Message-ID: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <20170222.101217.1995562365191986711.mbj@tail-f.com> References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> User-Agent: AquaMail/1.7.2-121 (build: 100700200) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8" 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.85.191 X-Exim-ID: 1cgVcM-00047O-QC X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([11.4.0.102]) [100.15.85.191]:45188 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:02:37 -0000 See below. On February 22, 2017 4:12:54 AM Martin Bjorklund wrote: > Jeff Tantsura wrote: >> Martin, >> >> please see inline >> >> Given your deep YANG expertise and contributions to both sides, I’d >> really appreciate your advice. >> >> Cheers, >> Jeff >> >> >> On 2/22/17, 00:25, "Martin Bjorklund" wrote: >> >> Hi, >> >> Jeff Tantsura wrote: >> > Lou, >> > >> > Yes, absolutely! >> > >> > Please note - my goal is NOT to create more formal documents/YANG >> > versions/etc – it is to get to the point we could reduce (eliminate >> > would be the grand goal) discrepancy between IETF and OpenConfig (by >> > now implemented by every vendor out there) models. >> >> I just want to comment on this last point. It is simply not true. >> YANG is designed for and used in *lots* of other types of devices than >> routers, many of which do not implement the OC models. >> [jeff] This discussion has started in context of OC using >> ietf-routing-types, which is a product of RTGWG and meant to be used >> in routing realm > > Ok. > As stated in my previous mail, if the problem is with routing types it is certainly appropriate to fix it in the routing working group. > >> > Having OC using >> > ietf-routing-types without sacrificing functionality would be a great >> > starting point, tangible deliverable, achievable given both sides are >> > willing to co-operate. >> >> My question about what the problem is is still not answered. Is the >> problem that the XSD regexp dialect is too primitive, or is it that >> the open implementations that exist cannot be used? >> [jeff] Rob did shed some light, I’ll be working towards a better >> problem definition, please give me some time > > I didn't quite understand Rob's comment, so I look forward to a > problem definition. > >> > I’ll be talking to some of you during this and next week. >> > >> > I believe RTGWG should provide venue for the discussion, let me >> > discuss this with co-chair and AD >> >> A clarifying question - what does "the discussion" refer to? Is it >> about making sure ietf-routing-types can be used by others, or is it >> about making changes to the YANG language? >> [jeff] obviously, RTGWG is not the right place to decide on any YANG >> changes, it is to discuss what is the problem and potential solution. > > Ok. Once you get into potential solutions that go beyond a single module, i.e., are changes to yang, it's really best to have the discussion in the location the general Yang expertise, ie net mod. > >> [jeff] /*routing context*/ the fact that part of the industry can’t >> use what has been produced by IETF is a serious issue that needs to be >> resolved, it doesn’t do any good to either implementers or >> users. 100% agree. >> Rather than keeping on duplicating the work, and calling each >> other names we should work together! > > I don't think I have been calling anyone names. I always try hard to > keep the discussions at a technical level. > > Going back to the issue on regexps, I (and probably others) have > proposed a way for OC to work around the problem - use an oc-specific > extension statement, so instead of doing: > > type string { > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } > > one could do: > > type string { > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } > > > This would avoid the fork of YANG that actually has happened now. > This is a good approach if it works - it's certainly an order of magnitude or two simpler than bumping yang revs! Is there any reason to *not* include it in routing types if it addresses the base comment? Rob/Anees, Would this address your issue? Lou PS thanks for illustrating why it's so important to ensure that the right expertise is part of the discussion, as well as the value of focusing on solving a raised issue. > > /martin > _______________________________________________ > Rtg-dt-yang-arch mailing list > Rtg-dt-yang-arch@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch From nobody Wed Feb 22 04:15:57 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6804129721; Wed, 22 Feb 2017 04:15:56 -0800 (PST) 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, 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 EwER3jdws6rn; Wed, 22 Feb 2017 04:15:55 -0800 (PST) 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 34AC7129579; Wed, 22 Feb 2017 04:15:55 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 03D797A0; Wed, 22 Feb 2017 13:15:54 +0100 (CET) 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 mXfcLRM5m0M0; Wed, 22 Feb 2017 13:15:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Feb 2017 13:15:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94F15200CB; Wed, 22 Feb 2017 13:15:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GQVsQSG2ZLHE; Wed, 22 Feb 2017 13:15:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1718200C9; Wed, 22 Feb 2017 13:15:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3E1F73E835AB; Wed, 22 Feb 2017 13:15:55 +0100 (CET) Date: Wed, 22 Feb 2017 13:15:55 +0100 From: Juergen Schoenwaelder To: Lou Berger Message-ID: <20170222121555.GD44810@elstar.local> Mail-Followup-To: Lou Berger , Martin Bjorklund , jefftant.ietf@gmail.com, rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, rjs@rob.sh, yingzhen.qu@huawei.com References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:15:56 -0000 On Wed, Feb 22, 2017 at 07:02:01AM -0500, Lou Berger wrote: > > Going back to the issue on regexps, I (and probably others) have > > proposed a way for OC to work around the problem - use an oc-specific > > extension statement, so instead of doing: > > > > type string { > > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > > } > > > > one could do: > > > > type string { > > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > > } > > > > > > This would avoid the fork of YANG that actually has happened now. > > > > This is a good approach if it works - it's certainly an order of magnitude > or two simpler than bumping yang revs! > > Is there any reason to *not* include it in routing types if it addresses the > base comment? > > Rob/Anees, > Would this address your issue? > > Lou > > PS thanks for illustrating why it's so important to ensure that the right > expertise is part of the discussion, as well as the value of focusing on > solving a raised issue. I think we need a clear problem statement before discussing any solutions. Adding a new extension statement that none of the existing tools understands also comes with a cost. There is a difference between OC adding an extension for OC usage or the IETF adding an extension for general usage. /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 Feb 22 04:26:47 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65471297B8; Wed, 22 Feb 2017 04:26:43 -0800 (PST) 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 wMdfxN-aTx5m; Wed, 22 Feb 2017 04:26:42 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4054D1297A8; Wed, 22 Feb 2017 04:26:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4956; q=dns/txt; s=iport; t=1487766402; x=1488976002; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YycB+pu00Qyh66WhNWaDhqQWqGpEvpK2wZS/H6EVhAc=; b=MWLEa6ZZEcn2AKdHyxcnEfi/rRzcFEbPj9fLxDrGfwhQW6wda+9YNE32 +iIUgJPgvyqutnYAmR3XjWTO8HWldUENhZ67wRT2JkMpntDG9UgFldyNC sItqqUrLi6p8U0VTZrxgdww39cm3rQfRMdBICrQkofih0Vh+A3Z9fFtD2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQBHgq1Y/4oNJK1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1FhgQkHjVyRWogMjSiCDR8LhXgCgnk/GAECAQEBAQEBAWIohHEBAQQ?= =?us-ascii?q?BAWkDCxACAQgOCi4hBgslAgQBDQUbh20DgVIDFQ6xF4dCDYN3AQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGAWKMoEJglGBZgEBhWEfBZtWOgGKFYNuhB+Be4UciXmKQYh?= =?us-ascii?q?jAR84gQBUFT6ESx2BYXWHZoEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.35,194,1484006400"; d="scan'208";a="209780194" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 12:26:41 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v1MCQeMf000813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 12:26:41 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Feb 2017 07:26:40 -0500 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; Wed, 22 Feb 2017 07:26:40 -0500 From: "Acee Lindem (acee)" To: Lou Berger , Martin Bjorklund , "jefftant.ietf@gmail.com" Thread-Topic: [Rtg-dt-yang-arch] [yang-doctors] Open Config on ietf-routing-types Thread-Index: AQHSjQOkTHy45oibVEmKzZE0s3AunqF088uA Date: Wed, 22 Feb 2017 12:26:40 +0000 Message-ID: References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> 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.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , "phil@juniper.net" , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "yang-doctors@ietf.org" , "rjs@rob.sh" , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:26:44 -0000 See a couple inlines=8A On 2/22/17, 7:02 AM, "Lou Berger" wrote: >See below. > > >On February 22, 2017 4:12:54 AM Martin Bjorklund wrote: > >> Jeff Tantsura wrote: >>> Martin, >>> >>> please see inline >>> >>> Given your deep YANG expertise and contributions to both sides, I=B9d >>> really appreciate your advice. >>> >>> Cheers, >>> Jeff >>> >>> >>> On 2/22/17, 00:25, "Martin Bjorklund" wrote: >>> >>> Hi, >>> >>> Jeff Tantsura wrote: >>> > Lou, >>> > >>> > Yes, absolutely! >>> > >>> > Please note - my goal is NOT to create more formal documents/YANG >>> > versions/etc =AD it is to get to the point we could reduce >>>(eliminate >>> > would be the grand goal) discrepancy between IETF and OpenConfig >>>(by >>> > now implemented by every vendor out there) models. >>> >>> I just want to comment on this last point. It is simply not true. >>> YANG is designed for and used in *lots* of other types of devices >>>than >>> routers, many of which do not implement the OC models. >>> [jeff] This discussion has started in context of OC using >>> ietf-routing-types, which is a product of RTGWG and meant to be used >>> in routing realm >> >> Ok. >> > >As stated in my previous mail, if the problem is with routing types it is >certainly appropriate to fix it in the routing working group. The issue is obviously related to YANG in general. There is currently no YANG construct to use POSIX expressions to model strings. > > >> >>> > Having OC using >>> > ietf-routing-types without sacrificing functionality would be a >>>great >>> > starting point, tangible deliverable, achievable given both >>>sides are >>> > willing to co-operate. >>> >>> My question about what the problem is is still not answered. Is >>>the >>> problem that the XSD regexp dialect is too primitive, or is it that >>> the open implementations that exist cannot be used? >>> [jeff] Rob did shed some light, I=B9ll be working towards a better >>> problem definition, please give me some time >> >> I didn't quite understand Rob's comment, so I look forward to a >> problem definition. >> >>> > I=B9ll be talking to some of you during this and next week. >>> > >>> > I believe RTGWG should provide venue for the discussion, let me >>> > discuss this with co-chair and AD >>> >>> A clarifying question - what does "the discussion" refer to? Is >>>it >>> about making sure ietf-routing-types can be used by others, or is >>>it >>> about making changes to the YANG language? >>> [jeff] obviously, RTGWG is not the right place to decide on any YANG >>> changes, it is to discuss what is the problem and potential solution. >> >> Ok. > >Once you get into potential solutions that go beyond a single module, >i.e.,=20 >are changes to yang, it's really best to have the discussion in the >location the general Yang expertise, ie net mod. > >> >>> [jeff] /*routing context*/ the fact that part of the industry can=B9t >>> use what has been produced by IETF is a serious issue that needs to be >>> resolved, it doesn=B9t do any good to either implementers or >>> users. > >100% agree. > >>> Rather than keeping on duplicating the work, and calling each >>> other names we should work together! >> >> I don't think I have been calling anyone names. I always try hard to >> keep the discussions at a technical level. >> >> Going back to the issue on regexps, I (and probably others) have >> proposed a way for OC to work around the problem - use an oc-specific >> extension statement, so instead of doing: >> >> type string { >> pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >> } >> >> one could do: >> >> type string { >> oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >> } >> >> >> This would avoid the fork of YANG that actually has happened now. >> > >This is a good approach if it works - it's certainly an order of >magnitude=20 >or two simpler than bumping yang revs! With this YANG extension, would we specify both types of pattern for common reusable types? I think we need a quick POSIX extension draft to precisely define the semantics. Thanks, Acee > >Is there any reason to *not* include it in routing types if it addresses >the base comment? > >Rob/Anees, > Would this address your issue? > >Lou > >PS thanks for illustrating why it's so important to ensure that the right >expertise is part of the discussion, as well as the value of focusing on >solving a raised issue. > >> >> /martin >> _______________________________________________ >> Rtg-dt-yang-arch mailing list >> Rtg-dt-yang-arch@ietf.org >> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch > > From nobody Wed Feb 22 04:30:57 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251461297AC; Wed, 22 Feb 2017 04:30:55 -0800 (PST) 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 czIewRMYkuev; Wed, 22 Feb 2017 04:30:48 -0800 (PST) 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 0BA9B1297B8; Wed, 22 Feb 2017 04:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1911; q=dns/txt; s=iport; t=1487766648; x=1488976248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F5zB8PP6nsKlfIl0ZHQPBymBFY+GohcKWO7/tfRDQZU=; b=hIN5oy+MWJRoEZ0Ixz0cIaoW1GZ2YOR6mnHKJNEOiyJbZDkyjrLPjqUa q/CxPDmbnwDN2DMpX4YKVOzzlqFBm3uVyitk26fZAwzhaTFnuDs3kF1ih yS3+qaCZGwloxgScUzI5JZcHniW9lVnydJCBLTFUsojg+myne7B2sZ9bO A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQAehK1Y/4UNJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRYYEJB41ckVqVNIINJoV8AoJ6PxgBAgEBAQEBAQFiKIRxAQU?= =?us-ascii?q?6MQ4OAgIBCA4CCB4QGxclAgQBDQUbiVqxKItGAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHQWLNoR1JoR/HwWcEAGKFYgNkRCTJAEfOIEAVBWHB3WJB4ENAQEB?= X-IronPort-AV: E=Sophos;i="5.35,194,1484006400"; d="scan'208";a="388077103" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Feb 2017 12:30:47 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v1MCUk13016267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Feb 2017 12:30:47 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 22 Feb 2017 07:30:46 -0500 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; Wed, 22 Feb 2017 07:30:46 -0500 From: "Acee Lindem (acee)" To: Juergen Schoenwaelder , Lou Berger Thread-Topic: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types Thread-Index: AQHSjQVuINN50X5DZE2TSllcbytXyaF09OyA Date: Wed, 22 Feb 2017 12:30:46 +0000 Message-ID: References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222121555.GD44810@elstar.local> In-Reply-To: <20170222121555.GD44810@elstar.local> 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.196] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , "phil@juniper.net" , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "rjs@rob.sh" , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:30:55 -0000 On 2/22/17, 7:15 AM, "Juergen Schoenwaelder" wrote: >On Wed, Feb 22, 2017 at 07:02:01AM -0500, Lou Berger wrote: >> > Going back to the issue on regexps, I (and probably others) have >> > proposed a way for OC to work around the problem - use an oc-specific >> > extension statement, so instead of doing: >> >=20 >> > type string { >> > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >> > } >> >=20 >> > one could do: >> >=20 >> > type string { >> > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >> > } >> >=20 >> >=20 >> > This would avoid the fork of YANG that actually has happened now. >> >=20 >>=20 >> This is a good approach if it works - it's certainly an order of >>magnitude >> or two simpler than bumping yang revs! >>=20 >> Is there any reason to *not* include it in routing types if it >>addresses the >> base comment? >>=20 >> Rob/Anees, >> Would this address your issue? >>=20 >> Lou >>=20 >> PS thanks for illustrating why it's so important to ensure that the >>right >> expertise is part of the discussion, as well as the value of focusing on >> solving a raised issue. > >I think we need a clear problem statement before discussing any >solutions. Adding a new extension statement that none of the existing >tools understands also comes with a cost. There is a difference >between OC adding an extension for OC usage or the IETF adding an >extension for general usage. But this is the case for any extension. I think it has to be a general IETF extension so that it can be readily used by IETF modules including routing types.=20 Acee=20 > >/js > >--=20 >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 Feb 22 04:36:39 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DAA1297CB; Wed, 22 Feb 2017 04:36:37 -0800 (PST) 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 pWQGywE36dN9; Wed, 22 Feb 2017 04:36:35 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67DBF1297C9; Wed, 22 Feb 2017 04:36:35 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 4FC511AE0187; Wed, 22 Feb 2017 13:36:31 +0100 (CET) Date: Wed, 22 Feb 2017 13:36:32 +0100 (CET) Message-Id: <20170222.133632.1310891825599234865.mbj@tail-f.com> To: lberger@labn.net From: Martin Bjorklund In-Reply-To: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.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: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:36:37 -0000 Lou Berger wrote: > See below. > > > On February 22, 2017 4:12:54 AM Martin Bjorklund > wrote: [...] > > Going back to the issue on regexps, I (and probably others) have > > proposed a way for OC to work around the problem - use an oc-specific > > extension statement, so instead of doing: > > > > type string { > > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > > } > > > > one could do: > > > > type string { > > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > > } > > > > > > This would avoid the fork of YANG that actually has happened now. > > > > This is a good approach if it works - it's certainly an order of > magnitude or two simpler than bumping yang revs! > > Is there any reason to *not* include it in routing types if it > addresses the base comment? I think there are two issues. The first is how OC can specify patterns in their preferred regexp dialect in their own modules. My proposal above is one way of doing that, in a way that is 100% YANG compliant. [Side note: this is common practise; we have our own extension statements that can be used to restrict certain types, and I am pretty sure that yumapro and libyang etc all have similar extensions.] The other issue is how OC can utilize IETF modules with regexps written in the standard dialect. IMO this is more an implementation matter. The "pattern" statement formally defines a constraint on the value space, but there is nothing that requires an implementation to use the pattern exactly as it is specified. A toolchain that doesn't understand the XSD regexp dialect can simply ignore the pattern; or if it is clever and maybe doesn't really care about unicode it can translate the pattern to another dialect automatically; or if it is even more clever it can translate if possible or otherwise use a user-provided regexp in another dialect. These are just suggestions of course, I'm sure there are other ways of dealing with this. This said, I don't think it's a good idea to define an openconfig specific extension in the ietf-routing-types document, and I also don't think that the IETF should define a second way of defining regexp patterns. Having two very similar ways of doing the same thing often leads to more problems than it solves. /martin From nobody Wed Feb 22 04:47:17 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC09B1297EE; Wed, 22 Feb 2017 04:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 G0IgDpee_4R0; Wed, 22 Feb 2017 04:47:11 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 708B41297EB; Wed, 22 Feb 2017 04:47:11 -0800 (PST) Received: from tops.chopps.org (97-83-46-222.dhcp.trcy.mi.charter.com [97.83.46.222]) (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 CE87A61B5B; Wed, 22 Feb 2017 12:47:08 +0000 (UTC) References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Martin Bjorklund In-reply-to: <20170222.101217.1995562365191986711.mbj@tail-f.com> Date: Wed, 22 Feb 2017 07:47:03 -0500 Message-ID: <87h93m5r5k.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: rtg-dt-yang-arch@ietf.org, lberger@labn.net, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:47:13 -0000 --=-=-= Content-Type: text/plain Martin Bjorklund writes: > Going back to the issue on regexps, I (and probably others) have > proposed a way for OC to work around the problem - use an oc-specific > extension statement, so instead of doing: > > type string { > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } > > one could do: > > type string { > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } > > > This would avoid the fork of YANG that actually has happened now. If after discussing the merits of POSIX regexp we decide that adding POSIX regexp is useful beyond just OpenConfig, would we just create a new posix-regex module that adds the POSIX regular expression syntax then? If so that sounds like a great solution to me. As to any possible 100 message long email thread that I probably don't have time to participate in, I'd say perfect is the enemy of good, and if the feature is optional letting the market decide is sometimes a very effective way of judging somethings usefulness. :) Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlitiEcACgkQLh2DDte4 MCUYDw//ZZHXSaanDlj88Dc9erPqvlX2+HV3Cf4YUtfWrU+MlR79WwSreYzRi+v0 jR7IhwtyDsbOOw0yBrl8cJT2Tqvyux9VfB77uU5B/TFJYt/LcaHFpyDPZrvmSELe yfA3wJaOUbOmP66sEbkphCMfEUpNcyXezxT1TR4aECH342dsBWgmwP5PZqtNa55d krHC5gFlRcb//WQM/GuqoWtiQHhZD2DRJSPFg6QFtsGdAPUaiaWLMLKZC5YCw/3Z BGl4nTWkkp021dE567ivkamAq0JZhWvR3Ydi5I0Kkfx6uk7rcsxbMADKFhQPE6yL 4vY2ilfPoJo/9SeWAJa3tWOmjaF1XrptMfmQEgJqX0/x+SFo4UyLIj47BZPuw3s2 VNMWdrz+XZlPEBIfRzvEvCOtKuyNYRJgi24+erm3no21AIGvErAQRH1sm1i9D+zF AKmRmhOriZwuNwPiQgkUW9roLONgsrzTX8+M3WY70O8KBr+30sP/ptey/94fyn1s CU3ZxxkCFH4cn0OnBIhdmDQmky1edITO9tsSk5NYb8M4FAJIsi+V3x8xXc6RYC3c kqBfggrIkQFM5GWkhChtw2N4fvef+R93lziDb6+EYrbb9K+Bj7yh+uCSD3an3mt/ 90MZZyK96Yml5E6SnYrehVez35zMjWZDjO/he1x14iaHLvsAUWo= =UvXv -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 22 04:52:30 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B981297F0; Wed, 22 Feb 2017 04:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lZR7IoLAhQX9; Wed, 22 Feb 2017 04:52:27 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC361297EB; Wed, 22 Feb 2017 04:52:27 -0800 (PST) Received: from tops.chopps.org (97-83-46-222.dhcp.trcy.mi.charter.com [97.83.46.222]) (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 DEBA661B5B; Wed, 22 Feb 2017 12:52:25 +0000 (UTC) References: <9AC86767-FADD-4E96-8710-C7968FF63963@gmail.com> <3a70aee6-da36-fc4c-6f20-5599e50a31ec@labn.net> <5a87446b-3b1b-aec4-0dd1-fe46f65f7080@cisco.com> User-agent: mu4e 0.9.19; emacs 25.1.1 From: Christian Hopps To: Andy Bierman In-reply-to: Date: Wed, 22 Feb 2017 07:52:25 -0500 Message-ID: <87fuj65qwm.fsf@chopps.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: RTG YANG Design Team , Rob Shakir , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Lou Berger , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:52:28 -0000 --=-=-= Content-Type: text/plain Andy Bierman writes: > Hi, > > The pattern syntax has not really changed since the early drafts in 2008, > so it is a bit surprising to hear that it is a show-stopper in 2017. To be fair I think a lot of routing folks (and perhaps others) only started trying to use YANG in the last couple of years. I don't think it's a show-stopper (Lada's did use this term referring to regexp without unicode support), but it's causing the Open Config folks to define their own common type modules, if I understand the issue correctly. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlitiYkACgkQLh2DDte4 MCWjlg//YHpbsz0nh3NYNeJoS2uz4kiGzxekahAZBok4r+Qhn2R7vVlUMMNDr6fj fm1gnl/WykjIsgBlfXwbFkOXJWriUiSh0M+nAjnMcQ0650scXlba1oO/DD3ihyY9 Axevs9baQGRbcQvOSofswU/hgPguZ4CSXQdeTRtPOTqDDHPOTEdv3Nmo8Kv/2vZW 1FPVbqaqXWzPGB+/NC45iWu6ZXA17EL9n3urb4lnJtx8yVxj6rNIqrbNs2oXtAaN 6YjBiV+cMMGRNU4iDJ8VNW5s8N1o1F9bC0JmbCldw9u4UXCIzXRUJe+N7Rx9+bDb ic+V+V3ujF60YLgJ4g6LzFGCxUYPfi7pdEJ9iMKkNP1yuZM0xvExef3DA1p5fNUz t6ZMRXd5FvZt9z4jcNWyAs2dmDlTn439xoZahrdK4hCLY5vpq0JhSNyxIa7wom9S Edp3iJa3DZNyeewn69w7d8jGMbNTu/eNVaKPyvsPRMFUBUca6Pne8HE34i/5nnEK yIgUp7wUj4QeB3JVFwVFT0ugTYbEyadPY11IFNQNlah/llk5fTWsMpvaHyeKSr9S wWQy3zHaxAMyMIAjuL8trnO5coylrKHwnK81fPGddzmzTszR5HfaQiAT103q6HWE SEtOnLgD9bTeMCNxLbdjWcI0OhVLehTkd5lmq0tYlNhL8XtSdII= =UG0C -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 22 04:55:05 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75499129841; Wed, 22 Feb 2017 04:55:00 -0800 (PST) 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, 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 jRPuGDuseOaI; Wed, 22 Feb 2017 04:54:59 -0800 (PST) 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 1A0EB1296C5; Wed, 22 Feb 2017 04:54:59 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6A98F930; Wed, 22 Feb 2017 13:54:57 +0100 (CET) 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 C97ciyDsn8xP; Wed, 22 Feb 2017 13:54:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Feb 2017 13:54:57 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F0AE200CB; Wed, 22 Feb 2017 13:54:57 +0100 (CET) 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 AzgdOsdt0tOa; Wed, 22 Feb 2017 13:54:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2222D200C9; Wed, 22 Feb 2017 13:54:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9D1EB3E8379D; Wed, 22 Feb 2017 13:54:58 +0100 (CET) Date: Wed, 22 Feb 2017 13:54:57 +0100 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Message-ID: <20170222125457.GA45275@elstar.local> Mail-Followup-To: "Acee Lindem (acee)" , Lou Berger , Martin Bjorklund , "jefftant.ietf@gmail.com" , "rtg-dt-yang-arch@ietf.org" , "phil@juniper.net" , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "yang-doctors@ietf.org" , "rjs@rob.sh" , "yingzhen.qu@huawei.com" References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222121555.GD44810@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: Cc: "rtg-dt-yang-arch@ietf.org" , "phil@juniper.net" , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "rjs@rob.sh" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , Lou Berger , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 12:55:00 -0000 On Wed, Feb 22, 2017 at 12:30:46PM +0000, Acee Lindem (acee) wrote: > > > >I think we need a clear problem statement before discussing any > >solutions. Adding a new extension statement that none of the existing > >tools understands also comes with a cost. There is a difference > >between OC adding an extension for OC usage or the IETF adding an > >extension for general usage. > > But this is the case for any extension. I think it has to be a general > IETF extension so that it can be readily used by IETF modules including > routing types. > So someone has to write an I-D that motivates why an extension is needed and which defines the extension in some level of detail. And in this particular case, it is likely also desirable to include guidelines when to use which pattern syntax. /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 Feb 22 05:46:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7871298BF; Wed, 22 Feb 2017 05:46:53 -0800 (PST) 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 KCuP3UpMDl3L; Wed, 22 Feb 2017 05:46:52 -0800 (PST) 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 BDBA51298B9; Wed, 22 Feb 2017 05:46:51 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80] (unknown [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80]) by mail.nic.cz (Postfix) with ESMTPSA id 3F070600D0; Wed, 22 Feb 2017 14:46:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487771210; bh=4Ri59DFPJEtOunbgyI8CKJbLOrhnRVlvRVlGUEbFQXs=; h=From:Date:To; b=TKoUhRKgMW1gT5p8D6wSGL39ELdinhqS8kR2N7OJ9dP5SMj4Ey6hcscdFMlrbHD0u qLhZbRtclIP7T3jC7iHH7LmZoSI2sVG1CNjg7bWDQj7bd2iF1bLvabw0ZJ2pGKbtC1 tyE2rWolZTpQAJPOEI5pmqFIkffbTln6O42eZS5A= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170222.101217.1995562365191986711.mbj@tail-f.com> Date: Wed, 22 Feb 2017 14:46:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9CEF1CC9-E254-4D0F-AA2B-E61D7568B684@nic.cz> References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.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: Cc: RTG YANG Design Team , lberger@labn.net, Phil Shafer , Anees Shaikh , Xufeng Liu , Alia Atlas , acee@cisco.com, Benoit Claise , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:46:54 -0000 > On 22 Feb 2017, at 10:12, Martin Bjorklund wrote: >=20 > Jeff Tantsura wrote: >> Martin, >>=20 >> please see inline >>=20 >> Given your deep YANG expertise and contributions to both sides, I=E2=80= =99d >> really appreciate your advice. >>=20 >> Cheers, >> Jeff >>=20 >>=20 >> On 2/22/17, 00:25, "Martin Bjorklund" wrote: >>=20 >> Hi, >>=20 >> Jeff Tantsura wrote: >>> Lou, >>>=20 >>> Yes, absolutely! >>>=20 >>> Please note - my goal is NOT to create more formal documents/YANG >>> versions/etc =E2=80=93 it is to get to the point we could reduce = (eliminate >>> would be the grand goal) discrepancy between IETF and OpenConfig (by >>> now implemented by every vendor out there) models. >>=20 >> I just want to comment on this last point. It is simply not true. >> YANG is designed for and used in *lots* of other types of devices = than >> routers, many of which do not implement the OC models. >> [jeff] This discussion has started in context of OC using >> ietf-routing-types, which is a product of RTGWG and meant to be used >> in routing realm >=20 > Ok. >=20 >=20 >>> Having OC using >>> ietf-routing-types without sacrificing functionality would be a = great >>> starting point, tangible deliverable, achievable given both sides = are >>> willing to co-operate. >>=20 >> My question about what the problem is is still not answered. Is = the >> problem that the XSD regexp dialect is too primitive, or is it = that >> the open implementations that exist cannot be used? >> [jeff] Rob did shed some light, I=E2=80=99ll be working towards a = better >> problem definition, please give me some time >=20 > I didn't quite understand Rob's comment, so I look forward to a > problem definition. >=20 >>> I=E2=80=99ll be talking to some of you during this and next week. >>>=20 >>> I believe RTGWG should provide venue for the discussion, let me >>> discuss this with co-chair and AD >>=20 >> A clarifying question - what does "the discussion" refer to? Is = it >> about making sure ietf-routing-types can be used by others, or is = it >> about making changes to the YANG language? >> [jeff] obviously, RTGWG is not the right place to decide on any YANG >> changes, it is to discuss what is the problem and potential solution. >=20 > Ok. >=20 >> [jeff] /*routing context*/ the fact that part of the industry can=E2=80= =99t >> use what has been produced by IETF is a serious issue that needs to = be >> resolved, it doesn=E2=80=99t do any good to either implementers or >> users. Rather than keeping on duplicating the work, and calling each >> other names we should work together! >=20 > I don't think I have been calling anyone names. I always try hard to > keep the discussions at a technical level. >=20 > Going back to the issue on regexps, I (and probably others) have > proposed a way for OC to work around the problem - use an oc-specific > extension statement, so instead of doing: >=20 > type string { > pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } >=20 > one could do: >=20 > type string { > oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > } >=20 >=20 > This would avoid the fork of YANG that actually has happened now. Actually, such an extension is a fork of YANG as well. Constraints are = the substance of YANG and we should not change their semantics through = extensions. Lada =20 >=20 >=20 > /martin > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 22 05:54:23 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A5A12983F; Wed, 22 Feb 2017 05:54:12 -0800 (PST) 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 RjY6PkRYUM0S; Wed, 22 Feb 2017 05:54:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0872812988C; Wed, 22 Feb 2017 05:54:11 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 46AA51AE0187; Wed, 22 Feb 2017 14:54:09 +0100 (CET) Date: Wed, 22 Feb 2017 14:54:10 +0100 (CET) Message-Id: <20170222.145410.778622940212168378.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170222125457.GA45275@elstar.local> References: <20170222121555.GD44810@elstar.local> <20170222125457.GA45275@elstar.local> 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: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:54:12 -0000 Juergen Schoenwaelder wrote: > On Wed, Feb 22, 2017 at 12:30:46PM +0000, Acee Lindem (acee) wrote: > > > > > >I think we need a clear problem statement before discussing any > > >solutions. Adding a new extension statement that none of the existing > > >tools understands also comes with a cost. There is a difference > > >between OC adding an extension for OC usage or the IETF adding an > > >extension for general usage. > > > > But this is the case for any extension. I think it has to be a general > > IETF extension so that it can be readily used by IETF modules including > > routing types. > > > > So someone has to write an I-D that motivates why an extension is > needed and which defines the extension in some level of detail. And > in this particular case, it is likely also desirable to include > guidelines when to use which pattern syntax. But I hope we wait for the problem definition before providing a solution... /martin From nobody Wed Feb 22 05:54:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86881298BF; Wed, 22 Feb 2017 05:54:52 -0800 (PST) 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 5xw0vdTZv0fB; Wed, 22 Feb 2017 05:54:46 -0800 (PST) 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 27B2112988C; Wed, 22 Feb 2017 05:54:46 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80] (unknown [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80]) by mail.nic.cz (Postfix) with ESMTPSA id 9D8BE6012D; Wed, 22 Feb 2017 14:54:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487771684; bh=0stDX9m7Sn2ZdIMvuDRmcJQln1mppHp0y9qJ4zNpaOo=; h=From:Date:To; b=XFbW0FLYFjG7ptBBFNykZ8JWm0ciVur+QX0endKIFgj8+8XwRh+wBINL9gQZSWHu6 XsHCp6IwXiQv/6X6oHw4YFAnB1NyFtpqyNOFcoKNHPTEx9QH14JxqFCXJGQ2WTxzen u+tDoOGcE6YXz043hXLRQIfiFzIo2Rb7ep5eeZKM= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170222.133632.1310891825599234865.mbj@tail-f.com> Date: Wed, 22 Feb 2017 14:54:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <37595AF3-BEF0-4169-9992-64FE20AD1230@nic.cz> References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.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: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, Phil Shafer , aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, Benoit Claise , jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:54:52 -0000 > On 22 Feb 2017, at 13:36, Martin Bjorklund wrote: >=20 > Lou Berger wrote: >> See below. >>=20 >>=20 >> On February 22, 2017 4:12:54 AM Martin Bjorklund >> wrote: >=20 > [...] >=20 >>> Going back to the issue on regexps, I (and probably others) have >>> proposed a way for OC to work around the problem - use an = oc-specific >>> extension statement, so instead of doing: >>>=20 >>> type string { >>> pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >>> } >>>=20 >>> one could do: >>>=20 >>> type string { >>> oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >>> } >>>=20 >>>=20 >>> This would avoid the fork of YANG that actually has happened now. >>>=20 >>=20 >> This is a good approach if it works - it's certainly an order of >> magnitude or two simpler than bumping yang revs! >>=20 >> Is there any reason to *not* include it in routing types if it >> addresses the base comment? >=20 > I think there are two issues. The first is how OC can specify > patterns in their preferred regexp dialect in their own modules. My > proposal above is one way of doing that, in a way that is 100% YANG > compliant. [Side note: this is common practise; we have our own > extension statements that can be used to restrict certain types, and I > am pretty sure that yumapro and libyang etc all have similar > extensions.] This is a very slippery slope. If every vendor defines their own = extensions that change YANG semantics, we will end up with many YANG = dialects (silos) even though all will report the same YANG version. Lada >=20 > The other issue is how OC can utilize IETF modules with regexps > written in the standard dialect. IMO this is more an implementation > matter. The "pattern" statement formally defines a constraint on > the value space, but there is nothing that requires an implementation > to use the pattern exactly as it is specified. A toolchain that > doesn't understand the XSD regexp dialect can simply ignore the > pattern; or if it is clever and maybe doesn't really care about > unicode it can translate the pattern to another dialect automatically; > or if it is even more clever it can translate if possible or otherwise > use a user-provided regexp in another dialect. These are just > suggestions of course, I'm sure there are other ways of dealing with > this. >=20 > This said, I don't think it's a good idea to define an openconfig > specific extension in the ietf-routing-types document, and I also > don't think that the IETF should define a second way of defining > regexp patterns. Having two very similar ways of doing the same thing > often leads to more problems than it solves. >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 22 05:58:58 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85396129863; Wed, 22 Feb 2017 05:58:54 -0800 (PST) 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 pzkB2bgAvtgJ; Wed, 22 Feb 2017 05:58:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B92F612968F; Wed, 22 Feb 2017 05:58:52 -0800 (PST) Received: from localhost (unknown [173.38.220.40]) by mail.tail-f.com (Postfix) with ESMTPSA id 289E71AE0187; Wed, 22 Feb 2017 14:58:51 +0100 (CET) Date: Wed, 22 Feb 2017 14:58:52 +0100 (CET) Message-Id: <20170222.145852.880199244379432694.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <37595AF3-BEF0-4169-9992-64FE20AD1230@nic.cz> References: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <37595AF3-BEF0-4169-9992-64FE20AD1230@nic.cz> 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: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:58:54 -0000 Ladislav Lhotka wrote: > > > On 22 Feb 2017, at 13:36, Martin Bjorklund wrote: > > > > Lou Berger wrote: > >> See below. > >> > >> > >> On February 22, 2017 4:12:54 AM Martin Bjorklund > >> wrote: > > > > [...] > > > >>> Going back to the issue on regexps, I (and probably others) have > >>> proposed a way for OC to work around the problem - use an oc-specific > >>> extension statement, so instead of doing: > >>> > >>> type string { > >>> pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > >>> } > >>> > >>> one could do: > >>> > >>> type string { > >>> oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; > >>> } > >>> > >>> > >>> This would avoid the fork of YANG that actually has happened now. > >>> > >> > >> This is a good approach if it works - it's certainly an order of > >> magnitude or two simpler than bumping yang revs! > >> > >> Is there any reason to *not* include it in routing types if it > >> addresses the base comment? > > > > I think there are two issues. The first is how OC can specify > > patterns in their preferred regexp dialect in their own modules. My > > proposal above is one way of doing that, in a way that is 100% YANG > > compliant. [Side note: this is common practise; we have our own > > extension statements that can be used to restrict certain types, and I > > am pretty sure that yumapro and libyang etc all have similar > > extensions.] > > This is a very slippery slope. If every vendor defines their own > extensions that change YANG semantics, we will end up with many YANG > dialects (silos) even though all will report the same YANG version. They don't necessarily change YANG semantics. In this particular case it just provides a way to do exactly the same thing as 'pattern' already does. And any vendor can do whatever they want in their extensions. The result may or may not be generally useful, but that's up to the vendor. /martin > > Lada > > > > > The other issue is how OC can utilize IETF modules with regexps > > written in the standard dialect. IMO this is more an implementation > > matter. The "pattern" statement formally defines a constraint on > > the value space, but there is nothing that requires an implementation > > to use the pattern exactly as it is specified. A toolchain that > > doesn't understand the XSD regexp dialect can simply ignore the > > pattern; or if it is clever and maybe doesn't really care about > > unicode it can translate the pattern to another dialect automatically; > > or if it is even more clever it can translate if possible or otherwise > > use a user-provided regexp in another dialect. These are just > > suggestions of course, I'm sure there are other ways of dealing with > > this. > > > > This said, I don't think it's a good idea to define an openconfig > > specific extension in the ietf-routing-types document, and I also > > don't think that the IETF should define a second way of defining > > regexp patterns. Having two very similar ways of doing the same thing > > often leads to more problems than it solves. > > > > > > > > /martin > > > > _______________________________________________ > > yang-doctors mailing list > > yang-doctors@ietf.org > > https://www.ietf.org/mailman/listinfo/yang-doctors > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Feb 22 06:00:49 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8369F1298C4; Wed, 22 Feb 2017 06:00:48 -0800 (PST) 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 bPLxCRc9UESw; Wed, 22 Feb 2017 06:00:47 -0800 (PST) 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 F40631298CA; Wed, 22 Feb 2017 06:00:46 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80] (unknown [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80]) by mail.nic.cz (Postfix) with ESMTPSA id 8E6B260531; Wed, 22 Feb 2017 15:00:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487772045; bh=XO3NlQXRqmvxLVHqen/JUKG4FEZP4LJ2h2F99/TC+IM=; h=From:Date:To; b=cN0X7VYr68CWHUMofoCDt9gJP4dsV3LPBEMgGoY53ev2rUJAbXsjm/9qyiwfIOK5d SNfx1CaFR50Fac8MVb64NkBqNU6uEM1LvW8YYahMtuLozPxvFAN/SayHeYDzQz/zAO xLXDpqnAhEIfm8YQ2w2GUjgQlnaibfQdvtf9MNew= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170222.145410.778622940212168378.mbj@tail-f.com> Date: Wed, 22 Feb 2017 15:00:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D6426BF-8E24-4A6B-BFB4-EF2AD25247B5@nic.cz> References: <20170222121555.GD44810@elstar.local> <20170222125457.GA45275@elstar.local> <20170222.145410.778622940212168378.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: Cc: rtg-dt-yang-arch@ietf.org, lberger@labn.net, Phil Shafer , aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, Benoit Claise , jefftant.ietf@gmail.com, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:00:48 -0000 > On 22 Feb 2017, at 14:54, Martin Bjorklund wrote: >=20 > Juergen Schoenwaelder wrote: >> On Wed, Feb 22, 2017 at 12:30:46PM +0000, Acee Lindem (acee) wrote: >>>>=20 >>>> I think we need a clear problem statement before discussing any >>>> solutions. Adding a new extension statement that none of the = existing >>>> tools understands also comes with a cost. There is a difference >>>> between OC adding an extension for OC usage or the IETF adding an >>>> extension for general usage. >>>=20 >>> But this is the case for any extension. I think it has to be a = general >>> IETF extension so that it can be readily used by IETF modules = including >>> routing types.=20 >>>=20 >>=20 >> So someone has to write an I-D that motivates why an extension is >> needed and which defines the extension in some level of detail. And >> in this particular case, it is likely also desirable to include >> guidelines when to use which pattern syntax. >=20 > But I hope we wait for the problem definition before providing a > solution... Right. What I am still missing is an answer to your original question: = are XSD regexs not powerful enough, or is language/library support = insufficient? Lada >=20 >=20 > /martin >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 22 06:10:47 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F401298C0; Wed, 22 Feb 2017 06:10:42 -0800 (PST) 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 BMW2MTMDt4DT; Wed, 22 Feb 2017 06:10:40 -0800 (PST) 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 55B1012988C; Wed, 22 Feb 2017 06:10:39 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80] (unknown [IPv6:2001:718:1a02:1:786d:1c74:a89f:9a80]) by mail.nic.cz (Postfix) with ESMTPSA id 0317D6012D; Wed, 22 Feb 2017 15:10:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1487772638; bh=JKiOWXPo3+JFxlx3tQOSR66MBBQNjEkF/kdka4TE8HI=; h=From:Date:To; b=QcxnMnOJiKabqEVcGrCDGhD22MRBoCz3qkf8ys7qrxAxeNUHF7C/SnY+1a1S2c0ns 3npblthqE3C66WXUhjTxc6dgY9DVtfX6a5zcLa5rmQNxJbkSyZ4q+7M/SUniRA0pI9 PFPsXboILvB8Vc6GWc9dn01pdBFPtCSe6/5hqSBI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170222.145852.880199244379432694.mbj@tail-f.com> Date: Wed, 22 Feb 2017 15:10:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23C9AE20-E052-4643-8E95-781F8CE8745B@nic.cz> References: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <37595AF3-BEF0-4169-9992-64FE20AD1230@nic.cz> <20170222.145852.880199244379432694.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: Cc: rtg-dt-yang-arch@ietf.org, rjs@rob.sh, Phil Shafer , aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, Benoit Claise , jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 14:10:42 -0000 > On 22 Feb 2017, at 14:58, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 22 Feb 2017, at 13:36, Martin Bjorklund wrote: >>>=20 >>> Lou Berger wrote: >>>> See below. >>>>=20 >>>>=20 >>>> On February 22, 2017 4:12:54 AM Martin Bjorklund >>>> wrote: >>>=20 >>> [...] >>>=20 >>>>> Going back to the issue on regexps, I (and probably others) have >>>>> proposed a way for OC to work around the problem - use an = oc-specific >>>>> extension statement, so instead of doing: >>>>>=20 >>>>> type string { >>>>> pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >>>>> } >>>>>=20 >>>>> one could do: >>>>>=20 >>>>> type string { >>>>> oc:pattern '^[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}$'; >>>>> } >>>>>=20 >>>>>=20 >>>>> This would avoid the fork of YANG that actually has happened now. >>>>>=20 >>>>=20 >>>> This is a good approach if it works - it's certainly an order of >>>> magnitude or two simpler than bumping yang revs! >>>>=20 >>>> Is there any reason to *not* include it in routing types if it >>>> addresses the base comment? >>>=20 >>> I think there are two issues. The first is how OC can specify >>> patterns in their preferred regexp dialect in their own modules. My >>> proposal above is one way of doing that, in a way that is 100% YANG >>> compliant. [Side note: this is common practise; we have our own >>> extension statements that can be used to restrict certain types, and = I >>> am pretty sure that yumapro and libyang etc all have similar >>> extensions.] >>=20 >> This is a very slippery slope. If every vendor defines their own >> extensions that change YANG semantics, we will end up with many YANG >> dialects (silos) even though all will report the same YANG version. >=20 > They don't necessarily change YANG semantics. In this particular case > it just provides a way to do exactly the same thing as 'pattern' > already does. And any vendor can do whatever they want in their > extensions. The result may or may not be generally useful, but that's > up to the vendor. >=20 If two YANG validators end up with with different results regarding = validity of the same document, then something appears to be broken. = What's then the value of YANG as a standard? Lada >=20 > /martin >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> The other issue is how OC can utilize IETF modules with regexps >>> written in the standard dialect. IMO this is more an implementation >>> matter. The "pattern" statement formally defines a constraint on >>> the value space, but there is nothing that requires an = implementation >>> to use the pattern exactly as it is specified. A toolchain that >>> doesn't understand the XSD regexp dialect can simply ignore the >>> pattern; or if it is clever and maybe doesn't really care about >>> unicode it can translate the pattern to another dialect = automatically; >>> or if it is even more clever it can translate if possible or = otherwise >>> use a user-provided regexp in another dialect. These are just >>> suggestions of course, I'm sure there are other ways of dealing with >>> this. >>>=20 >>> This said, I don't think it's a good idea to define an openconfig >>> specific extension in the ietf-routing-types document, and I also >>> don't think that the IETF should define a second way of defining >>> regexp patterns. Having two very similar ways of doing the same = thing >>> often leads to more problems than it solves. >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 22 09:08:43 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C9129A78; Wed, 22 Feb 2017 09:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.789 X-Spam-Level: X-Spam-Status: No, score=-3.789 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=-1.887, 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 F0Cjznqtdxlz; Wed, 22 Feb 2017 09:08:38 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C4C129A76; Wed, 22 Feb 2017 09:08:37 -0800 (PST) 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=4x6ZguodndRxBUkQjZ/1dNnBNeXxwZ5vRTe1z93BIUQ=; b=hJafwuLn2Cq3jpSE6aAS+veBklzKSzCO8T5niZJesAZFkJ6UpgJscqTJGMmZLOHenh/PAyB2/QDJPgszN+6wIsq9dC6Wc8xV+2YOf9/mh2zKaai/6gIcOV+eK8BxMAdmHjDevf1seZix2vsIE5NluuH/pNfhb8RVdyie/rTeS18= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1217.namprd05.prod.outlook.com (10.160.113.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 17:08: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.0919.018; Wed, 22 Feb 2017 17:08:36 +0000 From: Kent Watsen To: Martin Bjorklund , "lberger@labn.net" Thread-Topic: [Rtg-dt-yang-arch] [yang-doctors] Open Config on ietf-routing-types Thread-Index: AQHSjQOEKaRJ03OB6Eaug6rVYP2mGKF09pAA///4MAA= Date: Wed, 22 Feb 2017 17:08:36 +0000 Message-ID: <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> In-Reply-To: <20170222.133632.1310891825599234865.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170216 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-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: a9bfc394-19f4-41ef-c5f7-08d45b457056 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1217; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1217; 7:pYtjsX/mPwYeS59Kntr3rGnxpPWC5iewXteOz4KdMdJ/uWcq3vykhdE307Uc8mU2y04L60xL6DPpEHg11We2u+IbOcsuGWeBMUwj0mm2eU89pa6X0vhSUET42tPORKa1n7VFr7c94Y5KcjyRRB5ZVl13cAqiHD68EoyfOCamq1SrSBJHe+VsLPCPIpO0v+Hgm5dFiN9yX3Es77NRgcNRPTVVvG1rlfVdU25F+ty8pEBxE8O8z+LiRCiSl5cAk0qaWFG1xwhItIlN5dH9VfsxC2ehuIi3oUODnB/Iz1KnTH/uqyogBmxmAQUFU9yJL/eNrBfa3G9IEdcl6ZfAkDxlkw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN3PR0501MB1217; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1217; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(4326007)(39060400002)(33656002)(230783001)(66066001)(82746002)(86362001)(83506001)(2501003)(36756003)(2900100001)(38730400002)(8676002)(3280700002)(6246003)(3660700001)(53936002)(8936002)(76176999)(81166006)(93886004)(83716003)(2906002)(54356999)(50986999)(122556002)(229853002)(4001350100001)(6486002)(77096006)(2950100002)(92566002)(189998001)(6506006)(54906002)(99286003)(305945005)(7736002)(6512007)(7416002)(6436002)(106116001)(6116002)(3846002)(5660300001)(102836003)(25786008)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1217; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; 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: 22 Feb 2017 17:08:36.0177 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1217 Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "acee@cisco.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "rjs@rob.sh" , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:08:39 -0000 DQoNCj4gVGhlIG90aGVyIGlzc3VlIGlzIGhvdyBPQyBjYW4gdXRpbGl6ZSBJRVRGIG1vZHVsZXMg d2l0aCByZWdleHBzDQo+IHdyaXR0ZW4gaW4gdGhlIHN0YW5kYXJkIGRpYWxlY3QuICBJTU8gdGhp cyBpcyBtb3JlIGFuIGltcGxlbWVudGF0aW9uDQo+IG1hdHRlci4gIFRoZSAicGF0dGVybiIgc3Rh dGVtZW50IGZvcm1hbGx5IGRlZmluZXMgYSBjb25zdHJhaW50IG9uDQo+IHRoZSB2YWx1ZSBzcGFj ZSwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgdGhhdCByZXF1aXJlcyBhbiBpbXBsZW1lbnRhdGlvbg0K PiB0byB1c2UgdGhlIHBhdHRlcm4gZXhhY3RseSBhcyBpdCBpcyBzcGVjaWZpZWQuICBBIHRvb2xj aGFpbiB0aGF0DQo+IGRvZXNuJ3QgdW5kZXJzdGFuZCB0aGUgWFNEIHJlZ2V4cCBkaWFsZWN0IGNh biBzaW1wbHkgaWdub3JlIHRoZQ0KPiBwYXR0ZXJuOyBvciBpZiBpdCBpcyBjbGV2ZXIgYW5kIG1h eWJlIGRvZXNuJ3QgcmVhbGx5IGNhcmUgYWJvdXQNCj4gdW5pY29kZSBpdCBjYW4gdHJhbnNsYXRl IHRoZSBwYXR0ZXJuIHRvIGFub3RoZXIgZGlhbGVjdCBhdXRvbWF0aWNhbGx5Ow0KPiBvciBpZiBp dCBpcyBldmVuIG1vcmUgY2xldmVyIGl0IGNhbiB0cmFuc2xhdGUgaWYgcG9zc2libGUgb3Igb3Ro ZXJ3aXNlDQo+IHVzZSBhIHVzZXItcHJvdmlkZWQgcmVnZXhwIGluIGFub3RoZXIgZGlhbGVjdC4g IFRoZXNlIGFyZSBqdXN0DQo+IHN1Z2dlc3Rpb25zIG9mIGNvdXJzZSwgSSdtIHN1cmUgdGhlcmUg YXJlIG90aGVyIHdheXMgb2YgZGVhbGluZyB3aXRoDQo+IHRoaXMuDQoNClJpZ2h0LCBhIHNlcnZl ciBkb2Vzbid0IGhhdmUgdG8gY29tcGlsZS9leGVjdXRlIHRoZSBYU0QgJ3BhdHRlcm4nIA0KZXhw cmVzc2lvbiBhdCBhbGwsIHNvIGxvbmcgYXMgaXQgY2FuIGltcGxlbWVudCB0aGUgdmFsaWRhdGlv biBydWxlcw0KYnkgb3RoZXIgbWVhbnMsIHBlcmhhcHMgYnkgdHJhbnNsYXRpbmcgdGhlIFhTRCBw YXR0ZXJuIHRvIGFub3RoZXINCmRpYWxlY3Qgb3IgYnkganVzdCB1c2luZyAnQycgY29kZS4gIElm IHRoZSBzZXJ2ZXIncyBpbXBsZW1lbnRhdGlvbg0Kb2YgYSBwYXR0ZXJuIGlzIG5vdCBhIDEwMCUg YWNjdXJhdGUsIHRoZW4gY3VzdG9tZXJzIHdpbGwgcmVwb3J0IHRoZQ0KaXNzdWUgYW5kIHRoZSBz ZXJ2ZXIgd2lsbCBiZSBpbXByb3ZlZC4NCg0KQXMgZm9yIFVuaWNvZGUgc3VwcG9ydCwgc29tZSBz ZXJ2ZXJzIGRvbid0IGV2ZW4gc3VwcG9ydCBVbmljb2RlLCBzbw0KdHJhbnNsYXRpbmcgdGhlIFhT RCBwYXR0ZXJuIHRvIGFub3RoZXIgcmVnZXggdGhhdCBkb2Vzbid0IHN1cHBvcnQNClVuaWNvZGUg d291bGQgYmUgYSBub24taXNzdWUgZm9yIHRoZXNlIHN5c3RlbXMuICBQZXJoYXBzIGEgZ2VuZXJp Yw0KWFNELXJlZ2V4IHRvIFBPU0lYLXJlZ2V4IGNvbnZlcnRvciBjb3VsZCBiZSB1c2VkIGJ5IHN1 Y2ggc3lzdGVtcy4NClNlYXJjaGluZyBvbmxpbmUsIEkgZG9uJ3QgZmluZCBhbnkgc3VjaCBjb252 ZXJ0b3IgYXZhaWxhYmxlIChidXQgSQ0KZGlkbid0IGxvb2sgdmVyeSBoYXJkKS4gIFBlcmhhcHMg dGhpcyB3b3VsZCBtYWtlIGZvciBiZSBhIGdvb2QgDQpIYWNrYXRob24gcHJvamVjdD8gOykNCg0K S2VudCAvLyBhcyBhIGNvbnRyaWJ1dG9yDQoNCg0KDQoNCg== From nobody Wed Feb 22 10:34:51 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBEB1296B6 for ; Wed, 22 Feb 2017 10:34:46 -0800 (PST) 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 TtWGsa4zHUDX for ; Wed, 22 Feb 2017 10:34:46 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 3A33D12967C for ; Wed, 22 Feb 2017 10:34:44 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id d9so41141666itc.0 for ; Wed, 22 Feb 2017 10:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uWJg7T7SM5OWWVf/EpCqvbP7MpFAg8GmZA01p4OBaTI=; b=vmPVMz4MAPKYUsudmLBR6rArjK0w5xP3jXu5aYs5twaEsnFW4SyIhbSXvPSaQMa4Wt m7NrDI6zwInID/81D8BzfztnbJxLB42x8bvTOvC5cxDwApcA9DJfnRlkZQurNtn0hhav rO+K0/9faiHZdVFDjl+msv5Uo3zhePM6SvOXNBVrJQniNkI8Imqto7tkRheA8eYXXnRT ZMJYfX8t+d3eIaQarzk2wZ3k6Q32Te/h7Ia5gk1n4bdXSsDz/4xbchF3p+vhd53RiBkr UER8z8EIfmntk0Sevu+EPOCSnwQiq/WlGblJfzN7EV/+t0TR3C4GGLndYiVYjJ6B5s3g 5/lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uWJg7T7SM5OWWVf/EpCqvbP7MpFAg8GmZA01p4OBaTI=; b=oFxxyhoLfJeRALKh0/24HIOnD3rH7K+IdvZQHvO7PgMrXsVGqItW9aiuVUJVHXCHkb pkglyNx7mi0MH+LjOctOC8+RBr6zSdMYRYAaxVPh9EuPb5Y+kV0QYt1OZX34uTU9FTZK lCGfsNkq2yOUrBJ5BCtO2Gj+iP84KPm/DCqL/orLFiR19d0e8vkPOWPoodtiB1MyvBLx HhhcDnF+5DC/NHeJh5XM3Xt2ebN89WWA0K1gkYo6A3nAmfdKr8SA7aW7WkfyVeea7mWJ 3jlrbgjXJxPvfMlncOglCdhdqi5ZhiOWIt/n9Sf5NUN3R8VnegJs0pYZYZfeH6SwbMB1 MHWA== X-Gm-Message-State: AMke39nDkaH0ykGVWB6nyL8NoVxxZBFY1WqgfcjuyK52tX6C+BP8+O8eDpV5GUEIEI1TtBcMLq5mtVQJONHt/Q== X-Received: by 10.107.172.7 with SMTP id v7mr28724861ioe.49.1487788483388; Wed, 22 Feb 2017 10:34:43 -0800 (PST) MIME-Version: 1.0 References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> In-Reply-To: <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> From: Rob Shakir Date: Wed, 22 Feb 2017 18:34:32 +0000 Message-ID: To: Kent Watsen , Martin Bjorklund , "lberger@labn.net" Content-Type: multipart/alternative; boundary=94eb2c05a3800de416054922c080 Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "acee@cisco.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:34:47 -0000 --94eb2c05a3800de416054922c080 Content-Type: text/plain; charset=UTF-8 Note, my mail didn't ask for anything to be changed. It just noted that there are implementation complexities of having an XSD regexp dialect that is not widely supported in non-XML libraries. This is an implementation barrier for servers that want to use YANG to model their schema. Kent is right, translation is an approach - but transcoding regexps is something that adds more code to maintain for those building systems that use these data models. I know, from comments made elsewhere, that this isn't just something that is an OpenConfig issue - and I'm fine if NETMOD/IETF doesn't want to work on a solution. Merely, as someone that has spent a couple of years writing actually writing models, and implementing tooling around YANG that's used to run networks - I provided feedback as to what the issue was for the systems that we're considering. r. On Wed, 22 Feb 2017 at 09:08 Kent Watsen wrote: > > > > The other issue is how OC can utilize IETF modules with regexps > > written in the standard dialect. IMO this is more an implementation > > matter. The "pattern" statement formally defines a constraint on > > the value space, but there is nothing that requires an implementation > > to use the pattern exactly as it is specified. A toolchain that > > doesn't understand the XSD regexp dialect can simply ignore the > > pattern; or if it is clever and maybe doesn't really care about > > unicode it can translate the pattern to another dialect automatically; > > or if it is even more clever it can translate if possible or otherwise > > use a user-provided regexp in another dialect. These are just > > suggestions of course, I'm sure there are other ways of dealing with > > this. > > Right, a server doesn't have to compile/execute the XSD 'pattern' > expression at all, so long as it can implement the validation rules > by other means, perhaps by translating the XSD pattern to another > dialect or by just using 'C' code. If the server's implementation > of a pattern is not a 100% accurate, then customers will report the > issue and the server will be improved. > > As for Unicode support, some servers don't even support Unicode, so > translating the XSD pattern to another regex that doesn't support > Unicode would be a non-issue for these systems. Perhaps a generic > XSD-regex to POSIX-regex convertor could be used by such systems. > Searching online, I don't find any such convertor available (but I > didn't look very hard). Perhaps this would make for be a good > Hackathon project? ;) > > Kent // as a contributor > > > > > --94eb2c05a3800de416054922c080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note, my mail didn't ask for anything to be changed. I= t just noted that there are implementation complexities of having an XSD re= gexp dialect that is not widely supported in non-XML libraries. This is an = implementation barrier for servers that want to use YANG to model their sch= ema. Kent is right, translation is an approach - but transcoding regexps is= something that adds more code to maintain for those building systems that = use these data models.

I know, from comments made elsewh= ere, that this isn't just something that is an OpenConfig issue - and I= 'm fine if NETMOD/IETF doesn't want to work on a solution. Merely, = as someone that has spent a couple of years writing actually writing models= , and implementing tooling around YANG that's used to run networks - I = provided feedback as to what the issue was for the systems that we're c= onsidering.

r.

On Wed, 22 Feb 2017 at 09:08 Kent Watsen <kwatsen@juniper.net> wrote:


> The other issue is how OC can utilize IETF modules with regexps
> written in the standard dialect.=C2=A0 IMO this is more an implementat= ion
> matter.=C2=A0 The "pattern" statement formally defines a con= straint on
> the value space, but there is nothing that requires an implementation<= br class=3D"gmail_msg"> > to use the pattern exactly as it is specified.=C2=A0 A toolchain that<= br class=3D"gmail_msg"> > doesn't understand the XSD regexp dialect can simply ignore the > pattern; or if it is clever and maybe doesn't really care about > unicode it can translate the pattern to another dialect automatically;=
> or if it is even more clever it can translate if possible or otherwise=
> use a user-provided regexp in another dialect.=C2=A0 These are just > suggestions of course, I'm sure there are other ways of dealing wi= th
> this.

Right, a server doesn't have to compile/execute the XSD 'pattern= 9;
expression at all, so long as it can implement the validation rules
by other means, perhaps by translating the XSD pattern to another
dialect or by just using 'C' code.=C2=A0 If the server's implem= entation
of a pattern is not a 100% accurate, then customers will report the
issue and the server will be improved.

As for Unicode support, some servers don't even support Unicode, so
translating the XSD pattern to another regex that doesn't support
Unicode would be a non-issue for these systems.=C2=A0 Perhaps a generic
XSD-regex to POSIX-regex convertor could be used by such systems.
Searching online, I don't find any such convertor available (but I
didn't look very hard).=C2=A0 Perhaps this would make for be a good
Hackathon project? ;)

Kent // as a contributor




--94eb2c05a3800de416054922c080-- From nobody Wed Feb 22 10:43:57 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AB1296B4; Wed, 22 Feb 2017 10:43:56 -0800 (PST) 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 rlGB0Ym5a8cG; Wed, 22 Feb 2017 10:43:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 647FD12967C; Wed, 22 Feb 2017 10:43:55 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 62D191AE0187; Wed, 22 Feb 2017 19:43:53 +0100 (CET) Date: Wed, 22 Feb 2017 19:43:49 +0100 (CET) Message-Id: <20170222.194349.709735877588963434.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: References: <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@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: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:43:56 -0000 Hi, Rob Shakir wrote: > Note, my mail didn't ask for anything to be changed. It just noted that > there are implementation complexities of having an XSD regexp dialect that > is not widely supported in non-XML libraries. This is an implementation > barrier for servers that want to use YANG to model their schema. For my understanding, did you consider libxml2? I would like to understand what "implementation barrier" and "implementation complexity" really means. /martin From nobody Wed Feb 22 10:45:11 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1440129982; Wed, 22 Feb 2017 10:45:06 -0800 (PST) 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, 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 pby1OxrnTYXE; Wed, 22 Feb 2017 10:45:05 -0800 (PST) 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 BC50612997D; Wed, 22 Feb 2017 10:45:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1C496762; Wed, 22 Feb 2017 19:45:03 +0100 (CET) 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 Er5e3yzAZfWV; Wed, 22 Feb 2017 19:44:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 22 Feb 2017 19:45:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A88EF200CE; Wed, 22 Feb 2017 19:45:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rt5V0VH59Bsk; Wed, 22 Feb 2017 19:45:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B28CE200C9; Wed, 22 Feb 2017 19:45:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 36D183E8440E; Wed, 22 Feb 2017 19:45:03 +0100 (CET) Date: Wed, 22 Feb 2017 19:45:02 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170222184502.GA46638@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "lberger@labn.net" , "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "acee@cisco.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "rjs@rob.sh" , "yingzhen.qu@huawei.com" References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "yingzhen.qu@huawei.com" , "akatlas@gmail.com" , "rjs@rob.sh" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "lberger@labn.net" , "acee@cisco.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:45:07 -0000 On Wed, Feb 22, 2017 at 05:08:36PM +0000, Kent Watsen wrote: > > As for Unicode support, some servers don't even support Unicode, so > translating the XSD pattern to another regex that doesn't support > Unicode would be a non-issue for these systems. I think strictly speaking, a server not supporting Unicode is not compliant. So why care about how a non-compliant server deals with the fact of not being compliant? I understand that for global operators Unicode may not be important since they use English as their lingua france (love this expression). But the technology is not just for big global operators. /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 Feb 22 10:49:58 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D176B1295DB for ; Wed, 22 Feb 2017 10:49:54 -0800 (PST) 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] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 0sz-LAJSiUa1 for ; Wed, 22 Feb 2017 10:49:52 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 5849812967C for ; Wed, 22 Feb 2017 10:49:52 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id 203so8772733ith.0 for ; Wed, 22 Feb 2017 10:49:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zTDiC3mIVy8whp0eJ0K9Kzh8Gq9oT8zAjwvf/DbK600=; b=W0TpiaaInhouZGAvz8Qb7d7QFeYr1cqnU1s+ueVuLHctco0rBosI+IfdcUuKNtxPE6 wb8nAfMTfdrtlOP1tS9bWfGsLi2M495AgEEm1DY/Znhe7q9x5dBQHe1d0uWLKcCIe+f8 avw1dT1CwOBZFJGo7I/PcofYLZ+xIJw9XUnb7abmsvrWpfIMksyGUS/HPLhvivuFXbn7 2DxyDeZy7t1mpTEhORLfsV0sUjCGrHSttkm82aGGyOupQfYQI5EVkswjHpFtXQZLVD+x R6V0AXCrSxGnRZY8FAq+4LlloxXTwYRZDAkvnPcw/d9gaxF++kObpGVeK61hTgyfYuWd bF2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zTDiC3mIVy8whp0eJ0K9Kzh8Gq9oT8zAjwvf/DbK600=; b=rfFTU0JYcu4WGrmfgvXevero/ODO0nq0hUZ5Ois4XcnAQaw4Ecfq76vToqG8BvODaU hnmXhQQWYiLdTat8dt7wVSbwz+Y0OrM5Gi/uJE5Q1w+3f4U9xjSjELvBQsyOvOirOU8f p/pF4kjOmejuQnK+9yQ+pV5D0AXV+01fcWlybFpAnXYHYvlCGBnHml2BLkw6gEkpjypL 3VfPHrp88sDW/oBKhrw5+JkWhbOfJuLgKkVJG1X51JMYo2s9O4qwbevUSiQ6E0BfANrn yRuNLQ4g7nssoaVcRHemNREuXLgmHHtqwMd4smvjLrP3VrLuBwMsNR8QEHEN68TMrH5x olpw== X-Gm-Message-State: AMke39l78Cv0eCoI5v3jerCIyY278fy5yZrQZK7/ix5ZcC/iqmN0N3drcJD+TSDDleUOSx63OgeVRWkfiIHMYA== X-Received: by 10.36.67.210 with SMTP id s201mr3518122itb.28.1487789391313; Wed, 22 Feb 2017 10:49:51 -0800 (PST) MIME-Version: 1.0 References: <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> <20170222.194349.709735877588963434.mbj@tail-f.com> In-Reply-To: <20170222.194349.709735877588963434.mbj@tail-f.com> From: Rob Shakir Date: Wed, 22 Feb 2017 18:49:40 +0000 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113fac782baca4054922f678 Archived-At: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:49:55 -0000 --001a113fac782baca4054922f678 Content-Type: text/plain; charset=UTF-8 On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund wrote: > > For my understanding, did you consider libxml2? I would like to > understand what "implementation barrier" and "implementation > complexity" really means. > Pyangbind uses lxml for some elements of its functionality - particularly to support a lightweight XML backend for XPATH querying. It doesn't use libxml2 for regexps. When I looked originally, I didn't find useful language bindings to libxml2 in Python. In other projects, we don't have any XML library dependencies, adding libxml2 as a dependency seems overkill simply to parse regexs when there are built in libraries in many languages without libxml2. r. --001a113fac782baca4054922f678 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , 22 Feb 2017 at 10:43 Martin Bjorklund <mbj@tail-f.com> wrote:
For my understanding, did you consider libxml2?=C2=A0 I would like to
understand what "implementation barrier" and "implementation=
complexity" really means.
Pyangbind uses lxml for some elements of its functionality - pa= rticularly to support a lightweight XML backend for XPATH querying. It does= n't use libxml2 for regexps. When I looked originally, I didn't fin= d useful language bindings to libxml2 in Python.

I= n other projects, we don't have any XML library dependencies, adding li= bxml2 as a dependency seems overkill simply to parse regexs when there are = built in libraries in many languages without libxml2.

<= div>r.=C2=A0
--001a113fac782baca4054922f678-- From nobody Wed Feb 22 10:52:46 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A891299E9 for ; Wed, 22 Feb 2017 10:52:43 -0800 (PST) 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 LfKM8XpHLERh for ; Wed, 22 Feb 2017 10:52:42 -0800 (PST) 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 DF33B1298B9 for ; Wed, 22 Feb 2017 10:52:41 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id v186so149245145wmd.0 for ; Wed, 22 Feb 2017 10:52:41 -0800 (PST) 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=/qC1zPhspMI4r/zHJyIe05jEfu+Yg+zc38JsiCsCgDU=; b=FQ82+9Kh6/AuyDD/eXcTK7dvy2O3Ynt351rFBbXctq4kbgLJzynvpv1NWrqTIcREA9 sdP6RDKlO+lBe4Lyk/P2+bEHJ3XDabVIXgFGEs2B4mZZmNO4S9tox6IeiOhtB0GH8SXb pzx3WFe3ayl+n8DyarQEh7OKqD8W05geBjjRajVrNHJrCeB0f+61nG3YwS0A5UjUviyx xDfgYdjqMWjAomDKaUMDlEmuq6zEtUtq8F0IDPZCPRzxiXTZp+pGT7NbbVDgpVAd7Zxr cv6rAKH5+v7j1YCZanbQcoNjE2jaWorfrG8zZacHcODmy+9aFRXWVEltNDqPPSBG3ehL uRyw== 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=/qC1zPhspMI4r/zHJyIe05jEfu+Yg+zc38JsiCsCgDU=; b=MhYsn+aS/UYuNn56xQYBE5xJSBQEpYZzD6YHH6/5LVyWt0qK09be8nGYkgc8FpAwkT w0MhJVKTBQr3FlZJc8VIeyIptVDkuavcXqnXhoU6pGtQnSAKvu14WVU1Eq5fjzEksrBN h8k+gO1ecojiqBvkuAZnOrCj1F623ByBsqScbJdqEkAugsk4shO8QxqgYc2cq/eiD0oX ljRTeMtikgtLa4OI89u5aSB8/o/P6UhL2/WVOr3r6hxn/ZQODIWZ0lrsZecsaR1BrZcV RwREWen1JUDbiXSOvczfkJl88wvcL/Gine6QakzGfUBLGd7CbXt0LT29cEiw2LxFd/4x 68Ag== X-Gm-Message-State: AMke39kux7NSKIDEczpch4U0XS0n0PpmU8O5wn3OtL/xlKGY3R2e3VDuL1gIH9Gjvx59KihBKxtxXNp3lu8Gpw== X-Received: by 10.28.109.27 with SMTP id i27mr3621835wmc.54.1487789560378; Wed, 22 Feb 2017 10:52:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Wed, 22 Feb 2017 10:52:39 -0800 (PST) In-Reply-To: <20170222.194349.709735877588963434.mbj@tail-f.com> References: <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> <20170222.194349.709735877588963434.mbj@tail-f.com> From: Andy Bierman Date: Wed, 22 Feb 2017 10:52:39 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11478e803f92d205492300f1 Archived-At: Cc: Routing Area YANG Architecture DT , Berger Lou , Phil Shafer , Anees Shaikh , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:52:44 -0000 --001a11478e803f92d205492300f1 Content-Type: text/plain; charset=UTF-8 Hi, Rob's last comment is actually quite important because SMIv2 veered off from the mainstream and it really diminished the available tools for SNMP. We should avoid the same fate for YANG. Has the mainstream moved away from the XSD regexp and towards Posix regexp? And by Posix regexp, do you mean sec. 9 of this spec: http://pubs.opengroup.org/onlinepubs/9699919799/ (This is a really heavyweight regexp in its entirety) YANG automation tools would be diminished if the standard pattern-stmt was ignored and an extension was used instead. This is my main concern with an extension. Andy On Wed, Feb 22, 2017 at 10:43 AM, Martin Bjorklund wrote: > Hi, > > Rob Shakir wrote: > > Note, my mail didn't ask for anything to be changed. It just noted that > > there are implementation complexities of having an XSD regexp dialect > that > > is not widely supported in non-XML libraries. This is an implementation > > barrier for servers that want to use YANG to model their schema. > > For my understanding, did you consider libxml2? I would like to > understand what "implementation barrier" and "implementation > complexity" really means. > > > /martin > --001a11478e803f92d205492300f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Rob's last comment is actually = quite important because SMIv2 veered off from
the mainstream and = it really diminished the available tools for SNMP.
We should avoi= d the same fate for YANG.

Has the mainstream moved= away from the XSD regexp and towards Posix regexp?
And by Posix = regexp, do you mean sec. 9 of this spec:
(This is a really heavyweight regexp in its en= tirety)

YANG automation tools would be diminished = if the standard pattern-stmt
was ignored and an extension was use= d instead. This is my main concern
with an extension.
<= br>

Andy


=

On Wed, Feb 22, 2= 017 at 10:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Rob Shakir <rjs@rob.sh> wrote:
> Note, my mail didn't ask for anything to be changed. It just noted= that
> there are implementation complexities of having an XSD regexp dialect = that
> is not widely supported in non-XML libraries. This is an implementatio= n
> barrier for servers that want to use YANG to model their schema.

For my understanding, did you consider libxml2?=C2=A0 I would like to
understand what "implementation barrier" and "implementation=
complexity" really means.


/martin

--001a11478e803f92d205492300f1-- From nobody Wed Feb 22 10:54:54 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5EA41299ED for ; Wed, 22 Feb 2017 10:54:52 -0800 (PST) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 1HqPP-JUv5Y9 for ; Wed, 22 Feb 2017 10:54:51 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 0F0D1129A08 for ; Wed, 22 Feb 2017 10:54:51 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id 203so8944212ith.0 for ; Wed, 22 Feb 2017 10:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KWmOGNHrgsCO71tAeRCfovIAqCupwS363IO7jF9rhG4=; b=QbCIyE5Ps0yoffNH0AtEMBKcFeEP4f0w7rG8ooK1gZFeEbQ5zh3lus3VEEWnD0MQsr h37eKTkDr77ICe/zlnY5FA40fgIrdPdmL8j+0t3Z3Hg2GQc3mFFoR0DCBWlG/QOjINhx jKHp20EldrUw6kA4yH98Tau5+lYEaFd/rRKc3T0/bxEGruhNAh4lS8X8MDc8fs4daHWs Rlp4aWwnENgHfBFW6OCJAx2hjmTRoqf0wR8ecNSGk19Vvn8FrohOivvBOJx618XZ8kqU 55+JRJ9rYdpEQ5v67Nvlq3AWqZDOGalMmbj3E7y60zjojKFs0PHwhomCP6Uz7Otzj/gi jZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KWmOGNHrgsCO71tAeRCfovIAqCupwS363IO7jF9rhG4=; b=tB24dUDxXeZ6lt/ro/7aD9Ka/ZLfnGEvTBqnLPGXAfprcNN/AeRa4GXi5N/abFJ5PG FrzSoVkx1sFuNwplbqBgOiQbuztp088nqKi9Gm1lr80DdDHzTbc6/6LoRpVuLWmkbbqc VwKyHVWwVfLYZeClsSCgkvfJhyOtgCjRC9nmkKYlG2BLJHWb744NPCAdmEvpnq1H1Rm2 RTEQXPUfCN/d269R+zp57PMB52SgOpXngRPZy93qTj9D8beVMMwGlp6s5E4mXaHWXbHt 3dkUwyEtYqCWSWAMaG1dmjWiLcPXXOR0n6bQxH23oj7LhHl02RCD/kp1TtZ9NE+6dhty 9Mdw== X-Gm-Message-State: AMke39n7wCDPGMslLmjs3qauVuuFW72Ljf2oDeZqbnSXxsTwx2fYzwI7lmR5UHG3jqxG2+2my+zJFKdY1wKmfQ== X-Received: by 10.36.152.196 with SMTP id n187mr3579906itd.28.1487789690221; Wed, 22 Feb 2017 10:54:50 -0800 (PST) MIME-Version: 1.0 References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> <20170222184502.GA46638@elstar.local> In-Reply-To: <20170222184502.GA46638@elstar.local> From: Rob Shakir Date: Wed, 22 Feb 2017 18:54:39 +0000 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , Martin Bjorklund , "lberger@labn.net" , "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "acee@cisco.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "yingzhen.qu@huawei.com" Content-Type: multipart/alternative; boundary=94eb2c05e9a2fc8b480549230709 Archived-At: Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:54:53 -0000 --94eb2c05e9a2fc8b480549230709 Content-Type: text/plain; charset=UTF-8 I suspect, based on this position, that this discussion will diverge. I suspect the community of interest is some implementation community, rather than a standards one. Taking the academic case that servers that don't support unicode shouldn't be cared about, when there are many, real world, systems that fall into this category is nice, but doesn't help operators move forward. Given the oft-cited motivation for YANG/NETCONF is a 10+ year old study of operators, yet again, one feels that the IETF isn't able to effectively interact with those for whom standards are more a means to an end, than the end itself. It's not about big operators (I've worked for smaller ones than my current position), and I was under the impression that we were not wearing hats within the IETF. If this isn't the case - that's fine, but I'll reserve my right to not contribute to the discussion. r. On Wed, 22 Feb 2017 at 10:45 Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Feb 22, 2017 at 05:08:36PM +0000, Kent Watsen wrote: > > > > As for Unicode support, some servers don't even support Unicode, so > > translating the XSD pattern to another regex that doesn't support > > Unicode would be a non-issue for these systems. > > I think strictly speaking, a server not supporting Unicode is not > compliant. So why care about how a non-compliant server deals with the > fact of not being compliant? I understand that for global operators > Unicode may not be important since they use English as their lingua > france (love this expression). But the technology is not just for big > global operators. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 <+49%20421%202003587> Campus Ring 1 | > 28759 Bremen | Germany > Fax: +49 421 200 3103 <+49%20421%202003103> < > http://www.jacobs-university.de/> > --94eb2c05e9a2fc8b480549230709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I suspect, based on this position, that this discussion wi= ll diverge. I suspect the community of interest is some implementation comm= unity, rather than a standards one. Taking the academic case that servers t= hat don't support unicode shouldn't be cared about, when there are = many, real world, systems that fall into this category is nice, but doesn&#= 39;t help operators move forward.

Given the oft-cited mo= tivation for YANG/NETCONF is a 10+ year old study of operators, yet again, = one feels that the IETF isn't able to effectively interact with those f= or whom standards are more a means to an end, than the end itself.

It's not about big operators (I've worked for smal= ler ones than my current position), and I was under the impression that we = were not wearing hats within the IETF. If this isn't the case - that= 9;s fine, but I'll reserve my right to not contribute to the discussion= .

r.

On Wed, 22 Feb 2017 at 10:45 Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de> wrote:
On Wed, Feb 22, = 2017 at 05:08:36PM +0000, Kent Watsen wrote:
>
> As for Unicode support, some servers don't even support Unicode, s= o
> translating the XSD pattern to another regex that doesn't support<= br class=3D"gmail_msg"> > Unicode would be a non-issue for these systems.

I think strictly speaking, a server not supporting Unicode is not
compliant. So why care about how a non-compliant server deals with the
fact of not being compliant? I understand that for global operators
Unicode may not be important since they use English as their lingua
france (love this expression). But the technology is not just for big
global operators.

/js

--
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 | 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-univer= sity.de/>
--94eb2c05e9a2fc8b480549230709-- From nobody Wed Feb 22 10:59:54 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ED4129A47; Wed, 22 Feb 2017 10:59:53 -0800 (PST) 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 FabNNc08PKRk; Wed, 22 Feb 2017 10:59:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0147B129A3F; Wed, 22 Feb 2017 10:59:52 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 20CF71AE0187; Wed, 22 Feb 2017 19:59:51 +0100 (CET) Date: Wed, 22 Feb 2017 19:59:50 +0100 (CET) Message-Id: <20170222.195950.1851393848459342115.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: References: <20170222.194349.709735877588963434.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: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 18:59:53 -0000 Rob Shakir wrote: > On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund wrote: > > > > > For my understanding, did you consider libxml2? I would like to > > understand what "implementation barrier" and "implementation > > complexity" really means. > > > > Pyangbind uses lxml for some elements of its functionality - particularly > to support a lightweight XML backend for XPATH querying. It doesn't use > libxml2 for regexps. When I looked originally, I didn't find useful > language bindings to libxml2 in Python. pyang is using libxml2 to validate the patterns. > In other projects, we don't have any XML library dependencies, adding > libxml2 as a dependency seems overkill simply to parse regexs when there > are built in libraries in many languages without libxml2. Hmm. In what way overkill? For ConfD/NCS we actually took the regexp part of libxml2 and we build a separate .a/.so file; the .a file is ~130K stripped. Compared to ~3M for libxml2. If it would help I can publish this project on github. /martin From nobody Wed Feb 22 11:03:40 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCDE4129A69; Wed, 22 Feb 2017 11:03:34 -0800 (PST) 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 jB6oaFBCRwbf; Wed, 22 Feb 2017 11:03:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8E1298B9; Wed, 22 Feb 2017 11:03:33 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id 6DA811AE0187; Wed, 22 Feb 2017 20:03:32 +0100 (CET) Date: Wed, 22 Feb 2017 20:03:32 +0100 (CET) Message-Id: <20170222.200332.806502305400371391.mbj@tail-f.com> To: rjs@rob.sh From: Martin Bjorklund In-Reply-To: References: <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@juniper.net> <20170222184502.GA46638@elstar.local> 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: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, yingzhen.qu@huawei.com, akatlas@gmail.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, acee@cisco.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 19:03:35 -0000 Rob Shakir wrote: > I suspect, based on this position, that this discussion will diverge. I > suspect the community of interest is some implementation community, rather > than a standards one. Taking the academic case that servers that don't > support unicode shouldn't be cared about, when there are many, real world, > systems that fall into this category is nice, but doesn't help operators > move forward. I think that maybe the position should be that we need to care also about implementations that *do* need unicode. So picking a regexp dialect that doesn't support unicode in the standard is probably not a good idea - NOTE: I don't know if you have proposed this or not, but others have. /martin From nobody Wed Feb 22 11:08:09 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E56129A9A for ; Wed, 22 Feb 2017 11:08:08 -0800 (PST) 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.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 KRR6KmWy5-ab for ; Wed, 22 Feb 2017 11:08:05 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 BEAD2129A7A for ; Wed, 22 Feb 2017 11:08:05 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id y135so9858586itc.1 for ; Wed, 22 Feb 2017 11:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vh/WYzaLTtqoECAO/jzbGjn6q653m/+G5Zguto3zQgU=; b=IeoL+s+ZhKveVVv32eK9xiBuW2oW7Y9n5bJuEjQtaLf7LRwp8rvQb6NYbchCA9DqgX mNDfq//hbnXIdmSuW7K4ho4EDKdzy5wI/LmUsmW7F275hWKwG7ao7gjgoJr604oMriDs 0X2Y3dm7NUb5sp4qQgceU10rEKoF/ILn2afpeetp8PoklGVmepOWrkYM3jj7RWc2QB+9 A88IaISO7mBXge6DTxXkErjdBe/MABWrhR+J3VriIQ4WA3v+hKlB89iYf6tG7w/lQVoE TE2Jao5BMh4IV6dLMlzUz+4zOpZ59vWSyuMC94JQmc63CMXIHX47SfAAXc8Icycw2zY3 LbjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vh/WYzaLTtqoECAO/jzbGjn6q653m/+G5Zguto3zQgU=; b=GXr7wVVS+S4h0WzZr+NJ8BasEUERn0KdIskyg5d4QheTqWiaULwNRrUqhP8K66oWE6 SAMDal9TNUX6MLr5WtWXQDsTvaEWpUAEvUPQ7Qg/nCJuEgMx3sMTTtKt6UBxDztTC9JI 3w9GiXSP4LTKugBaEuDBzFKIzIT8Mg/1T7XDSwbGl7uMWb0DF6YMkQvUSsZktYUo/aU2 PUOvv0NBJJDLXHJmo7qeADdf+MdiagOHNaFRWkjjeKuzKhktUYxnT/eTtwX/KWretSS5 Wpo2ROqg5a7FRlpBb2aIYO5K77EQMURYvN2M6j+GwOeNrdZrDXB5RKH7xy4LAIgvXiD5 /bwA== X-Gm-Message-State: AMke39m0Jnus3fqJqkB0l6vqJKnYHNOvUK1c9cc6zeBy3Q0fuagVHtPgeIiabD2+BU0jkOle8nzevMtO/Bsrlg== X-Received: by 10.107.172.7 with SMTP id v7mr28915165ioe.49.1487790484955; Wed, 22 Feb 2017 11:08:04 -0800 (PST) MIME-Version: 1.0 References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> In-Reply-To: <20170222.195950.1851393848459342115.mbj@tail-f.com> From: Rob Shakir Date: Wed, 22 Feb 2017 19:07:54 +0000 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c05a3805b4e290549233750 Archived-At: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, lberger@labn.net, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 19:08:08 -0000 --94eb2c05a3805b4e290549233750 Content-Type: text/plain; charset=UTF-8 I'm not asserting it is not possible to do so - of course it is, and I encourage anything to be open sourced that helps YANG adoption (hey, I'm actually trying to do that everywhere I can). But there are other problems too - what common tooling is available for non-developers that are writing models? For example, there are many, many different sites that will give you a way to validate that a regexp matches some test content that you're interested in (e.g., http://regexr.com/, https://regex101.com/). I have found none of these that support XSD regexps. The key point is that picking a road less travelled comes with costs around the ecosystem. I don't think anyone on this thread has asserted "The regexp forward must be POSIX". I am definitely sympathetic to the need for unicode support. Let's debate the merits of the different solutions - with everything in mind, not a single implementation iff we want to change something in YANG. OC - which targets specific use cases - simply because we are use-case focused, may make specific decisions that work with the systems that it is interested with a view to getting to the stage of being able to move network management forward. The latter's what I care about most. YANG is really just a means to an end. r. On Wed, 22 Feb 2017 at 10:59 Martin Bjorklund wrote: > Rob Shakir wrote: > > On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund wrote: > > > > > > > > For my understanding, did you consider libxml2? I would like to > > > understand what "implementation barrier" and "implementation > > > complexity" really means. > > > > > > > Pyangbind uses lxml for some elements of its functionality - particularly > > to support a lightweight XML backend for XPATH querying. It doesn't use > > libxml2 for regexps. When I looked originally, I didn't find useful > > language bindings to libxml2 in Python. > > pyang is using libxml2 to validate the patterns. > > > In other projects, we don't have any XML library dependencies, adding > > libxml2 as a dependency seems overkill simply to parse regexs when there > > are built in libraries in many languages without libxml2. > > Hmm. In what way overkill? For ConfD/NCS we actually took the regexp > part of libxml2 and we build a separate .a/.so file; the .a file is > ~130K stripped. Compared to ~3M for libxml2. If it would help I can > publish this project on github. > > > /martin > --94eb2c05a3805b4e290549233750 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not asserting it is not possible to do so - of cou= rse it is, and I encourage anything to be open sourced that helps YANG adop= tion (hey, I'm actually trying to do that everywhere I can).

But there are other problems too - what common tooling is availabl= e for non-developers that are writing models? For example, there are many, = many different sites that will give you a way to validate that a regexp mat= ches some test content that you're interested in (e.g.,=C2=A0http://regexr.com/,=C2=A0https://regex101.com/). I have found none of these that suppor= t XSD regexps. The key point is =C2=A0that picking a road less travelled co= mes with costs around the ecosystem.

I don't t= hink anyone on this thread has asserted "The regexp forward must be PO= SIX". I am definitely sympathetic to the need for unicode support. Let= 's debate the merits of the different solutions - with everything in mi= nd, not a single implementation iff we want to change something in YANG.=C2= =A0

OC - which targets specific use cases - simply= because we are use-case focused, may make specific decisions that work wit= h the systems that it is interested with a view to getting to the stage of = being able to move network management forward. The latter's what I care= about most. YANG is really just a means to an end.

r.


On Wed, 22 Feb 2017 at 10:59 Martin Bjorklund <mbj@tail-f.com> wrote:
Rob Shakir <rjs@rob.sh> wrote:
> On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund <mbj@tail-f.com> = wrote:
>
> >
> > For my understanding, did you consider libxml2?=C2=A0 I would lik= e to
> > understand what "implementation barrier" and "impl= ementation
> > complexity" really means.
> >
>
> Pyangbind uses lxml for some elements of its functionality - particula= rly
> to support a lightweight XML backend for XPATH querying. It doesn'= t use
> libxml2 for regexps. When I looked originally, I didn't find usefu= l
> language bindings to libxml2 in Python.

pyang is using libxml2 to validate the patterns.

> In other projects, we don't have any XML library dependencies, add= ing
> libxml2 as a dependency seems overkill simply to parse regexs when the= re
> are built in libraries in many languages without libxml2.

Hmm.=C2=A0 In what way overkill?=C2=A0 For ConfD/NCS we actually took the r= egexp
part of libxml2 and we build a separate .a/.so file; the .a file is
~130K stripped.=C2=A0 Compared to ~3M for libxml2.=C2=A0 If it would help I= can
publish this project on github.


/martin
--94eb2c05a3805b4e290549233750-- From nobody Wed Feb 22 12:03:39 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B72129AD3; Wed, 22 Feb 2017 12:03:38 -0800 (PST) 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=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 jUfdC9vVoDzF; Wed, 22 Feb 2017 12:03:36 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0127.outbound.protection.outlook.com [104.47.37.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05177129AC9; Wed, 22 Feb 2017 12:03:35 -0800 (PST) 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=A+KFKPwPGI1UPOzme3nrzG06U3uA0uZnHav5itVhUJU=; b=PdkF6Un/TYeO5/wPkGtbTpYhhUwZPJVrmOHrVd+owaz3VlAoY+ruXeGsT6ooFFWo4DRfnfGV4CCvhEwyX9h9R5LwuL1l/pGQClB/eeBPhrBjspxICdyTNlRwJDAXigESgO8LrROaaiAHlPcMt6a8PwJmP6fXgo2l9e1wSBc7A20= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1219.namprd05.prod.outlook.com (10.160.113.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 20:03:34 +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.0919.018; Wed, 22 Feb 2017 20:03:34 +0000 From: Kent Watsen To: Rob Shakir , Martin Bjorklund , "lberger@labn.net" Thread-Topic: [Rtg-dt-yang-arch] [yang-doctors] Open Config on ietf-routing-types Thread-Index: AQHSjQOEKaRJ03OB6Eaug6rVYP2mGKF09pAA///4MACAAGvWAP//xQ6A Date: Wed, 22 Feb 2017 20:03:34 +0000 Message-ID: References: <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20170222.133632.1310891825599234865.mbj@tail-f.com> <9C688BE3-BD7E-462B-ADA2-CEC216F3FBA8@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.1f.0.170216 authentication-results: rob.sh; dkim=none (message not signed) header.d=none;rob.sh; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 3daeea36-69c9-4989-f996-08d45b5de1d6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1219; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1219; 7:zRMeN5ZI/HkepmREBxS9YmP6KAwafYdagDjh4NNNYxHSz3UTJytej65oqC6n1mLjWOhM9Q6d2NffIKQK534AiNd7YjZxXnyYdM5uDZlYbXNPhQ68IqXtivqbxlhwesDnUoNRQ1g9rmkfp9n+65pnDyYpWlZUxuvADOdpcsSkc5W4u4UMSq7LrSnQHVNKwSmBlnodrOYPESk9rSkS+FpibDzuU8zvf1jixJs1BZZEPQu5/j954Me5O6W6LNHLxNUznYM1fInCfQTKxJukhaqre2fgYybiQ3SsJIQuNeIw1xlib6PvP47t/8QzjGm1YSxgRnbdlLEYMVV0KbDrCE13/A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851)(138986009662008)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:BN3PR0501MB1219; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1219; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39410400002)(39840400002)(39850400002)(377454003)(24454002)(92566002)(3280700002)(106116001)(3660700001)(53546006)(38730400002)(6246003)(2501003)(83716003)(7736002)(39060400002)(7416002)(2906002)(66066001)(33656002)(230783001)(93886004)(2950100002)(82746002)(83506001)(189998001)(122556002)(2900100001)(6512007)(6306002)(54896002)(4326007)(4001350100001)(6436002)(54356999)(76176999)(99286003)(50986999)(236005)(3846002)(6116002)(8676002)(86362001)(36756003)(53936002)(81166006)(102836003)(8936002)(6486002)(5660300001)(54906002)(77096006)(6506006)(229853002)(25786008)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1219; 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_D31BCD9172FB409EA72E850F208EC05Fjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 20:03:34.3689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1219 Archived-At: Cc: "rtg-dt-yang-arch@ietf.org" , Phil Shafer , "aashaikh@google.com" , "Xufeng_Liu@jabil.com" , "akatlas@gmail.com" , "acee@cisco.com" , "yang-doctors@ietf.org" , "jefftant.ietf@gmail.com" , "yingzhen.qu@huawei.com" Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:03:38 -0000 --_000_D31BCD9172FB409EA72E850F208EC05Fjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZXSVcsIEkgZm91bmQgYSB0b29sIHRoYXQgY2FuIGNvbnZlcnQgWFNEIHJlZ2V4IHRvIH4y MyBvdGhlciByZWdleCBkaWFsZWN0cyAoaW5jbHVkaW5nIFBPU0lYKSBoZXJlOg0KDQogICAgaHR0 cHM6Ly93d3cucmVnZXhidWRkeS5jb20veG1sLmh0bWwNCg0KSXQncyBhIGNvbW1lcmNpYWwsIGFu ZCBXaW5kb3dzLW9ubHksIGJ1dCBhdCBsZWFzdCBzaG93cyB0aGF0IGl0IGlzIGRvYWJsZS4NCg0K Sy4NCg0KDQpPbiAyLzIyLzE3LCAxOjM0IFBNLCAiUm9iIFNoYWtpciIgPHJqc0Byb2Iuc2g8bWFp bHRvOnJqc0Byb2Iuc2g+PiB3cm90ZToNCg0KTm90ZSwgbXkgbWFpbCBkaWRuJ3QgYXNrIGZvciBh bnl0aGluZyB0byBiZSBjaGFuZ2VkLiBJdCBqdXN0IG5vdGVkIHRoYXQgdGhlcmUgYXJlIGltcGxl bWVudGF0aW9uIGNvbXBsZXhpdGllcyBvZiBoYXZpbmcgYW4gWFNEIHJlZ2V4cCBkaWFsZWN0IHRo YXQgaXMgbm90IHdpZGVseSBzdXBwb3J0ZWQgaW4gbm9uLVhNTCBsaWJyYXJpZXMuIFRoaXMgaXMg YW4gaW1wbGVtZW50YXRpb24gYmFycmllciBmb3Igc2VydmVycyB0aGF0IHdhbnQgdG8gdXNlIFlB TkcgdG8gbW9kZWwgdGhlaXIgc2NoZW1hLiBLZW50IGlzIHJpZ2h0LCB0cmFuc2xhdGlvbiBpcyBh biBhcHByb2FjaCAtIGJ1dCB0cmFuc2NvZGluZyByZWdleHBzIGlzIHNvbWV0aGluZyB0aGF0IGFk ZHMgbW9yZSBjb2RlIHRvIG1haW50YWluIGZvciB0aG9zZSBidWlsZGluZyBzeXN0ZW1zIHRoYXQg dXNlIHRoZXNlIGRhdGEgbW9kZWxzLg0KDQpJIGtub3csIGZyb20gY29tbWVudHMgbWFkZSBlbHNl d2hlcmUsIHRoYXQgdGhpcyBpc24ndCBqdXN0IHNvbWV0aGluZyB0aGF0IGlzIGFuIE9wZW5Db25m aWcgaXNzdWUgLSBhbmQgSSdtIGZpbmUgaWYgTkVUTU9EL0lFVEYgZG9lc24ndCB3YW50IHRvIHdv cmsgb24gYSBzb2x1dGlvbi4gTWVyZWx5LCBhcyBzb21lb25lIHRoYXQgaGFzIHNwZW50IGEgY291 cGxlIG9mIHllYXJzIHdyaXRpbmcgYWN0dWFsbHkgd3JpdGluZyBtb2RlbHMsIGFuZCBpbXBsZW1l bnRpbmcgdG9vbGluZyBhcm91bmQgWUFORyB0aGF0J3MgdXNlZCB0byBydW4gbmV0d29ya3MgLSBJ IHByb3ZpZGVkIGZlZWRiYWNrIGFzIHRvIHdoYXQgdGhlIGlzc3VlIHdhcyBmb3IgdGhlIHN5c3Rl bXMgdGhhdCB3ZSdyZSBjb25zaWRlcmluZy4NCg0Kci4NCg0KT24gV2VkLCAyMiBGZWIgMjAxNyBh dCAwOTowOCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBq dW5pcGVyLm5ldD4+IHdyb3RlOg0KDQoNCj4gVGhlIG90aGVyIGlzc3VlIGlzIGhvdyBPQyBjYW4g dXRpbGl6ZSBJRVRGIG1vZHVsZXMgd2l0aCByZWdleHBzDQo+IHdyaXR0ZW4gaW4gdGhlIHN0YW5k YXJkIGRpYWxlY3QuICBJTU8gdGhpcyBpcyBtb3JlIGFuIGltcGxlbWVudGF0aW9uDQo+IG1hdHRl ci4gIFRoZSAicGF0dGVybiIgc3RhdGVtZW50IGZvcm1hbGx5IGRlZmluZXMgYSBjb25zdHJhaW50 IG9uDQo+IHRoZSB2YWx1ZSBzcGFjZSwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgdGhhdCByZXF1aXJl cyBhbiBpbXBsZW1lbnRhdGlvbg0KPiB0byB1c2UgdGhlIHBhdHRlcm4gZXhhY3RseSBhcyBpdCBp cyBzcGVjaWZpZWQuICBBIHRvb2xjaGFpbiB0aGF0DQo+IGRvZXNuJ3QgdW5kZXJzdGFuZCB0aGUg WFNEIHJlZ2V4cCBkaWFsZWN0IGNhbiBzaW1wbHkgaWdub3JlIHRoZQ0KPiBwYXR0ZXJuOyBvciBp ZiBpdCBpcyBjbGV2ZXIgYW5kIG1heWJlIGRvZXNuJ3QgcmVhbGx5IGNhcmUgYWJvdXQNCj4gdW5p Y29kZSBpdCBjYW4gdHJhbnNsYXRlIHRoZSBwYXR0ZXJuIHRvIGFub3RoZXIgZGlhbGVjdCBhdXRv bWF0aWNhbGx5Ow0KPiBvciBpZiBpdCBpcyBldmVuIG1vcmUgY2xldmVyIGl0IGNhbiB0cmFuc2xh dGUgaWYgcG9zc2libGUgb3Igb3RoZXJ3aXNlDQo+IHVzZSBhIHVzZXItcHJvdmlkZWQgcmVnZXhw IGluIGFub3RoZXIgZGlhbGVjdC4gIFRoZXNlIGFyZSBqdXN0DQo+IHN1Z2dlc3Rpb25zIG9mIGNv dXJzZSwgSSdtIHN1cmUgdGhlcmUgYXJlIG90aGVyIHdheXMgb2YgZGVhbGluZyB3aXRoDQo+IHRo aXMuDQoNClJpZ2h0LCBhIHNlcnZlciBkb2Vzbid0IGhhdmUgdG8gY29tcGlsZS9leGVjdXRlIHRo ZSBYU0QgJ3BhdHRlcm4nDQpleHByZXNzaW9uIGF0IGFsbCwgc28gbG9uZyBhcyBpdCBjYW4gaW1w bGVtZW50IHRoZSB2YWxpZGF0aW9uIHJ1bGVzDQpieSBvdGhlciBtZWFucywgcGVyaGFwcyBieSB0 cmFuc2xhdGluZyB0aGUgWFNEIHBhdHRlcm4gdG8gYW5vdGhlcg0KZGlhbGVjdCBvciBieSBqdXN0 IHVzaW5nICdDJyBjb2RlLiAgSWYgdGhlIHNlcnZlcidzIGltcGxlbWVudGF0aW9uDQpvZiBhIHBh dHRlcm4gaXMgbm90IGEgMTAwJSBhY2N1cmF0ZSwgdGhlbiBjdXN0b21lcnMgd2lsbCByZXBvcnQg dGhlDQppc3N1ZSBhbmQgdGhlIHNlcnZlciB3aWxsIGJlIGltcHJvdmVkLg0KDQpBcyBmb3IgVW5p Y29kZSBzdXBwb3J0LCBzb21lIHNlcnZlcnMgZG9uJ3QgZXZlbiBzdXBwb3J0IFVuaWNvZGUsIHNv DQp0cmFuc2xhdGluZyB0aGUgWFNEIHBhdHRlcm4gdG8gYW5vdGhlciByZWdleCB0aGF0IGRvZXNu J3Qgc3VwcG9ydA0KVW5pY29kZSB3b3VsZCBiZSBhIG5vbi1pc3N1ZSBmb3IgdGhlc2Ugc3lzdGVt cy4gIFBlcmhhcHMgYSBnZW5lcmljDQpYU0QtcmVnZXggdG8gUE9TSVgtcmVnZXggY29udmVydG9y IGNvdWxkIGJlIHVzZWQgYnkgc3VjaCBzeXN0ZW1zLg0KU2VhcmNoaW5nIG9ubGluZSwgSSBkb24n dCBmaW5kIGFueSBzdWNoIGNvbnZlcnRvciBhdmFpbGFibGUgKGJ1dCBJDQpkaWRuJ3QgbG9vayB2 ZXJ5IGhhcmQpLiAgUGVyaGFwcyB0aGlzIHdvdWxkIG1ha2UgZm9yIGJlIGEgZ29vZA0KSGFja2F0 aG9uIHByb2plY3Q/IDspDQoNCktlbnQgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCg0K --_000_D31BCD9172FB409EA72E850F208EC05Fjunipernet_ 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+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+RldJVywgSSBm b3VuZCBhIHRvb2wgdGhhdCBjYW4gY29udmVydCBYU0QgcmVnZXggdG8gfjIzIG90aGVyIHJlZ2V4 IGRpYWxlY3RzIChpbmNsdWRpbmcgUE9TSVgpIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cu cmVnZXhidWRkeS5jb20veG1sLmh0bWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmkiPkl0J3MgYSBjb21tZXJjaWFsLCBhbmQgV2luZG93cy1vbmx5LCBidXQg YXQgbGVhc3Qgc2hvd3MgdGhhdCBpdCBpcyBkb2FibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzIyLzE3LCAxOjM0IFBNLCAmcXVvdDtS b2IgU2hha2lyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cmpzQHJvYi5zaCI+cmpzQHJvYi5z aDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUsIG15IG1haWwgZGlkbid0IGFzayBmb3IgYW55dGhp bmcgdG8gYmUgY2hhbmdlZC4gSXQganVzdCBub3RlZCB0aGF0IHRoZXJlIGFyZSBpbXBsZW1lbnRh dGlvbiBjb21wbGV4aXRpZXMgb2YgaGF2aW5nIGFuIFhTRCByZWdleHAgZGlhbGVjdCB0aGF0IGlz IG5vdCB3aWRlbHkgc3VwcG9ydGVkIGluIG5vbi1YTUwgbGlicmFyaWVzLiBUaGlzIGlzIGFuIGlt cGxlbWVudGF0aW9uIGJhcnJpZXIgZm9yIHNlcnZlcnMNCiB0aGF0IHdhbnQgdG8gdXNlIFlBTkcg dG8gbW9kZWwgdGhlaXIgc2NoZW1hLiBLZW50IGlzIHJpZ2h0LCB0cmFuc2xhdGlvbiBpcyBhbiBh cHByb2FjaCAtIGJ1dCB0cmFuc2NvZGluZyByZWdleHBzIGlzIHNvbWV0aGluZyB0aGF0IGFkZHMg bW9yZSBjb2RlIHRvIG1haW50YWluIGZvciB0aG9zZSBidWlsZGluZyBzeXN0ZW1zIHRoYXQgdXNl IHRoZXNlIGRhdGEgbW9kZWxzLg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGtub3csIGZyb20gY29tbWVudHMgbWFkZSBlbHNld2hlcmUsIHRoYXQgdGhp cyBpc24ndCBqdXN0IHNvbWV0aGluZyB0aGF0IGlzIGFuIE9wZW5Db25maWcgaXNzdWUgLSBhbmQg SSdtIGZpbmUgaWYgTkVUTU9EL0lFVEYgZG9lc24ndCB3YW50IHRvIHdvcmsgb24gYSBzb2x1dGlv bi4gTWVyZWx5LCBhcyBzb21lb25lIHRoYXQgaGFzIHNwZW50IGEgY291cGxlIG9mIHllYXJzIHdy aXRpbmcgYWN0dWFsbHkgd3JpdGluZw0KIG1vZGVscywgYW5kIGltcGxlbWVudGluZyB0b29saW5n IGFyb3VuZCBZQU5HIHRoYXQncyB1c2VkIHRvIHJ1biBuZXR3b3JrcyAtIEkgcHJvdmlkZWQgZmVl ZGJhY2sgYXMgdG8gd2hhdCB0aGUgaXNzdWUgd2FzIGZvciB0aGUgc3lzdGVtcyB0aGF0IHdlJ3Jl IGNvbnNpZGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIDIyIEZlYiAyMDE3IGF0IDA5OjA4IEtlbnQgV2F0c2VuICZsdDs8 YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQom Z3Q7IFRoZSBvdGhlciBpc3N1ZSBpcyBob3cgT0MgY2FuIHV0aWxpemUgSUVURiBtb2R1bGVzIHdp dGggcmVnZXhwczxicj4NCiZndDsgd3JpdHRlbiBpbiB0aGUgc3RhbmRhcmQgZGlhbGVjdC4mbmJz cDsgSU1PIHRoaXMgaXMgbW9yZSBhbiBpbXBsZW1lbnRhdGlvbjxicj4NCiZndDsgbWF0dGVyLiZu YnNwOyBUaGUgJnF1b3Q7cGF0dGVybiZxdW90OyBzdGF0ZW1lbnQgZm9ybWFsbHkgZGVmaW5lcyBh IGNvbnN0cmFpbnQgb248YnI+DQomZ3Q7IHRoZSB2YWx1ZSBzcGFjZSwgYnV0IHRoZXJlIGlzIG5v dGhpbmcgdGhhdCByZXF1aXJlcyBhbiBpbXBsZW1lbnRhdGlvbjxicj4NCiZndDsgdG8gdXNlIHRo ZSBwYXR0ZXJuIGV4YWN0bHkgYXMgaXQgaXMgc3BlY2lmaWVkLiZuYnNwOyBBIHRvb2xjaGFpbiB0 aGF0PGJyPg0KJmd0OyBkb2Vzbid0IHVuZGVyc3RhbmQgdGhlIFhTRCByZWdleHAgZGlhbGVjdCBj YW4gc2ltcGx5IGlnbm9yZSB0aGU8YnI+DQomZ3Q7IHBhdHRlcm47IG9yIGlmIGl0IGlzIGNsZXZl ciBhbmQgbWF5YmUgZG9lc24ndCByZWFsbHkgY2FyZSBhYm91dDxicj4NCiZndDsgdW5pY29kZSBp dCBjYW4gdHJhbnNsYXRlIHRoZSBwYXR0ZXJuIHRvIGFub3RoZXIgZGlhbGVjdCBhdXRvbWF0aWNh bGx5Ozxicj4NCiZndDsgb3IgaWYgaXQgaXMgZXZlbiBtb3JlIGNsZXZlciBpdCBjYW4gdHJhbnNs YXRlIGlmIHBvc3NpYmxlIG9yIG90aGVyd2lzZTxicj4NCiZndDsgdXNlIGEgdXNlci1wcm92aWRl ZCByZWdleHAgaW4gYW5vdGhlciBkaWFsZWN0LiZuYnNwOyBUaGVzZSBhcmUganVzdDxicj4NCiZn dDsgc3VnZ2VzdGlvbnMgb2YgY291cnNlLCBJJ20gc3VyZSB0aGVyZSBhcmUgb3RoZXIgd2F5cyBv ZiBkZWFsaW5nIHdpdGg8YnI+DQomZ3Q7IHRoaXMuPGJyPg0KPGJyPg0KUmlnaHQsIGEgc2VydmVy IGRvZXNuJ3QgaGF2ZSB0byBjb21waWxlL2V4ZWN1dGUgdGhlIFhTRCAncGF0dGVybic8YnI+DQpl eHByZXNzaW9uIGF0IGFsbCwgc28gbG9uZyBhcyBpdCBjYW4gaW1wbGVtZW50IHRoZSB2YWxpZGF0 aW9uIHJ1bGVzPGJyPg0KYnkgb3RoZXIgbWVhbnMsIHBlcmhhcHMgYnkgdHJhbnNsYXRpbmcgdGhl IFhTRCBwYXR0ZXJuIHRvIGFub3RoZXI8YnI+DQpkaWFsZWN0IG9yIGJ5IGp1c3QgdXNpbmcgJ0Mn IGNvZGUuJm5ic3A7IElmIHRoZSBzZXJ2ZXIncyBpbXBsZW1lbnRhdGlvbjxicj4NCm9mIGEgcGF0 dGVybiBpcyBub3QgYSAxMDAlIGFjY3VyYXRlLCB0aGVuIGN1c3RvbWVycyB3aWxsIHJlcG9ydCB0 aGU8YnI+DQppc3N1ZSBhbmQgdGhlIHNlcnZlciB3aWxsIGJlIGltcHJvdmVkLjxicj4NCjxicj4N CkFzIGZvciBVbmljb2RlIHN1cHBvcnQsIHNvbWUgc2VydmVycyBkb24ndCBldmVuIHN1cHBvcnQg VW5pY29kZSwgc288YnI+DQp0cmFuc2xhdGluZyB0aGUgWFNEIHBhdHRlcm4gdG8gYW5vdGhlciBy ZWdleCB0aGF0IGRvZXNuJ3Qgc3VwcG9ydDxicj4NClVuaWNvZGUgd291bGQgYmUgYSBub24taXNz dWUgZm9yIHRoZXNlIHN5c3RlbXMuJm5ic3A7IFBlcmhhcHMgYSBnZW5lcmljPGJyPg0KWFNELXJl Z2V4IHRvIFBPU0lYLXJlZ2V4IGNvbnZlcnRvciBjb3VsZCBiZSB1c2VkIGJ5IHN1Y2ggc3lzdGVt cy48YnI+DQpTZWFyY2hpbmcgb25saW5lLCBJIGRvbid0IGZpbmQgYW55IHN1Y2ggY29udmVydG9y IGF2YWlsYWJsZSAoYnV0IEk8YnI+DQpkaWRuJ3QgbG9vayB2ZXJ5IGhhcmQpLiZuYnNwOyBQZXJo YXBzIHRoaXMgd291bGQgbWFrZSBmb3IgYmUgYSBnb29kPGJyPg0KSGFja2F0aG9uIHByb2plY3Q/ IDspPGJyPg0KPGJyPg0KS2VudCAvLyBhcyBhIGNvbnRyaWJ1dG9yPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D31BCD9172FB409EA72E850F208EC05Fjunipernet_-- From nobody Wed Feb 22 12:47:34 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BAB129B21; Wed, 22 Feb 2017 12:47:33 -0800 (PST) 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 QZKiLZ2C8RwW; Wed, 22 Feb 2017 12:47:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 937CF129B1F; Wed, 22 Feb 2017 12:47:31 -0800 (PST) Received: from localhost (h-148-188.a165.priv.bahnhof.se [176.10.148.188]) by mail.tail-f.com (Postfix) with ESMTPSA id D7B151AE0187; Wed, 22 Feb 2017 21:47:29 +0100 (CET) Date: Wed, 22 Feb 2017 21:47:29 +0100 (CET) Message-Id: <20170222.214729.1452616383371340013.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20170222.194349.709735877588963434.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: Cc: rtg-dt-yang-arch@ietf.org, lberger@labn.net, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, jefftant.ietf@gmail.com, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:47:33 -0000 Andy Bierman wrote: > Hi, > > Rob's last comment is actually quite important because SMIv2 veered off from > the mainstream and it really diminished the available tools for SNMP. > We should avoid the same fate for YANG. > > Has the mainstream moved away from the XSD regexp and towards Posix regexp? It's not that simple. There are many dialects available. See http://www.regular-expressions.info/tools.html for a list. Regardless of which dialect you pick, someone will prefer another one. OTOH you can also argue that people are used to the fact that different tools/systems use different dialects, so they adapt to whatever the tool they are using support. > And by Posix regexp, do you mean sec. 9 of this spec: > http://pubs.opengroup.org/onlinepubs/9699919799/ > (This is a really heavyweight regexp in its entirety) > > YANG automation tools would be diminished if the standard pattern-stmt > was ignored and an extension was used instead. This is my main concern > with an extension. Agreed - but I suggested this as an alternative to what they (OC) are using now. The current OC models use the standard "pattern" statement, but with POSIX syntax. An extension would be better IMO. /martin From nobody Wed Feb 22 13:37:37 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFC3129B75; Wed, 22 Feb 2017 13:37:36 -0800 (PST) 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, FREEMAIL_FROM=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 2LDQydZiAEKQ; Wed, 22 Feb 2017 13:37:35 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 0B833129B68; Wed, 22 Feb 2017 13:37:35 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id p185so289406pfb.0; Wed, 22 Feb 2017 13:37:35 -0800 (PST) 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=3iqs0i6tkSMbUJfIjFCrOYDJovkQwL1MfiFEwbRqE0c=; b=F1yDPYpJElimLukrqXfsH+ByueEN1PYM0yGHVjtWkb2M44i+iIifPLwNWl3OQxJnmk faD7xS+AErPCBv1EMGfmIbqKzRciC3RqX6A7tS8ImVyFZ5nMxLSEIVT0ijaQ2vji1LCu A+XwDSHpAE5MqcLjWT53tUiAyshbsnWq3id7AdZGCT592FAFWyJaQYk9/gjxiURtOr6K 8UsmIcrS7hDZm3K0ieWA0I9v18Wfun6rapVVjLyXQmDoc1rmjDvPiCFx+QVaSe9SUA5n AMt3oMpqII26ekV+hN2FvLrhkzqHHIf/vN4amwO2DcPHysykjNBcDZN3ez6yrhkEGSwr 4RiA== 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=3iqs0i6tkSMbUJfIjFCrOYDJovkQwL1MfiFEwbRqE0c=; b=Y/pLA8jskySRAkT2Dsex+UDPOkTi4tfkGTNmj/BZIoLauyzSzv0dpVKy935Y7Mss4G j1gE8G5S0M86Rd9KC0ezexZSo6MNeCXyeWirXJbfutoNtMDcWZpw3lJBmdXSbxZxWjN/ aEK2+7hoibC3rSxgUNuLKp414nuS5/57YNw+SNE8yfA/IWyq5CzsDbv0k0P59UD4zsF3 Esa3MsVDWyDefZoT/zSQnotgrXJ7XKgOSZWge1P/EvV3Estn3sH7Nee5sJzX7acEOVJb 1L04c0Vn9ujnmR62Ltnr3u0ENq0aLdz7NXRkB3nhkxcv8s97Lz4+0cdlGXYPJLNfFdhw A/cA== X-Gm-Message-State: AMke39lw8dC/uyo9+r1oKjAY0u/9mdj/M2iiikfo43uY9Obytfqhixc/dJTfqsX2YCHkmw== X-Received: by 10.98.60.20 with SMTP id j20mr13200075pfa.128.1487799454502; Wed, 22 Feb 2017 13:37:34 -0800 (PST) Received: from [192.168.1.4] ([76.126.247.72]) by smtp.gmail.com with ESMTPSA id 67sm5352818pfd.120.2017.02.22.13.37.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 13:37:33 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.1f.0.170216 Date: Wed, 22 Feb 2017 13:37:31 -0800 From: Jeff Tantsura To: Lou Berger , Martin Bjorklund Message-ID: <09FAEE92-711C-47D1-9BDB-CAF096F2FFF4@gmail.com> Thread-Topic: [Rtg-dt-yang-arch] [yang-doctors] Open Config on ietf-routing-types References: <15D625FF-F977-437D-8439-C485F7324267@gmail.com> <20170222.092522.195034997221928672.mbj@tail-f.com> <443E8F6C-4C8A-4BFD-B117-092B666D6999@gmail.com> <20170222.101217.1995562365191986711.mbj@tail-f.com> <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <15a65b31aa8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Cc: rtg-dt-yang-arch@ietf.org, phil@juniper.net, aashaikh@google.com, Xufeng_Liu@jabil.com, akatlas@gmail.com, acee@cisco.com, yang-doctors@ietf.org, rjs@rob.sh, yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:37:36 -0000 Lou, Exactly, this is what had been stated in the previous email. Cheers, Jeff | Once you get into potential solutions that go beyond a single module, i.e., | are changes to yang, it's really best to have the discussion in the | location the general Yang expertise, ie net mod. From nobody Wed Feb 22 19:28:29 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919C129F53 for ; Wed, 22 Feb 2017 19:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 LoTO75HvH414 for ; Wed, 22 Feb 2017 19:28:22 -0800 (PST) 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 16F61129F33 for ; Wed, 22 Feb 2017 19:28:22 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id 89so14038546wrr.3 for ; Wed, 22 Feb 2017 19:28:21 -0800 (PST) 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=Dn9mbs0RiCncF23NoH+YaRx8lPxTnH2xrx2xTbLPJoM=; b=jvoy8+WtRgJ1Nq8Sb1oo/9uPoSgYdXvNTch2+mSOWit7zDYbHaoCgomGxGSq+LPNd4 cvNdoruHkfngVayF4VS+xCiTpFxKv8AZ1i1aWnXZifLmc1sjB8u+7T6/NcHlCjs6i1h/ JXJaEaiupfV2xUXuxgw9/9c+5ettsAB54aFsWARN3h8hFgcF12VJyhsJJIBbnhXaE3M1 EYoWk9CUH4BcwUl4cqLlJEzRFoH73+iyE/5Okbv0a5YfHORTB3P9ewnuP8fbDn3E74RO pxQJXQ6l+gNS5NgRFL3q+qjo302TTe7x991Wz1/YQ1057XR+fhil19zWBZcep50lOCeD Kzgw== 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=Dn9mbs0RiCncF23NoH+YaRx8lPxTnH2xrx2xTbLPJoM=; b=V9z42JX0d6ViCbrcsuhvgGH/I2FAWrcriFSHPrTyK68YMytg0LweCrj3/xw9ba1sJf PFsIrBs5SWzddaWKyZllXpa9n1u3lqt6JNuHO8kyec8RzYkDwd3/6dzF5tP1eGDFx5Mq N4JQPElOu6bNIBWOgwEqrHG8boK7HCJwaOMftPADHz3SjPlLms4fzL6IAS+9N1vFExWP GGBWSP14SZQWywqHM2Dn2NISlbLE1pX+3ZGWy7X6hPOu/83i/0qntLVIWwB8p7NCCAB/ qqpHVUTVs2FRu51cOUuzYPoB66REt0OJeViAUVD+p60lPJ/lV0t63R0pi8l0sg4gvA+w ljeg== X-Gm-Message-State: AMke39kMawWRyJjxLxQuCnI8ebeDmcXM8C4wxOYdOPB1YWFdKaR5/IV01X97BsgN/j2fAgkuZfm1w2fy47Gbjw== X-Received: by 10.223.165.17 with SMTP id i17mr30428244wrb.62.1487820500579; Wed, 22 Feb 2017 19:28:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Wed, 22 Feb 2017 19:28:19 -0800 (PST) In-Reply-To: <20170222.214729.1452616383371340013.mbj@tail-f.com> References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.214729.1452616383371340013.mbj@tail-f.com> From: Andy Bierman Date: Wed, 22 Feb 2017 19:28:19 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=f403045f1fb06d4ae405492a34e1 Archived-At: Cc: Routing Area YANG Architecture DT , Berger Lou , Phil Shafer , Anees Shaikh , Xufeng Liu , Alia Atlas , "Acee Lindem \(acee\)" , YANG Doctors , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 03:28:25 -0000 --f403045f1fb06d4ae405492a34e1 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 12:47 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > Rob's last comment is actually quite important because SMIv2 veered off > from > > the mainstream and it really diminished the available tools for SNMP. > > We should avoid the same fate for YANG. > > > > Has the mainstream moved away from the XSD regexp and towards Posix > regexp? > > It's not that simple. There are many dialects available. See > http://www.regular-expressions.info/tools.html for a list. Regardless > of which dialect you pick, someone will prefer another one. OTOH you > can also argue that people are used to the fact that different > tools/systems use different dialects, so they adapt to whatever the > tool they are using support. > It is important that there is a clear mandatory syntax that all YANG tools can count on. Pick your own flavor is what I already have to deal with for 20+ Linux distros, MacOSX, and Windows. > > And by Posix regexp, do you mean sec. 9 of this spec: > > http://pubs.opengroup.org/onlinepubs/9699919799/ > > (This is a really heavyweight regexp in its entirety) > > > > YANG automation tools would be diminished if the standard pattern-stmt > > was ignored and an extension was used instead. This is my main concern > > with an extension. > > Agreed - but I suggested this as an alternative to what they (OC) are > using now. The current OC models use the standard "pattern" > statement, but with POSIX syntax. An extension would be better IMO. > > Obviously better if one cares about interoperability. The extension seems reasonable, especially if it is possible to always specify the XSD pattern-stmt when the extension is used. I think you should put your parser from libxml2 on github. It is more relevant than ever, since RESTCONF does not require XML at all. It would help vendors who use something else besides libxml2. > /martin > Andy --f403045f1fb06d4ae405492a34e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 22, 2017 at 12:47 PM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> Rob's last comment is actually quite important because SMIv2 veere= d off from
> the mainstream and it really diminished the available tools for SNMP.<= br> > We should avoid the same fate for YANG.
>
> Has the mainstream moved away from the XSD regexp and towards Posix re= gexp?

It's not that simple.=C2=A0 There are many dialects available.=C2=A0 Se= e
http://www.regular-expressions.info/tools.html for a list.=C2=A0 Regardless
of which dialect you pick, someone will prefer another one.=C2=A0 OTOH you<= br> can also argue that people are used to the fact that different
tools/systems use different dialects, so they adapt to whatever the
tool they are using support.


=
It is important that there is a clear mandatory syntax that all YANG t= ools can count on.=C2=A0
Pick your own flavor is what I already h= ave to deal with for 20+ Linux distros, MacOSX,
and Windows.



> And by Posix regexp, do you mean sec. 9 of this spec:
> http://pubs.opengroup.org/onlinepubs/96999= 19799/
> (This is a really heavyweight regexp in its entirety)
>
> YANG automation tools would be diminished if the standard pattern-stmt=
> was ignored and an extension was used instead. This is my main concern=
> with an extension.

Agreed - but I suggested this as an alternative to what they (OC) are
using now.=C2=A0 The current OC models use the standard "pattern"=
statement, but with POSIX syntax.=C2=A0 An extension would be better IMO.

Obviously better if one cares about interoperability= .
The extension seems reasonable, especially if it is possible
to always specify the XSD pattern-stmt when the extension is used.<= /div>

I think you should put your parser from libxml2 on= github.
It is more relevant than ever, since RESTCONF does not r= equire
XML at all.=C2=A0 It would help vendors who use something = else besides libxml2.




/martin

Andy<= /div>

--f403045f1fb06d4ae405492a34e1-- From nobody Mon Feb 27 10:39:07 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEBE12A2C6; Mon, 27 Feb 2017 10:39:05 -0800 (PST) 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 R5bmK-sM6_gt; Mon, 27 Feb 2017 10:39:03 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 6701D12999D; Mon, 27 Feb 2017 10:39:03 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id v186so68296894wmd.0; Mon, 27 Feb 2017 10:39:03 -0800 (PST) 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=FDfZnlbHmgK92Esxvm4ttdVfeMY8pXwN7pYFp6Szyr4=; b=CaygH2w/AAMk6pkysGuYJ7KhyFY1lKtNMwD5QuQ5KSAVHBpkIJvdNep/niSmuiqImy DDf5K7NxIyo6OKrINb+VwiJACmPjWdlt+I1DHKR0CESBBmE+rVjCCHydfVNsLshL32BH YnukKdaEWKYdg2+zpaSVLsGsOy90wBdhEh9ODaaFHsp3DRh67ngRNlR47znHJLYo5mt4 hKQcRQGbgK+bx223qOmZDRGnr/t4p1BRley1OGJ2VQrZ9vfvkHQNb4bCEfPNzMu+jjyX 9VEjOcX0p3VC/NA23h6SccKgKi1r2NbgZzQPpmbKyYzfraylM9gavhqYqajScdEi9jsk sJZg== 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=FDfZnlbHmgK92Esxvm4ttdVfeMY8pXwN7pYFp6Szyr4=; b=ucYmMe5F+zk9jzIESZf9/Vedt+M1R9jH2FoCiuQdESRuVmXm68neS9Bzn0GO/XMdj9 QYrsx+6SNiqUX1+r1+ECO1uPSwjrd34mJVepHOcv1QreGHP6/uBf7NZhl/FbOUcjN8gc RLVRRpUGsstCMcsTqTCZP0gc3NbgMsK4ScI5HVjnMQmayiepZZCuNQfVCKSR0cdgv8rw GH+zJR234LW5DEKyw1+ryKunIwk5onaVy5YNvZigjIKg2b68zYq0HFoorb+gPRBzP+OG g0UTTpIs8IJNStL8fw0FqMjNNNXBQ+morEHSuEqq8uRMAZZXDzKZ18bNyDuHVKSkc8+5 ZcLQ== X-Gm-Message-State: AMke39kOlsaWxHDV9VK6themlHNiqRUrw+Td0JOncWx+7fUlgX1cprwA1JGXfYMYjmnc0kxS+M2+ct/EDpp4/w== X-Received: by 10.28.207.7 with SMTP id f7mr15031472wmg.112.1488220741642; Mon, 27 Feb 2017 10:39:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.163.202 with HTTP; Mon, 27 Feb 2017 10:39:00 -0800 (PST) In-Reply-To: References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> From: Alia Atlas Date: Mon, 27 Feb 2017 13:39:00 -0500 Message-ID: To: Rob Shakir Content-Type: multipart/alternative; boundary=94eb2c0d79cca732440549876446 Archived-At: Cc: RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Acee Lindem , YANG Doctors , Jeff Tantsura , Lou Berger , yingzhen.qu@huawei.com Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:39:06 -0000 --94eb2c0d79cca732440549876446 Content-Type: text/plain; charset=UTF-8 First, while YANG models are obviously used in many places and for many purposes other than in routers, a great amount of the work on YANG modules in the IETF is in the Routing Area and targeted at routers. We need YANG modules that are practical and useful for routers and operators. Second, there is a split happening where many OpenConfig models are implemented on routers. These, of course, address limited use-cases. Doing what we can to reduce that split is useful. Getting a list of the perceived issues is useful. Claiming that we must have full agreement and understanding of the problem - when it is others who are experiencing it and making clear decisions based on their experience of the problems - is not. Understanding enough of the problem to propose solutions and iterate to get to acceptable solutions that solve the problem is important. As you all well know, we are working on getting YANG models completed and published as quickly as possible. Proposing the need for slow process, trying to put not-my-problem-fields on others' issues and implementations, and trying to make any change sound radical (YANG 2.0????) is not constructive. I would welcome Jeff organizing discussion in RTGWG around the issues with ietf-routing-types and, where they are more general, in NetMod. IETF YANG modules done in the Routing Area MUST be useful to router vendors and operators. Regards, Alia On Wed, Feb 22, 2017 at 2:07 PM, Rob Shakir wrote: > I'm not asserting it is not possible to do so - of course it is, and I > encourage anything to be open sourced that helps YANG adoption (hey, I'm > actually trying to do that everywhere I can). > > But there are other problems too - what common tooling is available for > non-developers that are writing models? For example, there are many, many > different sites that will give you a way to validate that a regexp matches > some test content that you're interested in (e.g., http://regexr.com/, htt > ps://regex101.com/). I have found none of these that support XSD regexps. > The key point is that picking a road less travelled comes with costs > around the ecosystem. > > I don't think anyone on this thread has asserted "The regexp forward must > be POSIX". I am definitely sympathetic to the need for unicode support. > Let's debate the merits of the different solutions - with everything in > mind, not a single implementation iff we want to change something in YANG. > > OC - which targets specific use cases - simply because we are use-case > focused, may make specific decisions that work with the systems that it is > interested with a view to getting to the stage of being able to move > network management forward. The latter's what I care about most. YANG is > really just a means to an end. > > r. > > > On Wed, 22 Feb 2017 at 10:59 Martin Bjorklund wrote: > >> Rob Shakir wrote: >> > On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund wrote: >> > >> > > >> > > For my understanding, did you consider libxml2? I would like to >> > > understand what "implementation barrier" and "implementation >> > > complexity" really means. >> > > >> > >> > Pyangbind uses lxml for some elements of its functionality - >> particularly >> > to support a lightweight XML backend for XPATH querying. It doesn't use >> > libxml2 for regexps. When I looked originally, I didn't find useful >> > language bindings to libxml2 in Python. >> >> pyang is using libxml2 to validate the patterns. >> >> > In other projects, we don't have any XML library dependencies, adding >> > libxml2 as a dependency seems overkill simply to parse regexs when there >> > are built in libraries in many languages without libxml2. >> >> Hmm. In what way overkill? For ConfD/NCS we actually took the regexp >> part of libxml2 and we build a separate .a/.so file; the .a file is >> ~130K stripped. Compared to ~3M for libxml2. If it would help I can >> publish this project on github. >> >> >> /martin >> > --94eb2c0d79cca732440549876446 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, while YANG models are obviously used in many places= and for many purposes other than in routers, a great amount of the work on= YANG modules in the IETF is in the Routing Area and targeted at routers. = =C2=A0 We need YANG modules that are practical and useful for routers and o= perators.

Second, there is a split happening where many = OpenConfig models are implemented on routers.=C2=A0 These, of course, addre= ss limited use-cases.=C2=A0 Doing what we can to reduce that split is usefu= l.

Getting a list of the perceived issues is usefu= l.=C2=A0 Claiming that we must have full agreement and understanding of the= problem - when it is others who are experiencing it and making clear decis= ions based on their experience of the problems - is not.=C2=A0 Understandin= g enough of the problem to propose solutions and iterate to get to acceptab= le solutions that solve the problem is important.

= As you all well know, we are working on getting YANG models completed and p= ublished as quickly as possible.=C2=A0 Proposing the need for slow process,= trying to put not-my-problem-fields on others' issues and implementati= ons, and trying to make any change sound radical (YANG 2.0????) is not cons= tructive.

I would welcome Jeff organizing discussi= on in RTGWG around the issues with ietf-routing-types and, where they are m= ore general, in NetMod.

IETF YANG modules done in = the Routing Area MUST be useful to router vendors and operators.
=
Regards,
Alia

On Wed, Feb 22, 2017 at 2:07 PM, Rob Shaki= r <rjs= @rob.sh> wrote:
I'm not asserting it is not possible to do so - of course it is, = and I encourage anything to be open sourced that helps YANG adoption (hey, = I'm actually trying to do that everywhere I can).

Bu= t there are other problems too - what common tooling is available for non-d= evelopers that are writing models? For example, there are many, many differ= ent sites that will give you a way to validate that a regexp matches some t= est content that you're interested in (e.g.,=C2=A0http://regexr.com/,=C2=A0https://regex101.com/). I have f= ound none of these that support XSD regexps. The key point is =C2=A0that pi= cking a road less travelled comes with costs around the ecosystem.

=
I don't think anyone on this thread has asserted "= ;The regexp forward must be POSIX". I am definitely sympathetic to the= need for unicode support. Let's debate the merits of the different sol= utions - with everything in mind, not a single implementation iff we want t= o change something in YANG.=C2=A0

OC - which targe= ts specific use cases - simply because we are use-case focused, may make sp= ecific decisions that work with the systems that it is interested with a vi= ew to getting to the stage of being able to move network management forward= . The latter's what I care about most. YANG is really just a means to a= n end.

<= div>r.


On Wed, 22 Feb = 2017 at 10:59 Martin Bjorklund <mbj@tail-f.com> wrote:
Rob Shakir <rjs@rob.sh> wrote:
> On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund <mb= j@tail-f.com> wrote:
>
> >
> > For my understanding, did you consider libxml2?=C2=A0 I would lik= e to
> > understand what "implementation barrier" and "impl= ementation
> > complexity" really means.
> >
>
> Pyangbind uses lxml for some elements of its functionality - particula= rly
> to support a lightweight XML backend for XPATH querying. It doesn'= t use
> libxml2 for regexps. When I looked originally, I didn't find usefu= l
> language bindings to libxml2 in Python.

pyang is using libxml2 to validate the patterns.

> In other projects, we don't have any XML library dependencies, add= ing
> libxml2 as a dependency seems overkill simply to parse regexs when the= re
> are built in libraries in many languages without libxml2.

Hmm.=C2=A0 In what way overkill?=C2=A0 For ConfD/NCS we actually took the r= egexp
part of libxml2 and we build a separate .a/.so file; the .a file is
~130K stripped.=C2=A0 Compared to ~3M for libxml2.=C2=A0 If it would help I= can
publish this project on github.


/martin

--94eb2c0d79cca732440549876446-- From nobody Mon Feb 27 10:51:06 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A036C12A2D3 for ; Mon, 27 Feb 2017 10:51:04 -0800 (PST) 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 PPWjPFHnHyMl for ; Mon, 27 Feb 2017 10:51:02 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 9A4BA12A2CE for ; Mon, 27 Feb 2017 10:51:01 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id u199so26346663wmd.1 for ; Mon, 27 Feb 2017 10:51:01 -0800 (PST) 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=N5UZUeVp4jZWaLX1PPh4DBCin6sQXkEXfhiJjBAp1Hw=; b=vejFetD7vTFNOyvRBK2/BuMCb9qbRkwx6+d1lpYH5t29Ma1jNW91kBcIAoQmbN/eei blhvdJaC1AMSKTqrYl1mb3UKwTSz252m0rnQLNARwiRqPN1XkJo/DxLViViy3L3MpyxE AmrE8FKVOGMfIHYFD8ciCeqec4dfW4P6y9p63D3devkI7p1H2TEvEw1LFK9xDQXM2lmp Mkrx43Stx49kqzRfenxIWfbgU2R/7+Y48iFYtsbsdF0HlseXFwHpSWMUlPZeBKjZFfro 1EcwX7JgoUVlDrGXefEBIaRttEvnVIVkwc/rsgWwzbGa8+HmKIRUYWfx0guVWMiic71I 9UIQ== 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=N5UZUeVp4jZWaLX1PPh4DBCin6sQXkEXfhiJjBAp1Hw=; b=mtHsCYXH5arMYrtEAK23jkwuTgN8QjGvj+mQhqQAPA4poudMj8iWYkkqSmFJxW7tXx ZoVATKxY1xddthUEY93HfmeN/21WhUFpOAwFPRfUVvvdU+GHxBUOQ4/RLTjtYd4YKSPH GGhysABadYv1bdgT682Ir5mc7NNP3+WCpNnbqFJX2ErilaRAeqChqVhN15QZvtJYINXb HVX4sfypAwn+KHWMRBIApbue8SEUM/3wLIQbODVKT2HZ5JAaIw1iNAxuzF4ZRx7KzIwG CFrFbFiNsDSLjKRGy1AaK4AzNCvOnVlXoXAjsH8nq3fXpzTssJfximJXZixhcooTsMiL D/YA== X-Gm-Message-State: AMke39l5+7QIZTJrlt3qsMqIeaW1P/HkuZn1Ph0Ldxsy9AfhVoc6c9g1JQgivKRdMHWZz1Y8ZXi9rInAtg8J1Q== X-Received: by 10.28.46.73 with SMTP id u70mr14064604wmu.54.1488221460001; Mon, 27 Feb 2017 10:51:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Mon, 27 Feb 2017 10:50:59 -0800 (PST) In-Reply-To: References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> From: Andy Bierman Date: Mon, 27 Feb 2017 10:50:59 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a114240b078a0210549878fb5 Archived-At: Cc: RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Lou Berger , Acee Lindem , YANG Doctors , Jeff Tantsura , Rob Shakir , Yingzhen Qu Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:51:04 -0000 --001a114240b078a0210549878fb5 Content-Type: text/plain; charset=UTF-8 Hi, I don't really care what process is used. That is for the IESG to figure out. Here is the text in RFC 7950: https://tools.ietf.org/html/rfc7950#section-9.4.5 That's your problem, not YANG doctors, but normative text in a standards track RFC. I am not in favor of changing that text, but if others want it changed, it seems that a new version of the YANG language would be required. The [XSD-TYPES] reference is not a typo, not an error, so an errata cannot be used to change it. Andy On Mon, Feb 27, 2017 at 10:39 AM, Alia Atlas wrote: > First, while YANG models are obviously used in many places and for many > purposes other than in routers, a great amount of the work on YANG modules > in the IETF is in the Routing Area and targeted at routers. We need YANG > modules that are practical and useful for routers and operators. > > Second, there is a split happening where many OpenConfig models are > implemented on routers. These, of course, address limited use-cases. > Doing what we can to reduce that split is useful. > > Getting a list of the perceived issues is useful. Claiming that we must > have full agreement and understanding of the problem - when it is others > who are experiencing it and making clear decisions based on their > experience of the problems - is not. Understanding enough of the problem > to propose solutions and iterate to get to acceptable solutions that solve > the problem is important. > > As you all well know, we are working on getting YANG models completed and > published as quickly as possible. Proposing the need for slow process, > trying to put not-my-problem-fields on others' issues and implementations, > and trying to make any change sound radical (YANG 2.0????) is not > constructive. > > I would welcome Jeff organizing discussion in RTGWG around the issues with > ietf-routing-types and, where they are more general, in NetMod. > > IETF YANG modules done in the Routing Area MUST be useful to router > vendors and operators. > > Regards, > Alia > > On Wed, Feb 22, 2017 at 2:07 PM, Rob Shakir wrote: > >> I'm not asserting it is not possible to do so - of course it is, and I >> encourage anything to be open sourced that helps YANG adoption (hey, I'm >> actually trying to do that everywhere I can). >> >> But there are other problems too - what common tooling is available for >> non-developers that are writing models? For example, there are many, many >> different sites that will give you a way to validate that a regexp matches >> some test content that you're interested in (e.g., http://regexr.com/, >> https://regex101.com/). I have found none of these that support XSD >> regexps. The key point is that picking a road less travelled comes with >> costs around the ecosystem. >> >> I don't think anyone on this thread has asserted "The regexp forward must >> be POSIX". I am definitely sympathetic to the need for unicode support. >> Let's debate the merits of the different solutions - with everything in >> mind, not a single implementation iff we want to change something in YANG. >> >> OC - which targets specific use cases - simply because we are use-case >> focused, may make specific decisions that work with the systems that it is >> interested with a view to getting to the stage of being able to move >> network management forward. The latter's what I care about most. YANG is >> really just a means to an end. >> >> r. >> >> >> On Wed, 22 Feb 2017 at 10:59 Martin Bjorklund wrote: >> >>> Rob Shakir wrote: >>> > On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund wrote: >>> > >>> > > >>> > > For my understanding, did you consider libxml2? I would like to >>> > > understand what "implementation barrier" and "implementation >>> > > complexity" really means. >>> > > >>> > >>> > Pyangbind uses lxml for some elements of its functionality - >>> particularly >>> > to support a lightweight XML backend for XPATH querying. It doesn't use >>> > libxml2 for regexps. When I looked originally, I didn't find useful >>> > language bindings to libxml2 in Python. >>> >>> pyang is using libxml2 to validate the patterns. >>> >>> > In other projects, we don't have any XML library dependencies, adding >>> > libxml2 as a dependency seems overkill simply to parse regexs when >>> there >>> > are built in libraries in many languages without libxml2. >>> >>> Hmm. In what way overkill? For ConfD/NCS we actually took the regexp >>> part of libxml2 and we build a separate .a/.so file; the .a file is >>> ~130K stripped. Compared to ~3M for libxml2. If it would help I can >>> publish this project on github. >>> >>> >>> /martin >>> >> > --001a114240b078a0210549878fb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I don't really care what proces= s is used.
That is for the IESG to figure out.

Here is the text in RFC 7950:

That's your problem, not YANG= doctors, but normative text in
a standards track RFC.
=
I am not in favor of changing that text, but if others want = it changed,
it seems that a new version of the YANG language woul= d be required.
The [XSD-TYPES] reference is not a typo, not an er= ror, so an errata
cannot be used to change it.


Andy


On Mon, Feb 27, 2017 at 10:39 AM, Alia = Atlas <akatlas@gmail.com> wrote:
First, while YANG models are obviously used in many= places and for many purposes other than in routers, a great amount of the = work on YANG modules in the IETF is in the Routing Area and targeted at rou= ters. =C2=A0 We need YANG modules that are practical and useful for routers= and operators.

Second, there is a split happening where= many OpenConfig models are implemented on routers.=C2=A0 These, of course,= address limited use-cases.=C2=A0 Doing what we can to reduce that split is= useful.

Getting a list of the perceived issues is= useful.=C2=A0 Claiming that we must have full agreement and understanding = of the problem - when it is others who are experiencing it and making clear= decisions based on their experience of the problems - is not.=C2=A0 Unders= tanding enough of the problem to propose solutions and iterate to get to ac= ceptable solutions that solve the problem is important.

As you all well know, we are working on getting YANG models completed= and published as quickly as possible.=C2=A0 Proposing the need for slow pr= ocess, trying to put not-my-problem-fields on others' issues and implem= entations, and trying to make any change sound radical (YANG 2.0????) is no= t constructive.

I would welcome Jeff organizing di= scussion in RTGWG around the issues with ietf-routing-types and, where they= are more general, in NetMod.

IETF YANG modules do= ne in the Routing Area MUST be useful to router vendors and operators.

Regards,
Alia

On Wed, Feb 22, 2017 at 2:07 PM, Rob= Shakir <rjs@rob.sh> wrote:
I'm not asserting it is not possible to do so - of course i= t is, and I encourage anything to be open sourced that helps YANG adoption = (hey, I'm actually trying to do that everywhere I can).

<= div>But there are other problems too - what common tooling is available for= non-developers that are writing models? For example, there are many, many = different sites that will give you a way to validate that a regexp matches = some test content that you're interested in (e.g.,=C2=A0http://regexr.com/,=C2=A0https://regex101.com/). I = have found none of these that support XSD regexps. The key point is =C2=A0t= hat picking a road less travelled comes with costs around the ecosystem.
I don't think anyone on this thread has asserted= "The regexp forward must be POSIX". I am definitely sympathetic = to the need for unicode support. Let's debate the merits of the differe= nt solutions - with everything in mind, not a single implementation iff we = want to change something in YANG.=C2=A0

OC - which= targets specific use cases - simply because we are use-case focused, may m= ake specific decisions that work with the systems that it is interested wit= h a view to getting to the stage of being able to move network management f= orward. The latter's what I care about most. YANG is really just a mean= s to an end.

r.


On Wed, 22 Feb 20= 17 at 10:59 Martin Bjorklund <mbj@tail-f.com> wrote:
Rob Shakir <rjs@rob.sh> wrote:
> On Wed, 22 Feb 2017 at 10:43 Martin Bjorklund <mbj@tail-f.com> wrote:
>
> >
> > For my understanding, did you consider libxml2?=C2=A0 I would lik= e to
> > understand what "implementation barrier" and "impl= ementation
> > complexity" really means.
> >
>
> Pyangbind uses lxml for some elements of its functionality - particula= rly
> to support a lightweight XML backend for XPATH querying. It doesn'= t use
> libxml2 for regexps. When I looked originally, I didn't find usefu= l
> language bindings to libxml2 in Python.

pyang is using libxml2 to validate the patterns.

> In other projects, we don't have any XML library dependencies, add= ing
> libxml2 as a dependency seems overkill simply to parse regexs when the= re
> are built in libraries in many languages without libxml2.

Hmm.=C2=A0 In what way overkill?=C2=A0 For ConfD/NCS we actually took the r= egexp
part of libxml2 and we build a separate .a/.so file; the .a file is
~130K stripped.=C2=A0 Compared to ~3M for libxml2.=C2=A0 If it would help I= can
publish this project on github.


/martin


--001a114240b078a0210549878fb5-- From nobody Mon Feb 27 10:57:44 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3BC12A2DF; Mon, 27 Feb 2017 10:57:42 -0800 (PST) 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 p9N8cZo9-EZ7; Mon, 27 Feb 2017 10:57:40 -0800 (PST) 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 9614D129B0F; Mon, 27 Feb 2017 10:57:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C0CF513FB; Mon, 27 Feb 2017 19:57:38 +0100 (CET) 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 LJneYY8N4Q82; Mon, 27 Feb 2017 19:57:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 27 Feb 2017 19:57:38 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57925200DE; Mon, 27 Feb 2017 19:57:38 +0100 (CET) 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 VY6ASmLYq6Do; Mon, 27 Feb 2017 19:57:38 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CDCC200DB; Mon, 27 Feb 2017 19:57:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5DA6F3E8B15A; Mon, 27 Feb 2017 19:57:40 +0100 (CET) Date: Mon, 27 Feb 2017 19:57:39 +0100 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20170227185739.GA68025@elstar.local> Mail-Followup-To: Alia Atlas , Rob Shakir , RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Acee Lindem , YANG Doctors , Jeff Tantsura , Lou Berger , yingzhen.qu@huawei.com References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.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: Cc: RTG YANG Design Team , Lou Berger , Phil Shafer , Anees Shaikh , Xufeng Liu , yingzhen.qu@huawei.com, YANG Doctors , Jeff Tantsura , Rob Shakir , Acee Lindem Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 18:57:43 -0000 On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote: > > Getting a list of the perceived issues is useful. Claiming that we must > have full agreement and understanding of the problem - when it is others > who are experiencing it and making clear decisions based on their > experience of the problems - is not. Understanding enough of the problem > to propose solutions and iterate to get to acceptable solutions that solve > the problem is important. > Alia, the pattern statement is part of a standards-track RFC (in its second revision) and it has been implemented in running code. I believe it is _required_ to have a clear problem statement if the pattern statement is not good enough and needs modifications. /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 Mon Feb 27 11:01:28 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0B12A2DF; Mon, 27 Feb 2017 11:01:27 -0800 (PST) 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 rEhp2EsEZ7zg; Mon, 27 Feb 2017 11:01:25 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 943D312A2CD; Mon, 27 Feb 2017 11:01:25 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id v186so68730149wmd.0; Mon, 27 Feb 2017 11:01:25 -0800 (PST) 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; bh=Aqvz/wTp42VlTFw71G68V7s18dzH/5cYnY9TJL/iCmY=; b=ncxoDh8BIESwdOkXf8mBtOBasHEwKYUp2zbSrO1Pxja5B3rVVHGatZZzYeDgdxAphe 0NV3Rr74JbJGVT8dIpBY1bATIzq0mnRRaTMf32CHyABvTT9ogpQg9sbbgsVXVV7Je34R xwX/oWKk4jxFMc5i/GkyIy0aYV4M0XOtZY6Km2Uv53nyK1Hb1bTPJqB4MAFX7iu9EFT0 8fWTHKxxvoqVMC92v31Y8E5GUMEqer9m4bEHQDflzyfUjI34eiUHXplnNNv4jmbBq2CS 6gG0zFJ9ApQR9eFzYfDcCLHK8hWOf35UGebdMAHpUH48emq1umcxCu9+jS0IAHw5dzgQ A1+g== 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=Aqvz/wTp42VlTFw71G68V7s18dzH/5cYnY9TJL/iCmY=; b=oUOWwEGHbZq4y3IoekwnTixzLkwshZk5asTDa/wGiF0t8Y6XI/n+sNvrWBAYh7HSms TtdgSG65oyB3dzoufaelF0DbGCMImk/iVBDxeUMTwThpEdUkxgozSQ7DN1gRcG+0z26m k3tWxwT1jg55oA+ghEx77BlttixslXtuoca7s3zxo//2U6UbqYRVocSp2l6psdaH7Kjl cqfa1znU442ElcjUdobJ+Ec0wtO2YUgE4D5bFdBgB+wbDlZzYYEwaWpWW0gM6Hjlczrs BTn9ZtE2XM4O0i4g3n3qsaVhz2FABbPuAAEJAJSMSXTbS1ep1NbmC8CDh5iZ9iU5gl2I bvPQ== X-Gm-Message-State: AMke39lO9wp+WFDVKKMnPrv/FTpIpgQKOdLzEV2SxzPNyXxrLZQKveEFYRETTZzQIxfho+EsB3LyAZRLkmRAqA== X-Received: by 10.28.127.13 with SMTP id a13mr14671845wmd.96.1488222083884; Mon, 27 Feb 2017 11:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.163.202 with HTTP; Mon, 27 Feb 2017 11:01:22 -0800 (PST) In-Reply-To: <20170227185739.GA68025@elstar.local> References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@elstar.local> From: Alia Atlas Date: Mon, 27 Feb 2017 14:01:22 -0500 Message-ID: To: Juergen Schoenwaelder , Alia Atlas , Rob Shakir , RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Acee Lindem , YANG Doctors , Jeff Tantsura , Lou Berger , yingzhen.qu@huawei.com Content-Type: multipart/alternative; boundary=001a1141e446a82fcf054987b4e3 Archived-At: Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:01:27 -0000 --001a1141e446a82fcf054987b4e3 Content-Type: text/plain; charset=UTF-8 Juergen, On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote: > > > > Getting a list of the perceived issues is useful. Claiming that we must > > have full agreement and understanding of the problem - when it is others > > who are experiencing it and making clear decisions based on their > > experience of the problems - is not. Understanding enough of the problem > > to propose solutions and iterate to get to acceptable solutions that > solve > > the problem is important. > > > > Alia, > > the pattern statement is part of a standards-track RFC (in its second > revision) and it has been implemented in running code. I believe it is > _required_ to have a clear problem statement if the pattern statement > is not good enough and needs modifications. There are several ideas in this thread of ways to handle the issue - ranging from an extension to regex translation. Jumping to the most extreme possibility can easily be seen as trying to shut down the conversation. A quick iteration of "problem, proposed solution, remaining issues, ok - new proposed solution & updated problem description" etc - works better for speed and ending up with something that we can all use. Regards, Alia > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1141e446a82fcf054987b4e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Juergen,

On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
=
On Mon, Feb 27, 2017 at 01:= 39:00PM -0500, Alia Atlas wrote:
>
> Getting a list of the perceived issues is useful.=C2=A0 Claiming that = we must
> have full agreement and understanding of the problem - when it is othe= rs
> who are experiencing it and making clear decisions based on their
> experience of the problems - is not.=C2=A0 Understanding enough of the= problem
> to propose solutions and iterate to get to acceptable solutions that s= olve
> the problem is important.
>

Alia,

the pattern statement is part of a standards-track RFC (in its second
revision) and it has been implemented in running code. I believe it is
_required_ to have a clear problem statement if the pattern statement
is not good enough and needs modifications.

There are several ideas in this thread of ways to handle the issue - rangi= ng
from an extension to regex translation. =C2=A0 Jumping to the = most extreme possibility
can easily be seen as trying to shut dow= n the conversation.

A quick iteration of "pro= blem, proposed solution, remaining issues, ok - new proposed
solu= tion & updated problem description" etc - works better for speed a= nd ending up
with something that we can all use.

Regards,
Alia

=C2=A0
/js

--
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 | 28759 Br= emen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<htt= p://www.jacobs-university.de/>

--001a1141e446a82fcf054987b4e3-- From nobody Mon Feb 27 11:10:20 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF5612A2E3 for ; Mon, 27 Feb 2017 11:10:17 -0800 (PST) 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=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 jw6l1miBq74G for ; Mon, 27 Feb 2017 11:10:15 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 9E3D212A2E1 for ; Mon, 27 Feb 2017 11:10:14 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id v186so68902285wmd.0 for ; Mon, 27 Feb 2017 11:10:14 -0800 (PST) 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=U7SLJA6X/9jUuisce64/RalEJxeYNz6PVufVzOEM/ws=; b=swlnmYp+2HwMURiWOb0ky4sg5BXaR37iiT5vV5yBZPJOH5fzc02mKs4V8w8D/415Cb Zmve4HFzovuXaAideSL1tsJy10QzKuIEZ5rsibb9DVLqki0nbXkT7+bpfBZ1WfhjDEZ9 Lt91kcwv0aKq9cflVn3s6wzgQHvZoLthKxdxW3lzI1MzpZKhPP3lnYvZSGT8KAlHcIbS aivveamv7X1QEt2D59qEs+2vziPfe4EX1ZGQsTR1D8qlPdV/9HsZqaeLp1yuiYYOqhz8 mjLMr7smuPpHHMIMWDLWH+hWA2AyeMwpSk5+cJE3ukM+15aDw6WVBYGEQnSmzOisklhr UXHA== 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=U7SLJA6X/9jUuisce64/RalEJxeYNz6PVufVzOEM/ws=; b=hnCCwmnb/4Dc//n4CMkg7NXD0b2XEdk0KIZyLkHu0VF97OHi6sE/HoMKD7ANsT4/Fd IKNR65ogLJoUWAth6xUTEHE+ueOI/8fc544DO8r0CCjUFQorG0fzcrjc/Aha2fbXiaOV ivrWxJs2qGpMKrUKbJz30ip6NpqxIY+EUXYdRwJcW+fWsh+lnEvCnZyqRpFQu5qLrl7c NyzBuhUXPanYPPz+iY7smlI1LR+qMz0bSm9/4q8Df5/p74NBwFXND20BIHRVfqhvtekg 6lBESrDvASukpIEC4vTjAmcQ1Q+96BI2NOHOxZKh/Z4dg6o3NXoz38TzfzMcOirOdZ2p zoqw== X-Gm-Message-State: AMke39nhni9i/EP28ikFvaO3fwaqP6tY0pE3efLK358TlzX+x2GupOP3aoXboCqAF9/N6mmT10RxNX1AZyBgcA== X-Received: by 10.28.214.144 with SMTP id n138mr14108503wmg.136.1488222613096; Mon, 27 Feb 2017 11:10:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Mon, 27 Feb 2017 11:10:12 -0800 (PST) In-Reply-To: References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@elstar.local> From: Andy Bierman Date: Mon, 27 Feb 2017 11:10:12 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=001a113fb18a335e21054987d4bd Archived-At: Cc: RTG YANG Design Team , Lou Berger , Phil Shafer , Anees Shaikh , Xufeng Liu , Yingzhen Qu , YANG Doctors , Jeff Tantsura , Rob Shakir , Acee Lindem Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:10:17 -0000 --001a113fb18a335e21054987d4bd Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 11:01 AM, Alia Atlas wrote: > Juergen, > > On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote: >> > >> > Getting a list of the perceived issues is useful. Claiming that we must >> > have full agreement and understanding of the problem - when it is others >> > who are experiencing it and making clear decisions based on their >> > experience of the problems - is not. Understanding enough of the >> problem >> > to propose solutions and iterate to get to acceptable solutions that >> solve >> > the problem is important. >> > >> >> Alia, >> >> the pattern statement is part of a standards-track RFC (in its second >> revision) and it has been implemented in running code. I believe it is >> _required_ to have a clear problem statement if the pattern statement >> is not good enough and needs modifications. > > > There are several ideas in this thread of ways to handle the issue - > ranging > from an extension to regex translation. Jumping to the most extreme > possibility > can easily be seen as trying to shut down the conversation. > > A quick iteration of "problem, proposed solution, remaining issues, ok - > new proposed > solution & updated problem description" etc - works better for speed and > ending up > with something that we can all use. > > The only problem statement I have heard is that the XSD pattern is too hard to implement, but several implementations exist countering the claim that it is too hard. Assuming there is agreement to use a different regexp spec, then what is it? Please provide a URL to the regexp spec that is being proposed instead. It is very common in the IETF to ask "what problem are you trying to solve", and "what is your solution proposal". You act like these questions are inappropriate. > Regards, > Alia > Andy > > > >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > --001a113fb18a335e21054987d4bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 27, 2017 at 11:01 AM, Alia Atlas <akatlas@gmail.com>= ; wrote:
Juergen,=

On Mon, Feb 2= 7, 2017 at 1:57 PM, Juergen Schoenwaelder <j.schoenwael= der@jacobs-university.de> wrote:
On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote= :
>
> Getting a list of the perceived issues is useful.=C2=A0 Claiming that = we must
> have full agreement and understanding of the problem - when it is othe= rs
> who are experiencing it and making clear decisions based on their
> experience of the problems - is not.=C2=A0 Understanding enough of the= problem
> to propose solutions and iterate to get to acceptable solutions that s= olve
> the problem is important.
>

Alia,

the pattern statement is part of a standards-track RFC (in its second
revision) and it has been implemented in running code. I believe it is
_required_ to have a clear problem statement if the pattern statement
is not good enough and needs modifications.

There are several ideas in this thread of ways to handle the issue - rangi= ng
from an extension to regex translation. =C2=A0 Jumping to the = most extreme possibility
can easily be seen as trying to shut dow= n the conversation.

A quick iteration of "pro= blem, proposed solution, remaining issues, ok - new proposed
solu= tion & updated problem description" etc - works better for speed a= nd ending up
with something that we can all use.


The only problem sta= tement I have heard is that the XSD pattern
is too hard to implem= ent, but several implementations exist countering
the claim that = it is too hard.

Assuming there is agreement to use= a different regexp spec,
then what is it?=C2=A0 Please provide a= URL to the regexp spec that
is being proposed instead.

It is very common in the IETF to ask "what problem are= you trying
to solve", and "what is your solution propo= sal".=C2=A0 You act like these
questions are inappropriate.<= /div>

=C2=A0
=
Regards,
Alia

<= /div>

Andy
=C2=A0

=C2=A0
/js

--
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 | 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/>


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors


--001a113fb18a335e21054987d4bd-- From nobody Mon Feb 27 11:19:58 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B212A2E4; Mon, 27 Feb 2017 11:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, 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 BQDT4e1yw7On; Mon, 27 Feb 2017 11:19:56 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 A230012956F; Mon, 27 Feb 2017 11:19:55 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id u48so9337339wrc.0; Mon, 27 Feb 2017 11:19:55 -0800 (PST) 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=dx2b4sdP2CTmFpllsTDhTKWWtDZSHMs24LGDeJ8b/0c=; b=ho8T+Pa7gBFxhwR0cNqI5YWOeITq0PxLsf8/b8CSPIrnE/FWSH21766iW/UJyOQPLN vY4DP+9PHbeqz/V1KzvUsX77Tn75gsEnFnZvofbjDBQEQQr+Il+BC9KRW6T5yOMfKUyi Ky5BTqgRBf91OGWRjZTjPhvp7vpAUHqK+5z/jIEewaHMc5M9MhOOihoLKjIyn+LM+6gB oMFW/iMP7qa5hG6r9L10wGnRAUINP+3Vc4DZE46PUSl8bTzaCx6enU2s2g41ge3UTxQ6 SaJDITtA1dywrZi8AcSHXdM/ywIyGOLap1JUVLYuWIWzJ7jZn68i3mglN4lES+Rg3HXS 1Ddw== 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=dx2b4sdP2CTmFpllsTDhTKWWtDZSHMs24LGDeJ8b/0c=; b=ElVUL4LQwPBypFz8M82rrMEhz38rUawd4Im810cT2A+N5x715lahFw52I2yccPP0Fu ZIEx9W3bmnyScsCDPHodiJo6appdYlwGz8ECtFKpmd6LO33DC1qvHjcIW2BieRKKVpYe at42nol71IJkzqeSDAW/B8jFfHGkdLNJJMR7r07zqABUwHovwYzKB+PzZm8aiiek9hXg E+gkIYyUocTBIbzT61WCUPLzqha+oQwdf5EkrzpvYei09h5hirhn1cCXDZb/0y9TbTFO hkt7E+DU0MqUEzU8/6CfUZ2vnCTVY27z1DuX8Sqa2uc2sP/amnnLActnGhqGvrBSm6ie PzcA== X-Gm-Message-State: AMke39kLdjXpVurK2tLgCBNQO7iPyMMrc50+1O76JY6ruHBowfuF6gf38H9ukFluxCwKovvDhtbaOOaaz83Wnw== X-Received: by 10.223.136.4 with SMTP id d4mr3531109wrd.44.1488223194035; Mon, 27 Feb 2017 11:19:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.163.202 with HTTP; Mon, 27 Feb 2017 11:19:53 -0800 (PST) In-Reply-To: References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@elstar.local> From: Alia Atlas Date: Mon, 27 Feb 2017 14:19:53 -0500 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=001a11461d18d3befb054987f69f Archived-At: Cc: RTG YANG Design Team , Lou Berger , Phil Shafer , Anees Shaikh , Xufeng Liu , Yingzhen Qu , YANG Doctors , Jeff Tantsura , Rob Shakir , Acee Lindem Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:19:58 -0000 --001a11461d18d3befb054987f69f Content-Type: text/plain; charset=UTF-8 Hi Andy, On Mon, Feb 27, 2017 at 2:10 PM, Andy Bierman wrote: > > > On Mon, Feb 27, 2017 at 11:01 AM, Alia Atlas wrote: > >> Juergen, >> >> On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote: >>> > >>> > Getting a list of the perceived issues is useful. Claiming that we >>> must >>> > have full agreement and understanding of the problem - when it is >>> others >>> > who are experiencing it and making clear decisions based on their >>> > experience of the problems - is not. Understanding enough of the >>> problem >>> > to propose solutions and iterate to get to acceptable solutions that >>> solve >>> > the problem is important. >>> > >>> >>> Alia, >>> >>> the pattern statement is part of a standards-track RFC (in its second >>> revision) and it has been implemented in running code. I believe it is >>> _required_ to have a clear problem statement if the pattern statement >>> is not good enough and needs modifications. >> >> >> There are several ideas in this thread of ways to handle the issue - >> ranging >> from an extension to regex translation. Jumping to the most extreme >> possibility >> can easily be seen as trying to shut down the conversation. >> >> A quick iteration of "problem, proposed solution, remaining issues, ok - >> new proposed >> solution & updated problem description" etc - works better for speed and >> ending up >> with something that we can all use. >> >> > The only problem statement I have heard is that the XSD pattern > is too hard to implement, but several implementations exist countering > the claim that it is too hard. > Earlier in this thread, Jeff mentioned that he is talking more and working on clarifying the details of the problem. Rob said that he's seen this issue during implementations; it might be that the smaller library suggested by Martin can help. I currently don't know and am awaiting more details. Please wait to form judgments. > Assuming there is agreement to use a different regexp spec, > then what is it? Please provide a URL to the regexp spec that > is being proposed instead. > First, I am responding with an AD hat - not as individual contributor. What I have read is that an implementation is using a different regexp because of the issue - and this is driving the OpenConfig depedencies away from ietf-routing-types. It is very common in the IETF to ask "what problem are you trying > to solve", and "what is your solution proposal". You act like these > questions are inappropriate. > I am quite aware of methods for engaging productively and for invoking excess process in an effort to slow needed work down. Regards, Alia > Regards, >> Alia >> > > > Andy > > >> >> >> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >> >> >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org >> https://www.ietf.org/mailman/listinfo/yang-doctors >> >> > --001a11461d18d3befb054987f69f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

On Mon, Feb 27, 2017 at 2:10 PM, Andy Bierman <andy@yumaworks= .com> wrote:


On Mon, Feb 27, 2017 at 11:01 AM, Alia Atlas <<= a href=3D"mailto:akatlas@gmail.com" target=3D"_blank">akatlas@gmail.com= > wrote:
Juerg= en,

On Mon, Fe= b 27, 2017 at 1:57 PM, Juergen Schoenwaelder <j.schoen= waelder@jacobs-university.de> wrote:
On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas w= rote:
>
> Getting a list of the perceived issues is useful.=C2=A0 Claiming that = we must
> have full agreement and understanding of the problem - when it is othe= rs
> who are experiencing it and making clear decisions based on their
> experience of the problems - is not.=C2=A0 Understanding enough of the= problem
> to propose solutions and iterate to get to acceptable solutions that s= olve
> the problem is important.
>

Alia,

the pattern statement is part of a standards-track RFC (in its second
revision) and it has been implemented in running code. I believe it is
_required_ to have a clear problem statement if the pattern statement
is not good enough and needs modifications.

There are several ideas in this thread of ways to handle the issue - rangi= ng
from an extension to regex translation. =C2=A0 Jumping to the = most extreme possibility
can easily be seen as trying to shut dow= n the conversation.

A quick iteration of "pro= blem, proposed solution, remaining issues, ok - new proposed
solu= tion & updated problem description" etc - works better for speed a= nd ending up
with something that we can all use.


The only prob= lem statement I have heard is that the XSD pattern
is too hard to= implement, but several implementations exist countering
the clai= m that it is too hard.

<= div>Earlier in this thread, Jeff mentioned that he is talking more and work= ing on clarifying
the details of the problem.=C2=A0 Rob said that= he's seen this issue during implementations;
it might be tha= t the smaller library suggested by Martin can help.=C2=A0 I currently don&#= 39;t know
and am awaiting more details.

= Please wait to form judgments. =C2=A0

=C2=A0
=
=
Assuming there is agreement to u= se a different regexp spec,
then what is it?=C2=A0 Please provide= a URL to the regexp spec that
is being proposed instead.

First, I am responding wit= h an AD hat - not as individual contributor.
What I have read is = that an implementation is using a different regexp because
of the= issue - and this is driving the OpenConfig depedencies away from ietf-rout= ing-types.

I= t is very common in the IETF to ask "what problem are you trying
=
to solve", and "what is your solution proposal".=C2=A0 = You act like these
questions are inappropriate.
=

I am quite aware of methods for enga= ging productively and for invoking excess process in
an effort to= slow needed work down.

Regards,
Alia

=C2=A0
Regards,
Alia

<= br>
Andy
=C2=A0

=C2=A0
/js

--
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 | 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/>


__________________________________________= _____
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors



--001a11461d18d3befb054987f69f-- From nobody Mon Feb 27 11:24:55 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B818512A2E8; Mon, 27 Feb 2017 11:24:51 -0800 (PST) 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 77aBNv496gE1; Mon, 27 Feb 2017 11:24:50 -0800 (PST) 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 3F47612A2F3; Mon, 27 Feb 2017 11:24:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 04F35133F; Mon, 27 Feb 2017 20:24:49 +0100 (CET) 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 GQY2qLnyt4Am; Mon, 27 Feb 2017 20:24:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 27 Feb 2017 20:24:48 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD78C200DE; Mon, 27 Feb 2017 20:24:48 +0100 (CET) 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 dCogurOo7hMD; Mon, 27 Feb 2017 20:24:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EFD6200DB; Mon, 27 Feb 2017 20:24:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0570F3E8B337; Mon, 27 Feb 2017 20:24:51 +0100 (CET) Date: Mon, 27 Feb 2017 20:24:51 +0100 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20170227192451.GA68227@elstar.local> Mail-Followup-To: Alia Atlas , Andy Bierman , Rob Shakir , RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Acee Lindem , YANG Doctors , Jeff Tantsura , Lou Berger , Yingzhen Qu References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@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: Cc: RTG YANG Design Team , Lou Berger , Phil Shafer , Anees Shaikh , Xufeng Liu , Yingzhen Qu , YANG Doctors , Jeff Tantsura , Rob Shakir , Acee Lindem Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:24:52 -0000 On Mon, Feb 27, 2017 at 02:19:53PM -0500, Alia Atlas wrote: > > First, I am responding with an AD hat - not as individual > contributor. > Thanks Alia for helping us to get a better understanding of the problem space and the solution space. I am looking forward to Jeffs and Robs input. /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 Mon Feb 27 11:31:53 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317EF129F03 for ; Mon, 27 Feb 2017 11:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 CNm_dsPzHCao for ; Mon, 27 Feb 2017 11:31:51 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 61B1A1270B4 for ; Mon, 27 Feb 2017 11:31:51 -0800 (PST) Received: (qmail 25267 invoked by uid 0); 27 Feb 2017 19:31:50 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 27 Feb 2017 19:31:50 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id pvXm1u00g2SSUrH01vXpvJ; Mon, 27 Feb 2017 12:31:50 -0700 X-Authority-Analysis: v=2.1 cv=H5NInYoi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=n2v9WMKugxEA:10 a=dtQ85cVabj5BqhdcSEIA:9 a=pILNOxqGKmIA:10 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:References:To:Subject: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=1qJxvvM4zeloHr+wMcusdFcBDc00oJui7FHZX8vWKs8=; b=1I71xIIocrc8MTf0BM0dvEDwuW kvXnBovnBxFD2Yu1BGHToTtARVxVjP42EbGqFNLatyt1bL9p04/lsRlA+gv/Zbgz+pJ87W+oGMPdA g3/ldzbRUqk/Ya6EpLWL7xI8E; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:51670 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1ciR1M-000448-Hy; Mon, 27 Feb 2017 12:31:46 -0700 To: Alia Atlas , Andy Bierman , Rob Shakir , RTG YANG Design Team , Phil Shafer , Anees Shaikh , Xufeng Liu , Acee Lindem , YANG Doctors , Jeff Tantsura , Yingzhen Qu References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@elstar.local> <20170227192451.GA68227@elstar.local> From: Lou Berger Message-ID: <1d7ce429-6934-983e-5b4a-70c67cf11c4e@labn.net> Date: Mon, 27 Feb 2017 14:31:02 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170227192451.GA68227@elstar.local> 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.85.191 X-Exim-ID: 1ciR1M-000448-Hy X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:51670 X-Source-Auth: lberger@labn.net X-Email-Count: 9 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:31:52 -0000 Just an FYI - In today's RTG Area YANG Arch DT meeting we discussed Jeff's plans and it includes presentation on requirements in Chicago. Let's given him some time to collect this and put it in a good form for further discussion. We'll ID WG in the 1-2 weeks for this presentation after more discussions with chairs and (if needed) ADs. Lou On 2/27/2017 2:24 PM, Juergen Schoenwaelder wrote: > On Mon, Feb 27, 2017 at 02:19:53PM -0500, Alia Atlas wrote: >> First, I am responding with an AD hat - not as individual >> contributor. >> > Thanks Alia for helping us to get a better understanding of the > problem space and the solution space. I am looking forward to Jeffs > and Robs input. > > /js > From nobody Mon Feb 27 11:33:09 2017 Return-Path: X-Original-To: yang-doctors@ietfa.amsl.com Delivered-To: yang-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114E9129F03 for ; Mon, 27 Feb 2017 11:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 tK1rIC9SLduT for ; Mon, 27 Feb 2017 11:33:06 -0800 (PST) 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 039DD12A2F4 for ; Mon, 27 Feb 2017 11:27:10 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id u48so9458876wrc.0 for ; Mon, 27 Feb 2017 11:27:09 -0800 (PST) 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=Cb0cPhqT9/PmJxeYZa0HeviJMMSSZQ2XBZJ/tD3gqJ0=; b=JAxvbLIPYYeTwCNJsqPza56rSfTmqx5gCnaNIA9ZgmhoNo/AxUFeMxCYXTyS33Oitq OeC86N0qBsrGr933XBtZUeQkz9pyyi97x+v40asIWgz6utM9JCfvjbCNL56urs1LJrU7 XdVKSzQfOpkaD7XSr6cFh/t4JT5mKuxEF6GleqVWx5YOzZG+wlyRsT49BV5uk/o2nFOP 2TTsZIxMN0gG3Swk6/Y7Cbpv8KQMuyT6MlQonF6I132lA0UkIahbsbhyhofB9z/YyagC lc3sDHZxiFpSItMH5Gpzm0NlFj65Z69NtjWt95eUvF+xwvWWBwY9Z8oFFPZGB8Ui4LSd VbfA== 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=Cb0cPhqT9/PmJxeYZa0HeviJMMSSZQ2XBZJ/tD3gqJ0=; b=WUqmVJeKErcUIK4VVsLrIKSWERTrPa2785zcELfsgU9anbxrL9YOILtPASGFymwceX 91sbJEu2UNeEs55i1dY/ovgfxzxMLEL903Zwep+EhtVhB11v4NpihHZSjI0txbj2W5Dp Di84/sU+3CMewPW6FYN/qZfgSafW4OeYvKrzcNBkxSzz8SJW3IdvWfVsSOJbZpfydwSt coDDj8EvobuIqUmfh2R5k4HLlJOhFSw91DOY42Cdu2J5X1Ipeczj3Isd8vJJOBl8T4Ea tmzDagVqdnxJn3WcRrT6oUJ3qWzUeprN00AH0MEKDkC1pjazJdpTMeuYZbl49QfgJqHD Zslg== X-Gm-Message-State: AMke39kn7NnD8eTGiX862FYIKi03cEvEeky+qr/Iw3rWFrGHMFinUKsLkMT3mkjs7XY8zuE27yJZyhSOWb3JTQ== X-Received: by 10.223.151.138 with SMTP id s10mr15285908wrb.65.1488223628531; Mon, 27 Feb 2017 11:27:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.154 with HTTP; Mon, 27 Feb 2017 11:27:07 -0800 (PST) In-Reply-To: References: <20170222.194349.709735877588963434.mbj@tail-f.com> <20170222.195950.1851393848459342115.mbj@tail-f.com> <20170227185739.GA68025@elstar.local> From: Andy Bierman Date: Mon, 27 Feb 2017 11:27:07 -0800 Message-ID: To: Alia Atlas Content-Type: multipart/alternative; boundary=94eb2c1b5912b9a2de05498810e3 Archived-At: Cc: RTG YANG Design Team , Lou Berger , Phil Shafer , Anees Shaikh , Xufeng Liu , Yingzhen Qu , YANG Doctors , Jeff Tantsura , Rob Shakir , Acee Lindem Subject: Re: [yang-doctors] [Rtg-dt-yang-arch] Open Config on ietf-routing-types X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:33:08 -0000 --94eb2c1b5912b9a2de05498810e3 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 11:19 AM, Alia Atlas wrote: > Hi Andy, > > On Mon, Feb 27, 2017 at 2:10 PM, Andy Bierman wrote: > >> >> >> On Mon, Feb 27, 2017 at 11:01 AM, Alia Atlas wrote: >> >>> Juergen, >>> >>> On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>>> On Mon, Feb 27, 2017 at 01:39:00PM -0500, Alia Atlas wrote: >>>> > >>>> > Getting a list of the perceived issues is useful. Claiming that we >>>> must >>>> > have full agreement and understanding of the problem - when it is >>>> others >>>> > who are experiencing it and making clear decisions based on their >>>> > experience of the problems - is not. Understanding enough of the >>>> problem >>>> > to propose solutions and iterate to get to acceptable solutions that >>>> solve >>>> > the problem is important. >>>> > >>>> >>>> Alia, >>>> >>>> the pattern statement is part of a standards-track RFC (in its second >>>> revision) and it has been implemented in running code. I believe it is >>>> _required_ to have a clear problem statement if the pattern statement >>>> is not good enough and needs modifications. >>> >>> >>> There are several ideas in this thread of ways to handle the issue - >>> ranging >>> from an extension to regex translation. Jumping to the most extreme >>> possibility >>> can easily be seen as trying to shut down the conversation. >>> >>> A quick iteration of "problem, proposed solution, remaining issues, ok - >>> new proposed >>> solution & updated problem description" etc - works better for speed and >>> ending up >>> with something that we can all use. >>> >>> >> The only problem statement I have heard is that the XSD pattern >> is too hard to implement, but several implementations exist countering >> the claim that it is too hard. >> > > Earlier in this thread, Jeff mentioned that he is talking more and working > on clarifying > the details of the problem. Rob said that he's seen this issue during > implementations; > it might be that the smaller library suggested by Martin can help. I > currently don't know > and am awaiting more details. > > Please wait to form judgments. > > > >> Assuming there is agreement to use a different regexp spec, >> then what is it? Please provide a URL to the regexp spec that >> is being proposed instead. >> > > First, I am responding with an AD hat - not as individual contributor. > What I have read is that an implementation is using a different regexp > because > of the issue - and this is driving the OpenConfig depedencies away from > ietf-routing-types. > > It is very common in the IETF to ask "what problem are you trying >> to solve", and "what is your solution proposal". You act like these >> questions are inappropriate. >> > > I am quite aware of methods for engaging productively and for invoking > excess process in > an effort to slow needed work down. > > These same "tools" are also used to build consensus. Genuine lack of consensus should not be confused with excess process. > Regards, > Alia > Andy > > > >> Regards, >>> Alia >>> >> >> >> Andy >> >> >>> >>> >>> >>>> /js >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>> >>> >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >>> >>> >> > --94eb2c1b5912b9a2de05498810e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 27, 2017 at 11:19 AM, Alia Atlas <akatlas@gmail.com>= ; wrote:
Hi Andy,=

On Mon, Feb 2= 7, 2017 at 2:10 PM, Andy Bierman <andy@yumaworks.com> wrote= :


On Mon, Feb 27, 2017 at 11:01= AM, Alia Atlas <akatlas@gmail.com> wrote:
Juergen,
On Mon, Feb 27, 2017 at 1:57 PM, Juergen Schoe= nwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Mon, Feb 27, = 2017 at 01:39:00PM -0500, Alia Atlas wrote:
>
> Getting a list of the perceived issues is useful.=C2=A0 Claiming that = we must
> have full agreement and understanding of the problem - when it is othe= rs
> who are experiencing it and making clear decisions based on their
> experience of the problems - is not.=C2=A0 Understanding enough of the= problem
> to propose solutions and iterate to get to acceptable solutions that s= olve
> the problem is important.
>

Alia,

the pattern statement is part of a standards-track RFC (in its second
revision) and it has been implemented in running code. I believe it is
_required_ to have a clear problem statement if the pattern statement
is not good enough and needs modifications.

There are several ideas in this thread of ways to handle the issue - rangi= ng
from an extension to regex translation. =C2=A0 Jumping to the = most extreme possibility
can easily be seen as trying to shut dow= n the conversation.

A quick iteration of "pro= blem, proposed solution, remaining issues, ok - new proposed
solu= tion & updated problem description" etc - works better for speed a= nd ending up
with something that we can all use.


The only prob= lem statement I have heard is that the XSD pattern
is too hard to= implement, but several implementations exist countering
the clai= m that it is too hard.

<= div>Earlier in this thread, Jeff mentioned that he is talking more and work= ing on clarifying
the details of the problem.=C2=A0 Rob said that= he's seen this issue during implementations;
it might be tha= t the smaller library suggested by Martin can help.=C2=A0 I currently don&#= 39;t know
and am awaiting more details.

= Please wait to form judgments. =C2=A0

=C2=A0
=
=
Assuming there is agreement to u= se a different regexp spec,
then what is it?=C2=A0 Please provide= a URL to the regexp spec that
is being proposed instead.

First, I am responding wit= h an AD hat - not as individual contributor.
What I have read is = that an implementation is using a different regexp because
of the= issue - and this is driving the OpenConfig depedencies away from ietf-rout= ing-types.

I= t is very common in the IETF to ask "what problem are you trying
=
to solve", and "what is your solution proposal".=C2=A0 = You act like these
questions are inappropriate.
=

I am quite aware of methods for enga= ging productively and for invoking excess process in
an effort to= slow needed work down.

=

These same "tools" are also used to build con= sensus.
Genuine lack of consensus should not be confused with exc= ess process.
=C2=A0
<= div>Regards,
Alia

Andy
=C2=A0

=C2=A0
<= div>Regards,
Alia


Andy
=C2=A0

=C2=A0
/js

--
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 | 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/>


_______________________________________________
yang-doctors mailing list
yang-doctors@iet= f.org
https://www.ietf.org/mailman/listinfo/yang-do= ctors




--94eb2c1b5912b9a2de05498810e3-- From nobody Mon Feb 27 12:58:45 2017 Return-Path: X-Original-To: yang-doctors@ietf.org Delivered-To: yang-doctors@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 33112127ABE for ; Mon, 27 Feb 2017 12:58:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mehmet Ersue To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148822912417.13871.3574357165650813426.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2017 12:58:44 -0800 Archived-At: Subject: [yang-doctors] Weekly Summary of Open review assignments for YANG Doctors X-BeenThere: yang-doctors@ietf.org X-Mailman-Version: 2.1.17 Reply-To: dromasca@gmail.com, mersue@gmail.com List-Id: email list of the yang-doctors directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:58:44 -0000 The following reviewers have assignments: Last calls: Reviewer LC end Draft Kent Watsen 2017-02-27 draft-ietf-netmod-syslog-model-12 Early review requests: Reviewer Due Draft Giles Heron 2017-02-09 draft-ietf-l3sm-l3vpn-service-model-16 Balazs Lengyel 2017-02-28 draft-ietf-netconf-yang-push-04 Jan Lindblad 2017-03-03 draft-ietf-pim-igmp-mld-yang-01 Carl Moberg 2017-02-28 draft-ietf-lime-yang-connectionless-oam-03 Carl Moberg 2017-02-28 draft-ietf-lime-yang-connectionless-oam-methods-00 Carl Moberg 2017-02-28 draft-ietf-lime-yang-oam-model-08 Thomas Nadeau 2017-02-28 draft-ietf-netmod-intf-ext-yang-03 * Other revision previously reviewed ** This revision already reviewed Next in the reviewer rotation: Andy Bierman Martin Bjorklund Dean Bogdanovic Giles Heron Mahesh Jethanandani Radek Krejčí Balazs Lengyel Ladislav Lhotka Jan Lindblad